#8896: 0.0000000000000000000000000000 is parsed completely differently than
1.0000000000000000000000000000 for no good reason
--------------------------------+-------------------------------------------
   Reporter:  was               |          Owner:  AlexGhitza     
       Type:  defect            |         Status:  needs_info     
   Priority:  minor             |      Milestone:  sage-4.7.1     
  Component:  basic arithmetic  |       Keywords:                 
Work_issues:                    |       Upstream:  N/A            
   Reviewer:  Mariah Lenox      |         Author:  Robert Bradshaw
     Merged:                    |   Dependencies:                 
--------------------------------+-------------------------------------------

Comment(by robertwb):

 Replying to [comment:28 jdemeyer]:
 > Replying to [comment:26 robertwb]:
 > > Replying to [comment:25 jdemeyer]:
 > > > 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 '''should''' be
 treated differently than 0.0000000000000.
 > >
 > > It's exactly the same reason that 1.0 is treated differently than
 1.0000000000000000000000. The (value-preserving) trailing zeros indicate
 higher precision.
 > It is absolutely ''not the same'' because with non-zero numbers only
 digits '''after''' a non-zero digit contribute to the precision.  Indeed,
 `0.437` and `0.00000000000437` have exactly the same precision.

 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.

 > > 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).
 > Well, you can always do:
 > {{{
 > sage: zero = RealField(1000)(0)
 > sage: zero.prec()
 > 1000
 > }}}

 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.

 > An other way to demonstrate the problem with this patch is that
 truncating decimal numbers (i.e. removing digits from the right) can
 ''increase'' the precision, which is very unlogical::
 > {{{
 > sage: (0.000000000000000000001234567890123456789).prec()
 > 67
 > sage: (0.00000000000000000000123456789012345678).prec()
 > 64
 > sage: (0.000000000000000000001).prec()
 > 53
 > sage: (0.00000000000000000000).prec()
 > 74
 > }}}

 It also changes the relative value by a huge amount :)

 Is it worth taking this discussion to sage-devel?

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/8896#comment:29>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica, 
and MATLAB

-- 
You received this message because you are subscribed to the Google Groups 
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sage-trac?hl=en.

Reply via email to