#7682: Customize printing of real numbers
---------------------------+------------------------------------------------
Reporter: jason | Owner: AlexGhitza
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-4.5
Component: numerical | Keywords:
Author: Jason Grout | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
---------------------------+------------------------------------------------
Comment(by jason):
Replying to [comment:32 cwitty]:
> I actually dislike the goal of this patch: I don't think it's a good
idea to have {{{RealNumber}}} printing varied per-parent, and certainly
not if the printing is mutable. Consider:
>
> Somebody wants to know what 128 bits of $\pi$ prints as in scientific
notation:
>
> {{{
> sage: RR128 = RealField(128)
> sage: RR128.print_options['scientific_notation'] = 'always'
> sage: RR128(pi)
> 3.1415926535897932384626433832795028842e0
> }}}
>
> Then, days later (but in the same Sage session) they're playing around
with the internals of AA/QQbar:
>
> {{{
> sage: rt2 = AA(sqrt(2))
> sage: rt2._value.center()
> 1.41421356237309505
> sage: RealIntervalField(100)(rt2)
> 1.414213562373095048801688724210?
> sage: rt2._value.center()
> 1.4142135623730950488016887242096980786e0
> }}}
>
> Why is that last number printed in scientific notation? Oh yes, it's
because we changed RR128 days ago.
>
> I realize that you're just extending a design that's been in Sage for
years (since before I started working on Sage), but IMHO it's a bad
design, and this just makes it worse.
>
> I can think of two ways to fix this:
>
> 1) Get rid of per-field printing options altogether; only have a single
global setting that affects all {{{RealField}}}s.
>
> 2) Make the print options immutable, so that creating
RR128scientific_notation doesn't affect anybody else who might create
RR128 without scientific notation.
>
> My vote would be for option 1, but I could live with either option.
I agree. Another reason to add to your argument above is that Sage does
coercing between different realfield precisions, so you might have a
number that is printed one way, then Sage automatically coerces to a
different precision for an operation and your result is printed a
different way. I think (1) is a better option, given the caching strategy
used.
For my use-case (teaching numerical analysis), option (1) is better than
the patch on this ticket.
So do you propose eliminating the sci_not options to RealField? Do you
propose eliminating the arguments to the str function?
Note that I think your suggestion will be relatively straightforward to
accommodate on this patch, since the patch defines module-level defaults.
We should be able to just remove the code that overrides the module-level
defaults and stores a user value. Note that this patch also unifies
several different options for scientific notation that were scattered in
different places in the code, so I think it is better to build (or cut
things out) on this patch rather than throw it away altogether.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7682#comment:33>
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.
