sagemath/sage

inconsistency between 0.nbits() and 0.ndigits(base=2)

sagetrac-marion opened this issue · 14 comments

There is an inconsistency between functions nbits(), bits() and digits(base=2) when applied to zero:

sage: 0.nbits()
1
sage: 0.ndigits(base=2)
0
sage: 0.bits()
[]
sage: 0.digits(base=2)
[]

Component: basic arithmetic

Keywords: ecc2011

Author: Paul Zimmermann

Reviewer: André Apitzsch

Merged: sage-4.8.alpha3

Issue created by migration from https://trac.sagemath.org/ticket/11796

comment:1

I checked all doctests with Sage 4.7.1 and they all still pass. Strangely the value of nbits for
0 was never tested nor apparently used.

Paul

comment:2

I checked the long doctests on my machine with version 4.7.1 of sage and the following tests failed:

	sage -t -long devel/sage-test/sage/databases/database.py # 15 doctests failed
	sage -t -long devel/sage-test/sage/graphs/graph.py # 6 doctests failed
	sage -t -long devel/sage-test/sage/graphs/graph_list.py # 4 doctests failed
	sage -t -long devel/sage-test/sage/graphs/graph_database.py # 28 doctests failed
	sage -t -long devel/sage-test/sage/graphs/generic_graph.py # 4 doctests failed

Marion

comment:3

Marion,

this is strange, since on my laptop (Core 2 Duo) with Sage 4.7.1 those 5 long doctests pass.

Please can you try again those 5 doctests? Just run for example
sage -t -long databases/database.py in the right directory.
Did they pass without the patch?

Paul

comment:4

Ok, on my Sage without the patch all these 5 doctests failed too (I did not check the tests on the version I downloaded first...)
I will investigate further where the problem comes from.

Marion

comment:5

Marion, you can also try on a computer where all doctests pass before the patch, and open a
separate ticket for the problem on your computer.

Paul

Changed keywords from none to ecc2011

comment:6

The problem was already mentioned in #10596.
But there ndigits() was changed to return 1 instead of 0.

So, whose solution is correct and why?

comment:7

Replying to @a-andre:

The problem was already mentioned in #10596.
But there ndigits() was changed to return 1 instead of 0.

So, whose solution is correct and why?

I cannot apply the patches from #10596 to Sage 4.7:

sage: hg_sage.import_patch("/tmp/trac_10596.patch")
cd "/usr/local/sage/devel/sage" && hg status
cd "/usr/local/sage/devel/sage" && hg status
cd "/usr/local/sage/devel/sage" && hg import   "/tmp/trac_10596.patch"
applying /tmp/trac_10596.patch
patching file sage/rings/integer.pyx
Hunk #4 succeeded at 566 with fuzz 2 (offset -34 lines).
Hunk #69 FAILED at 5248
1 out of 80 hunks FAILED -- saving rejects to file sage/rings/integer.pyx.rej

What is inconsistent is that we should have 0.nbits() == len(0.bits()) == 0.ndigits(base=2) == len(0.digits(base=2)), which currently does not hold.

Now if 0.nbits() is 1, then 0.bits() should be [0].
I would prefer to return 0 and [] respectively, but first solve the inconsistency.

Paul

comment:8

The patches from #10596 are based on Sage 4.8.alpha2.

Reviewer: André Apitzsch

Author: Paul Zimmermann

comment:9

sage/databases/database.py was removed by #11642. All other tests pass.

Merged: sage-4.8.alpha3