Sage: Ticket #8896: 0.0000000000000000000000000000 is parsed completely differently than 1.0000000000000000000000000000 for no good reason
https://trac.sagemath.org/ticket/8896
<p>
In Sage 0.0 and 0.00000000000000000000000000000000000000 denote exactly the same thing (a zero with the same precision). However, that 1.0 and 1.00000000000000000000000000000000000000 are different in Sage:
</p>
<pre class="wiki">sage: 0.0
0.000000000000000
sage: 0.00000000000000000000000000000000000000
0.000000000000000
sage: parent(0.00000000000000000000000000000000000000)
Real Field with 53 bits of precision
sage: 1.00000000000000000000000000000000000000
1.0000000000000000000000000000000000000
sage: 1.0
1.00000000000000
sage: parent(1.00000000000000000000000000000000000000)
Real Field with 130 bits of precision
sage: parent(1.0)
Real Field with 53 bits of precision
</pre><p>
Some people consider the above inconsistency a bug.
See the discussion below and at <a class="ext-link" href="http://groups.google.com/group/sage-devel/browse_thread/thread/73d513e2c55d4601"><span class="icon"></span>sage-devel</a>.
</p>
<p>
Apply <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/8896/8896-rebased.patch" title="Attachment '8896-rebased.patch' in Ticket #8896">8896-rebased.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/8896/8896-rebased.patch" title="Download"></a>
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/8896
Trac 1.1.6robertwbWed, 05 May 2010 22:53:47 GMT
https://trac.sagemath.org/ticket/8896#comment:1
https://trac.sagemath.org/ticket/8896#comment:1
<p>
This is because 0.00000000000000000000000000000000005 is not considered to have "high precision." We should special-case 0.
</p>
TicketleifThu, 06 May 2010 01:06:33 GMT
https://trac.sagemath.org/ticket/8896#comment:2
https://trac.sagemath.org/ticket/8896#comment:2
<p>
Btw, Sage does not distinguish +0.0 and -0.0 (and 0.0).
</p>
<p>
Nice how trac interprets long decimal fractions of floats. :D
</p>
TicketrobertwbSat, 15 May 2010 22:36:34 GMTattachment set
https://trac.sagemath.org/ticket/8896
https://trac.sagemath.org/ticket/8896
<ul>
<li><strong>attachment</strong>
set to <em>8896-highprec-zero.patch</em>
</li>
</ul>
TicketrobertwbSat, 15 May 2010 22:36:58 GMTstatus changed
https://trac.sagemath.org/ticket/8896#comment:3
https://trac.sagemath.org/ticket/8896#comment:3
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
</ul>
TicketjasonWed, 26 May 2010 15:22:22 GMTcc set
https://trac.sagemath.org/ticket/8896#comment:4
https://trac.sagemath.org/ticket/8896#comment:4
<ul>
<li><strong>cc</strong>
<em>jason</em> added
</li>
</ul>
TicketkcrismanWed, 26 May 2010 18:02:42 GMTstatus changed
https://trac.sagemath.org/ticket/8896#comment:5
https://trac.sagemath.org/ticket/8896#comment:5
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Looks okay in general, but the last block
</p>
<pre class="wiki">else:
# Must be 0.00000000000000...0
sigfigs = len(mantissa)
</pre><p>
needs to be indented, n'est pas?
</p>
<p>
In the tests, there should be (brief) words to the effect that the first two have the default minimum precision and that is what is being tested for, while in the new tests we are testing for getting high precision.
</p>
TicketleifThu, 27 May 2010 13:59:08 GMT
https://trac.sagemath.org/ticket/8896#comment:6
https://trac.sagemath.org/ticket/8896#comment:6
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/8896#comment:5" title="Comment 5">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Looks okay in general, but the last block
</p>
<pre class="wiki">else:
# Must be 0.00000000000000...0
sigfigs = len(mantissa)
</pre><p>
needs to be indented, n'est pas?
</p>
</blockquote>
<p>
No, the <code>else</code> belongs to the <code>for</code> statement.
But currently, <em>leading</em> zeros contribute to the precision, too: :)
</p>
<pre class="wiki">sage: RealNumber(0.000000000000000000).prec()
67
sage: RealNumber(00.000000000000000000).prec()
70
sage: RealNumber(.000000000000000000).prec()
64
</pre><p>
I'm not sure if this is intentional, it's at least uncommon.
(And a leading <code>+</code> also increases the precision.)
</p>
<p>
It looks as if a decimal point is counted as a significant digit.
</p>
<p>
And, sorry, the code is extremely ugly (not due to the patch) and inefficient.
Examples and parameter description can be improved as well.
</p>
<p>
I'm not quite sure what kind of strings actually get in (i.e., where/if illegal syntax is catched, it seems all is left to <code>RealNumber._set()</code> if not already handled by the parser), this should perhaps be documented, too.
</p>
TicketleifThu, 27 May 2010 15:03:06 GMT
https://trac.sagemath.org/ticket/8896#comment:7
https://trac.sagemath.org/ticket/8896#comment:7
<p>
Also, is it intentional that the exponent is ignored when computing the required precision?
E.g., <code>1.0e-1000000000</code> as well as <code>1.0e-10000000000</code> evaluate to zero, because of only 53 bits precision.
</p>
TicketleifThu, 27 May 2010 16:01:29 GMT
https://trac.sagemath.org/ticket/8896#comment:8
https://trac.sagemath.org/ticket/8896#comment:8
<p>
<code>sage.rings.complex_number.create_ComplexNumber()</code> also needs work.
</p>
<p>
(It doesn't "strip" trailing/fractional zeros, but also doesn't treat a given exponent correctly. Bases (other than 10) aren't supported; perhaps it should just call <code>create_RealNumber()</code> or use the same code to compute the necessary precision once this operates as desired.)
</p>
TicketrobertwbThu, 27 May 2010 18:48:51 GMTattachment set
https://trac.sagemath.org/ticket/8896
https://trac.sagemath.org/ticket/8896
<ul>
<li><strong>attachment</strong>
set to <em>8896-part2.patch</em>
</li>
</ul>
<p>
apply on top of previous
</p>
TicketrobertwbThu, 27 May 2010 18:51:01 GMTstatus changed
https://trac.sagemath.org/ticket/8896#comment:9
https://trac.sagemath.org/ticket/8896#comment:9
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/8896#comment:6" title="Comment 6">leif</a>:
</p>
<blockquote class="citation">
<p>
No, the <code>else</code> belongs to the <code>for</code> statement.
</p>
</blockquote>
<p>
Exactly.
</p>
<blockquote class="citation">
<p>
But currently, <em>leading</em> zeros contribute to the precision, too: :)
</p>
<pre class="wiki">sage: RealNumber(0.000000000000000000).prec()
67
sage: RealNumber(00.000000000000000000).prec()
70
sage: RealNumber(.000000000000000000).prec()
64
</pre><p>
I'm not sure if this is intentional, it's at least uncommon.
</p>
</blockquote>
<p>
That's the point of this ticket. For 0, all zeros are leading.
</p>
<blockquote class="citation">
<p>
(And a leading <code>+</code> also increases the precision.)
</p>
<p>
It looks as if a decimal point is counted as a significant digit.
</p>
</blockquote>
<p>
Good catch, fixed. That required some adjustment to keep the input/str in sync.
</p>
<blockquote class="citation">
<p>
And, sorry, the code is extremely ugly (not due to the patch) and inefficient.
Examples and parameter description can be improved as well.
</p>
<p>
I'm not quite sure what kind of strings actually get in (i.e., where/if illegal syntax is catched, it seems all is left to <code>RealNumber._set()</code> if not already handled by the parser), this should perhaps be documented, too.
</p>
</blockquote>
<p>
Updated the docstring a bit. This is mostly for use by the preparser, though of course it gets used directly as well.
</p>
TicketrobertwbThu, 27 May 2010 18:52:59 GMT
https://trac.sagemath.org/ticket/8896#comment:10
https://trac.sagemath.org/ticket/8896#comment:10
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/8896#comment:7" title="Comment 7">leif</a>:
</p>
<blockquote class="citation">
<p>
Also, is it intentional that the exponent is ignored when computing the required precision?
E.g., <code>1.0e-1000000000</code> as well as <code>1.0e-10000000000</code> evaluate to zero, because of only 53 bits precision.
</p>
</blockquote>
<p>
Yes, of course. The size of the exponent is completely orthogonal to the number of significant figures. I made create_ComplexNumber defer to create_RealNumber as well.
</p>
TicketkcrismanThu, 27 May 2010 19:29:04 GMT
https://trac.sagemath.org/ticket/8896#comment:11
https://trac.sagemath.org/ticket/8896#comment:11
<blockquote class="citation">
<blockquote class="citation">
<p>
No, the <code>else</code> belongs to the <code>for</code> statement.
</p>
</blockquote>
<p>
Exactly.
</p>
</blockquote>
<p>
<a class="ext-link" href="http://docs.python.org/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops"><span class="icon"></span>Here</a> is the reference for this - I hadn't seen that before. Thanks for the additional docstring.
</p>
TicketleifThu, 27 May 2010 23:00:20 GMT
https://trac.sagemath.org/ticket/8896#comment:12
https://trac.sagemath.org/ticket/8896#comment:12
<p>
Just took a first glance:
</p>
<ul><li><code>create_ComplexNumber()</code> now looks nice
</li><li>in the above function, it's <code>len<15</code> instead of <code>len<=15</code>
</li><li><code>min_prec</code> can be smaller than 53 (if specified)
</li><li><code>pad</code> should be (tested to be) non-negative
</li><li>(<code>min_prec</code> perhaps too, or <code>min_prec+pad>=0</code>)
</li><li>compare against <code>min_prec+pad</code> rather than individually for the "common" case
</li><li><code>rnd</code> description in <code>create_RealNumber()</code> is slightly messed up
</li><li>IMHO leading zeros <strong>left to the decimal point</strong> should be stripped/ignored
</li></ul><p>
More to come... ;-)
</p>
<p>
(I've only looked at the patch to the patch.)
</p>
TicketleifThu, 27 May 2010 23:26:56 GMT
https://trac.sagemath.org/ticket/8896#comment:13
https://trac.sagemath.org/ticket/8896#comment:13
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/8896#comment:9" title="Comment 9">robertwb</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/8896#comment:6" title="Comment 6">leif</a>:
</p>
<blockquote class="citation">
<p>
But currently, <em>leading</em> zeros contribute to the precision, too: :)
</p>
<pre class="wiki">sage: RealNumber(0.000000000000000000).prec()
67
sage: RealNumber(00.000000000000000000).prec()
70
sage: RealNumber(.000000000000000000).prec()
64
</pre><p>
I'm not sure if this is intentional, it's at least uncommon.
</p>
</blockquote>
<p>
That's the point of this ticket. For 0, all zeros are leading.
</p>
</blockquote>
<p>
Not really. We were (only I think) considering zeros of the <strong>fractional</strong> part.
</p>
<p>
Truncation only makes sense from the right; and you don't express precision by padding zeros to the left. Stating that the earth's diameter is about 013 million meters doesn't give more information than stating it is about 13 million meters.
</p>
<blockquote class="citation">
<p>
Updated the docstring a bit. This is mostly for use by the preparser, though of course it gets used directly as well.
</p>
</blockquote>
<p>
I was thinking of scientific notation syntax, too. (Also the examples do not contain that form.)
</p>
TicketleifThu, 27 May 2010 23:40:39 GMT
https://trac.sagemath.org/ticket/8896#comment:14
https://trac.sagemath.org/ticket/8896#comment:14
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/8896#comment:13" title="Comment 13">leif</a>:
</p>
<blockquote class="citation">
<p>
Not really. We were (only I think) considering zeros of the <strong>fractional</strong> part.
</p>
</blockquote>
<p>
To be more precise, 0.0 and 00.0 denote the same "thing", i.e. have the same meaning, while 0.0 and 0.00 do not.
</p>
TicketjasonFri, 28 May 2010 00:14:36 GMT
https://trac.sagemath.org/ticket/8896#comment:15
https://trac.sagemath.org/ticket/8896#comment:15
<p>
For those interested in printing real numbers in general, I'll just plug <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/7682" title="enhancement: Customize printing of real numbers (needs_work)">#7682</a>, which could use just a bit of polishing work, I believe, and makes printing real/complex numbers much more consistent and easy to adjust.
</p>
TicketleifFri, 28 May 2010 01:00:13 GMT
https://trac.sagemath.org/ticket/8896#comment:16
https://trac.sagemath.org/ticket/8896#comment:16
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/8896#comment:10" title="Comment 10">robertwb</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/8896#comment:7" title="Comment 7">leif</a>:
</p>
<blockquote class="citation">
<p>
Also, is it intentional that the exponent is ignored when computing the required precision?
E.g., <code>1.0e-1000000000</code> as well as <code>1.0e-10000000000</code> evaluate to zero, because of only 53 bits precision.
</p>
</blockquote>
<p>
Yes, of course. The size of the exponent is completely orthogonal to the number of significant figures.
</p>
</blockquote>
<p>
I don't agree either. If the "effective" exponent (the one in normalized form) exceeds the maximum, one should either increase <code>prec</code> accordingly or - more practical - raise an exception.
</p>
<p>
If not, this could be a pitfall. But <strong>I</strong> don't mind... ;-)
</p>
TicketrobertwbFri, 28 May 2010 06:24:27 GMT
https://trac.sagemath.org/ticket/8896#comment:17
https://trac.sagemath.org/ticket/8896#comment:17
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/8896#comment:13" title="Comment 13">leif</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/8896#comment:9" title="Comment 9">robertwb</a>:
</p>
<blockquote class="citation">
<p>
That's the point of this ticket. For 0, all zeros are leading.
</p>
</blockquote>
<p>
Not really. We were (only I think) considering zeros of the <strong>fractional</strong> part.
</p>
<p>
Truncation only makes sense from the right; and you don't express precision by padding zeros to the left. Stating that the earth's diameter is about 013 million meters doesn't give more information than stating it is about 13 million meters.
</p>
</blockquote>
<p>
Which has the same information as saying the Earth's diameter is about 0.000013 trillion meters. Whether or not a digit is significant is not a function of whether it is on the left or right of the decimal.
</p>
<p>
Would you then say that <code>0.00e9</code> and <code>00.0e8</code> and <code>.000e10</code> have different precisions?
</p>
TicketrobertwbFri, 28 May 2010 06:33:26 GMT
https://trac.sagemath.org/ticket/8896#comment:18
https://trac.sagemath.org/ticket/8896#comment:18
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/8896#comment:12" title="Comment 12">leif</a>:
</p>
<blockquote class="citation">
<p>
Just took a first glance:
</p>
<ul><li><code>create_ComplexNumber()</code> now looks nice
</li><li>in the above function, it's <code>len<15</code> instead of <code>len<=15</code>
</li></ul></blockquote>
<p>
Ah, oops.
</p>
<blockquote class="citation">
<ul><li><code>min_prec</code> can be smaller than 53 (if specified)
</li></ul></blockquote>
<p>
Yes, but I'm not following what you're trying to say here.
</p>
<blockquote class="citation">
<ul><li><code>pad</code> should be (tested to be) non-negative
</li><li>(<code>min_prec</code> perhaps too, or <code>min_prec+pad>=0</code>)
</li><li>compare against <code>min_prec+pad</code> rather than individually for the "common" case
</li></ul></blockquote>
<p>
I don't care if pad is negative (I'll fix the docstring). Same with min_prec, I just pass whatever I get onto the <a class="missing wiki">RealField?</a> constructor which will raise a perfectly fine exception if the precision is not valid (as defined by MPFR_MIN_PREC and MPFR_MAX_PREC).
</p>
<blockquote class="citation">
<ul><li><code>rnd</code> description in <code>create_RealNumber()</code> is slightly messed up
</li></ul></blockquote>
<p>
Ah, I'll fix that.
</p>
<blockquote class="citation">
<blockquote class="citation">
<blockquote class="citation">
<p>
E.g., <code>1.0e-1000000000</code> as well as <code>1.0e-10000000000</code> evaluate to zero, because of only 53 bits precision.
</p>
</blockquote>
<p>
Yes, of course. The size of the exponent is completely orthogonal to the number of significant figures.
</p>
</blockquote>
<p>
I don't agree either. If the "effective" exponent (the one in normalized form) exceeds the maximum, one should either increase <code>prec</code> accordingly or - more practical - raise an exception.
</p>
<p>
If not, this could be a pitfall. But <strong>I</strong> don't mind... ;-)
</p>
</blockquote>
<p>
Well, I'd say the above has only two significant digits of precision, no matter what the exponent, which is all this function tries to deduce. The fact that it's subnormal is outside of the scope of this ticket--if an exception should be raise it's not here. (And in this case you can't raise the precision enough, due to memory/library limitations.)
</p>
TicketleifFri, 28 May 2010 09:28:00 GMT
https://trac.sagemath.org/ticket/8896#comment:19
https://trac.sagemath.org/ticket/8896#comment:19
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/8896#comment:18" title="Comment 18">robertwb</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/8896#comment:12" title="Comment 12">leif</a>:
</p>
<blockquote class="citation">
<ul><li><code>min_prec</code> can be smaller than 53 (if specified)
</li></ul></blockquote>
<p>
Yes, but I'm not following what you're trying to say here.
</p>
<blockquote class="citation">
<ul><li><code>pad</code> should be (tested to be) non-negative
</li><li>(<code>min_prec</code> perhaps too, or <code>min_prec+pad>=0</code>)
</li><li>compare against <code>min_prec+pad</code> rather than individually for the "common" case
</li></ul></blockquote>
<p>
I don't care if pad is negative (I'll fix the docstring). Same with min_prec, I just pass whatever I get onto the <a class="missing wiki">RealField?</a> constructor which will raise a perfectly fine exception if the precision is not valid (as defined by MPFR_MIN_PREC and MPFR_MAX_PREC).
</p>
</blockquote>
<p>
If you test for <code>min_prec+pad==53 and ...</code>, more inputs fall into the simple common case (<code>RR</code>).
(Using <code>RR</code>, i.e. 53 bit mantissa, if the sum is <em>less</em> than 53 is perhaps not desired.)
</p>
TicketleifFri, 28 May 2010 12:47:02 GMT
https://trac.sagemath.org/ticket/8896#comment:20
https://trac.sagemath.org/ticket/8896#comment:20
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/8896#comment:19" title="Comment 19">leif</a>:
</p>
<blockquote class="citation">
<p>
(Using <code>RR</code>, i.e. 53 bit mantissa, if the sum is <em>less</em> than 53 is perhaps not desired.)
</p>
</blockquote>
<p>
Must have been some spot on the screen that covered <code>min_</code>... ;-)
</p>
<p>
Of course it's pretty ok to return <code>RR</code> in that case, too. (If someone really wants <em>less</em> precision, he can use <code>RealField(prec)("...")</code> directly.)
</p>
TicketrobertwbWed, 26 Jan 2011 06:43:41 GMTattachment set
https://trac.sagemath.org/ticket/8896
https://trac.sagemath.org/ticket/8896
<ul>
<li><strong>attachment</strong>
set to <em>8896-doctests.patch</em>
</li>
</ul>
TicketrobertwbWed, 26 Jan 2011 06:44:11 GMT
https://trac.sagemath.org/ticket/8896#comment:21
https://trac.sagemath.org/ticket/8896#comment:21
<p>
Doctest fixes for 4.6.1.
</p>
TicketrobertwbTue, 31 May 2011 07:03:39 GMTattachment set
https://trac.sagemath.org/ticket/8896
https://trac.sagemath.org/ticket/8896
<ul>
<li><strong>attachment</strong>
set to <em>8896-rebased.patch</em>
</li>
</ul>
<p>
Folded and rebased on 4.7. Apply only this patch.
</p>
TicketmariahMon, 06 Jun 2011 17:38:28 GMTstatus changed; reviewer, author set
https://trac.sagemath.org/ticket/8896#comment:22
https://trac.sagemath.org/ticket/8896#comment:22
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
set to <em>Mariah Lenox</em>
</li>
<li><strong>author</strong>
set to <em>Robert Bradshaw</em>
</li>
</ul>
<p>
Patch fixes problem. Ran 'make testlong'. All tests passed. Positive review!
</p>
TicketrobertwbMon, 06 Jun 2011 17:47:41 GMT
https://trac.sagemath.org/ticket/8896#comment:23
https://trac.sagemath.org/ticket/8896#comment:23
<p>
Thanks!
</p>
TicketjdemeyerWed, 08 Jun 2011 07:23:47 GMTdescription changed
https://trac.sagemath.org/ticket/8896#comment:24
https://trac.sagemath.org/ticket/8896#comment:24
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/8896?action=diff&version=24">diff</a>)
</li>
</ul>
TicketjdemeyerWed, 08 Jun 2011 07:32:18 GMTstatus changed
https://trac.sagemath.org/ticket/8896#comment:25
https://trac.sagemath.org/ticket/8896#comment:25
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_info</em>
</li>
</ul>
<p>
In my opinion, this ticket is a huge can of worms and a bad idea. I don't see any mathematically consistent reason who 0.0 <strong>should</strong> be treated differently than 0.0000000000000.
</p>
<p>
I really think the current behaviour of Sage is what makes the most sense (mathematically) so I am not in favour of this ticket. Of course, if the majority thinks this patch is a good idea then I'm all for it.
</p>
<p>
One thing about the patch which is very unclear is why zero is treated differently from other numbers. Consider::
</p>
<pre class="wiki">sage: (0.0).prec()
53
sage: (0.1).prec()
53
sage: (000000000000000000000.0).prec()
77
sage: (000000000000000000000.1).prec()
53
sage: (0.000000000000000000000).prec()
77
sage: (0.000000000000000000001).prec()
53
</pre>
TicketrobertwbWed, 08 Jun 2011 15:41:09 GMT
https://trac.sagemath.org/ticket/8896#comment:26
https://trac.sagemath.org/ticket/8896#comment:26
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/8896#comment:25" title="Comment 25">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
In my opinion, this ticket is a huge can of worms and a bad idea. I don't see any mathematically consistent reason who 0.0 <strong>should</strong> be treated differently than 0.0000000000000.
</p>
</blockquote>
<p>
It's exactly the same reason that 1.0 is treated differently than 1.0000000000000000000000. The (value-preserving) trailing zeros indicate higher precision.
</p>
<blockquote class="citation">
<p>
I really think the current behaviour of Sage is what makes the most sense (mathematically) so I am not in favour of this ticket. Of course, if the majority thinks this patch is a good idea then I'm all for it.
</p>
<p>
One thing about the patch which is very unclear is why zero is treated differently from other numbers.
</p>
</blockquote>
<p>
Because otherwise there's now way to write a high-precision zero (in fact I can't think of any other interpretation of a large number of trailing zeros).
</p>
<blockquote class="citation">
<p>
Consider::
</p>
<pre class="wiki">sage: (0.0).prec()
53
sage: (0.1).prec()
53
sage: (000000000000000000000.0).prec()
77
sage: (000000000000000000000.1).prec()
53
sage: (0.000000000000000000000).prec()
77
sage: (0.000000000000000000001).prec()
53
</pre></blockquote>
TicketkcrismanWed, 08 Jun 2011 15:56:54 GMT
https://trac.sagemath.org/ticket/8896#comment:27
https://trac.sagemath.org/ticket/8896#comment:27
<p>
Another argument is that the BDFL suggested this change fairly strongly when opening this ticket :)
</p>
<p>
More seriously, I do have a question here.
Robert's reasoning seems sound in the following example - we want a high-precision zero, and this is the best way to acquire it.
</p>
<pre class="wiki">> sage: (0.000000000000000000000).prec()
> 77
> sage: (0.000000000000000000001).prec()
> 53
</pre><p>
But I agree with Jeroen that the following seems problematic. Didn't you say yourself (robertwb) that leading zeros <em>before</em> the decimal point shouldn't make a difference? So in the case here maybe we should have the default precision...
</p>
<pre class="wiki">> sage: (000000000000000000000.0).prec()
> 77
> sage: (000000000000000000000.1).prec()
> 53
</pre><p>
Keeping in mind that I have very little invested in either outcome for now, so take these only as observations.
</p>
TicketjdemeyerWed, 08 Jun 2011 16:01:57 GMT
https://trac.sagemath.org/ticket/8896#comment:28
https://trac.sagemath.org/ticket/8896#comment:28
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/8896#comment:26" title="Comment 26">robertwb</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/8896#comment:25" title="Comment 25">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
In my opinion, this ticket is a huge can of worms and a bad idea. I don't see any mathematically consistent reason who 0.0 <strong>should</strong> be treated differently than 0.0000000000000.
</p>
</blockquote>
<p>
It's exactly the same reason that 1.0 is treated differently than 1.0000000000000000000000. The (value-preserving) trailing zeros indicate higher precision.
</p>
</blockquote>
<p>
It is absolutely <em>not the same</em> because with non-zero numbers only digits <strong>after</strong> a non-zero digit contribute to the precision. Indeed, <code>0.437</code> and <code>0.00000000000437</code> have exactly the same precision.
</p>
<blockquote class="citation">
<p>
Because otherwise there's now way to write a high-precision zero (in fact I can't think of any other interpretation of a large number of trailing zeros).
</p>
</blockquote>
<p>
Well, you can always do:
</p>
<pre class="wiki">sage: zero = RealField(1000)(0)
sage: zero.prec()
1000
</pre><p>
An other way to demonstrate the problem with this patch is that truncating decimal numbers (i.e. removing digits from the right) can <em>increase</em> the precision, which is very unlogical::
</p>
<pre class="wiki">sage: (0.000000000000000000001234567890123456789).prec()
67
sage: (0.00000000000000000000123456789012345678).prec()
64
sage: (0.000000000000000000001).prec()
53
sage: (0.00000000000000000000).prec()
74
</pre>
TicketrobertwbWed, 08 Jun 2011 16:19:58 GMT
https://trac.sagemath.org/ticket/8896#comment:29
https://trac.sagemath.org/ticket/8896#comment:29
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/8896#comment:28" title="Comment 28">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/8896#comment:26" title="Comment 26">robertwb</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/8896#comment:25" title="Comment 25">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
In my opinion, this ticket is a huge can of worms and a bad idea. I don't see any mathematically consistent reason who 0.0 <strong>should</strong> be treated differently than 0.0000000000000.
</p>
</blockquote>
<p>
It's exactly the same reason that 1.0 is treated differently than 1.0000000000000000000000. The (value-preserving) trailing zeros indicate higher precision.
</p>
</blockquote>
<p>
It is absolutely <em>not the same</em> because with non-zero numbers only digits <strong>after</strong> a non-zero digit contribute to the precision. Indeed, <code>0.437</code> and <code>0.00000000000437</code> have exactly the same precision.
</p>
</blockquote>
<p>
This hinges on the ambiguity of the term "trialing zero." Sage interprets trailing zeros after the decimal point as additional precision. To me, trailing zeros are those that are not followed by a non-zero digit, to you trailing zeros must also follow a non-zero digit.
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
Because otherwise there's now way to write a high-precision zero (in fact I can't think of any other interpretation of a large number of trailing zeros).
</p>
</blockquote>
<p>
Well, you can always do:
</p>
<pre class="wiki">sage: zero = RealField(1000)(0)
sage: zero.prec()
1000
</pre></blockquote>
<p>
Yeah, but that's a pain, but to me the fact that 0.00000000000000000000000000000000 is not high precision is more surprising, as it has many significant digits.
</p>
<blockquote class="citation">
<p>
An other way to demonstrate the problem with this patch is that truncating decimal numbers (i.e. removing digits from the right) can <em>increase</em> the precision, which is very unlogical::
</p>
<pre class="wiki">sage: (0.000000000000000000001234567890123456789).prec()
67
sage: (0.00000000000000000000123456789012345678).prec()
64
sage: (0.000000000000000000001).prec()
53
sage: (0.00000000000000000000).prec()
74
</pre></blockquote>
<p>
It also changes the relative value by a huge amount :)
</p>
<p>
Is it worth taking this discussion to sage-devel?
</p>
TicketjdemeyerWed, 08 Jun 2011 19:07:45 GMT
https://trac.sagemath.org/ticket/8896#comment:30
https://trac.sagemath.org/ticket/8896#comment:30
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/8896#comment:29" title="Comment 29">robertwb</a>:
</p>
<blockquote class="citation">
<p>
to me the fact that 0.00000000000000000000000000000000 is not high precision is more surprising, as it has many significant digits.
</p>
</blockquote>
<p>
I would say that it does have a lot of <em>digits</em> but that none of them is a <em>significant digit</em>.
</p>
TicketjdemeyerTue, 02 Aug 2011 19:32:49 GMTdescription, milestone changed
https://trac.sagemath.org/ticket/8896#comment:31
https://trac.sagemath.org/ticket/8896#comment:31
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/8896?action=diff&version=31">diff</a>)
</li>
<li><strong>milestone</strong>
changed from <em>sage-4.7.1</em> to <em>sage-pending</em>
</li>
</ul>
TicketwasWed, 24 Aug 2011 23:43:21 GMTkeywords set
https://trac.sagemath.org/ticket/8896#comment:32
https://trac.sagemath.org/ticket/8896#comment:32
<ul>
<li><strong>keywords</strong>
<em>sd32</em> added
</li>
</ul>
Ticket