#8896: 0.0000000000000000000000000000 is parsed completely differently than
1.0000000000000000000000000000 for no good reason
--------------------------------+-------------------------------------------
Reporter: was | Owner: AlexGhitza
Type: defect | Status: needs_review
Priority: minor | Milestone: sage-4.4.3
Component: basic arithmetic | Keywords:
Author: | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
--------------------------------+-------------------------------------------
Comment(by robertwb):
Replying to [comment:12 leif]:
> Just took a first glance:
>
> * {{{create_ComplexNumber()}}} now looks nice
> * in the above function, it's {{{len<15}}} instead of {{{len<=15}}}
Ah, oops.
> * {{{min_prec}}} can be smaller than 53 (if specified)
Yes, but I'm not following what you're trying to say here.
> * {{{pad}}} should be (tested to be) non-negative
> * ({{{min_prec}}} perhaps too, or {{{min_prec+pad>=0}}})
> * compare against {{{min_prec+pad}}} rather than individually for the
"common" case
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 RealField constructor which
will raise a perfectly fine exception if the precision is not valid (as
defined by MPFR_MIN_PREC and MPFR_MAX_PREC).
> * {{{rnd}}} description in {{{create_RealNumber()}}} is slightly messed
up
Ah, I'll fix that.
> > > E.g., {{{1.0e-1000000000}}} as well as {{{1.0e-10000000000}}}
evaluate to zero, because of only 53 bits precision.
> >
> > Yes, of course. The size of the exponent is completely orthogonal to
the number of significant figures.
>
> I don't agree either. If the "effective" exponent (the one in normalized
form) exceeds the maximum, one should either increase {{{prec}}}
accordingly or - more practical - raise an exception.
>
> If not, this could be a pitfall. But '''I''' don't mind... ;-)
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.)
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/8896#comment:18>
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.
