Opened 9 years ago
Last modified 4 months ago
#7682 needs_work enhancement
Customize printing of real numbers
Reported by: | jason | Owned by: | AlexGhitza |
---|---|---|---|
Priority: | major | Milestone: | sage-6.4 |
Component: | numerical | Keywords: | |
Cc: | robertwb, jkantor, was, kcrisman, egourgoulhon | Merged in: | |
Authors: | Jason Grout | Reviewers: | |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description (last modified by )
From http://groups.google.com/group/sage-support/browse_thread/thread/06756df51d828bf4
we probably ought to make this easier to just print the first n digits after the decimal by default for RR numbers, or to not print out the trailing zeros. I can't imagine telling my students, for example, that they need to do '%.3f'%num every time they come across a number, especially since they just want to display the equation, not format it as a string. What do people think about this interface? sage: RR.print_digits=3 sage: 3.09384 3.094 sage: RR.print_trailing_zeros=False sage: RR.print_digits=None sage: 3.09384 3.09384 Make it something like the RR.scientific_notation flag that is currently in use.
Additionally, and more flexibly, we could just have something like:
sage: RR.set_print_format('%.3f') sage: RR(pi) 3.142
or more pythonically
sage: RR.print_format = '%.3f' sage: RR(pi) 3.142
Edit: the patches below do not allow you to set a C format string or number of digits, but they do provide a framework for setting field-wide printing options, and wrap the current printing options Sage has implemented (plus a few minor extensions, I think).
Attachments (6)
Change History (49)
comment:1 Changed 9 years ago by
comment:2 Changed 9 years ago by
- Milestone changed from sage-4.3 to sage-4.3.1
I'm declaring a total feature freeze on sage-4.3.
comment:3 Changed 9 years ago by
- Cc robertwb added
- Status changed from new to needs_work
Here is a first cut of a print_options model for RealField? that lets you specify default printing options for any RealField?, all RealFields?, and still lets you override the defaults when you actually print the numbers.
It mostly works. Docs need to be updated, deprecation warnings need to be added, and the interface for scientific notation needs to be revamped (no_sci and sci_not are confusing and inconsistent keyword choices!).
comment:4 Changed 9 years ago by
- Cc jkantor added
- Component changed from basic arithmetic to numerical
comment:5 Changed 9 years ago by
comment:6 Changed 9 years ago by
I refreshed the patch which a much more comprehensive patch. This patch fixes all doctests in rings/*.pyx (running long doctests now). Documentation still needs to be updated, though, and some new doctests to test the new functionality.
comment:7 Changed 9 years ago by
Okay, patch passes all (non-long) doctests in Sage.
comment:8 follow-ups: ↓ 11 ↓ 12 Changed 9 years ago by
- Status changed from needs_work to needs_info
Usually rings are supposed to be immutable, but I think this general idea is worth it. As for the interface, setting attributes on RR directly isn't very consistent with the way we do things in Sage--it's probably be better to have a RR.print_options(...) that takes keywords. (This way it could have a nice docstring as well.)
comment:9 Changed 9 years ago by
Thanks for the style review. Okay, I can change print_options to a function, though I don't think it's "better", maybe just more consistent and slightly worse (i.e., unpythonic and more typing)
On another note, I just changed the latexing of a real field to indicate the precision and rounding, so that RealField?(100,rnd='RNDD') prints as \Bold{R}^{{-}_{100}. The subscript is the precision, the superscript is '+' for RNDU, '-' for RNDD, 0 for RNDZ, and nothing for RNDN. What do you think? It mirrors better the textual description of the field that indicates precision and rounding. }
comment:10 Changed 9 years ago by
As for immutability; what if we don't consider the printing options as part of the ring (i.e., it's not part of the hash for the cache, like it is now)? Then a user can temporarily change the ring's printing operations, but none of the printing options are considered in testing for equality, stored in pickles, etc.
comment:11 in reply to: ↑ 8 Changed 9 years ago by
Replying to robertwb:
it's probably be better to have a RR.print_options(...) that takes keywords. (This way it could have a nice docstring as well.)
Yes, but how do you get the value of a specific option (as opposed to setting it).
comment:12 in reply to: ↑ 8 Changed 9 years ago by
Replying to robertwb:
(This way it could have a nice docstring as well.)
The Cython "property" construct can also take a nice docstring. Is anything ever done with this docstring?
Changed 9 years ago by
comment:13 Changed 9 years ago by
Okay, this is getting big now. I went through real_mpfr.pyx and added a lot of doctests and documentation.
There are four doctests failing right now because I'm not sure if they are bugs or if they are right. Here they are:
********************************************************************** File "/home/grout/sage-4.3.1/devel/sage-main/sage/rings/real_mpfr.pyx", line 3343: sage: RR('nan').is_real() # fail until we decide what it should be Expected nothing Got: True ********************************************************************** File "/home/grout/sage-4.3.1/devel/sage-main/sage/rings/real_mpfr.pyx", line 3344: sage: RR('inf').is_real() # fail until we decide what it should be Expected nothing Got: True ********************************************************************** File "/home/grout/sage-4.3.1/devel/sage-main/sage/rings/real_mpfr.pyx", line 3360: sage: RR('nan').__nonzero__() # fail until we decide what it should be Expected nothing Got: False ********************************************************************** File "/home/grout/sage-4.3.1/devel/sage-main/sage/rings/real_mpfr.pyx", line 3397: sage: RR('nan')==RR('nan') # Fail until we decide what it should be Expected nothing Got: True ********************************************************************** File "/home/grout/sage-4.3.1/devel/sage-main/sage/rings/real_mpfr.pyx", line 3419: sage: RR('nan')==RR('nan') # fail until we decide what it should be Expected nothing Got: True
Are those four answers right (the "Got:" parts)? See #8074 for more corner cases.
comment:14 Changed 9 years ago by
- Cc was added
I rebased this patch to apply to 4.3.3 (it conflicted with a big rewrite by was and a small patch by robertwb). The patch touches a lot of areas (and adds lots of doctests!), so a quick review would help avoid having to rebase it again.
comment:15 Changed 9 years ago by
I uploaded a new patch which corrects several doctests; all doctests in Sage now seem to pass with this patch applied.
comment:16 Changed 9 years ago by
- Type changed from defect to enhancement
comment:17 Changed 9 years ago by
- Status changed from needs_info to needs_review
comment:18 Changed 8 years ago by
- Status changed from needs_review to needs_work
I removed a bunch of fixes unrelated to the printing option change and put them on other tickets. I also fixed at least one accidental code removal. In 4.4.1, Sage won't start after this patch is applied, due to
---------------------------------------------------------------------- | Sage Version 4.4.1, Release Date: 2010-05-02 | | Type notebook() for the GUI, and license() for information. | ---------------------------------------------------------------------- init2.c:52: MPFR assertion failed: p >= 2 && p <= ((mpfr_prec_t)((mpfr_prec_t)(~(mpfr_prec_t)0)>>1)) /Users/grout/sage/local/bin/sage-sage: line 206: 16842 Abort trap sage-ipython "$@" -i
Changed 8 years ago by
rebase to 4.4.1, fix startup bug, fix one doctest to test for the startup bug; apply only this patch
comment:19 follow-up: ↓ 20 Changed 8 years ago by
Slightly OT: Regarding the thread that started this, in finance you don't need less/limited precision, but fixed-point numbers. ;-)
comment:20 in reply to: ↑ 19 Changed 8 years ago by
Replying to leif:
Slightly OT: Regarding the thread that started this, in finance you don't need less/limited precision, but fixed-point numbers. ;-)
Of course, then you would probably use the python Decimal module :).
comment:21 Changed 8 years ago by
My reason for initially working on this was for a numerical analysis class, where we wanted to see *all* the digits of the real number, and not just have the last few digits rounded off.
comment:22 Changed 8 years ago by
#9261 asks for one of the features implemented in this patch (setting the printing style for real interval fields).
comment:23 Changed 8 years ago by
After experimenting for a few minutes, it looks like something like #9261 is almost implemented in this patch, but not quite.
comment:24 Changed 8 years ago by
I added a patch which implements the feature wanted in #9261:
sage: R=RealIntervalField(print_options=dict(style='brackets')) sage: R.print_options {'style': 'brackets', 'error_digits': 0} sage: R(1,2) [1.0000000000000000 .. 2.0000000000000000]
Doctests and documentation still needs to be written for this. And maybe convenience functions for setting these two options (i.e., make the syntax in #9261 work).
comment:25 follow-up: ↓ 26 Changed 8 years ago by
Jason,
sorry, I was not aware of this ticket. I see you have invested a lot of time in it. However I am not in favour of removing trailing zeroes by default. Those zeroes are quite helpful to give an idea of the accuracy of the computation.
About reducing or increasing the number of printed zeroes with respect to the internal precision, I don't see why this could be desirable. If we reduce the number of printed zeroes, then if we copy/paste the number, we will loose some accuracy (because of the decimal<->binary conversion). If we increase the number of printed zeroes, the user will see more significant digits (due to the internal binary representation) and this will lead to more user questions:
sage: a=n(pi); a 3.14159265358979 sage: print '%.3f'%a 3.142 sage: b=3.142; a-b -0.000407346410206788 sage: print '%.30f'%a 3.141592653589793115997963468544
In addition I don't understand how you achieve this:
sage: RR.print_trailing_zeros=False sage: RR.print_digits=None sage: 3.09384 3.09384
What happens with RR.print_digits=16
?
Also, what happens with numbers with tiny or huge exponent, say 3.09384e-100
or
3.09384e+100
?
Just my 2 cents.
Paul
PS: however, the patch for #9261 looks very nice. Can't you make it independent of that ticket?
comment:26 in reply to: ↑ 25 Changed 8 years ago by
Replying to zimmerma:
Jason,
sorry, I was not aware of this ticket. I see you have invested a lot of time in it. However I am not in favour of removing trailing zeroes by default. Those zeroes are quite helpful to give an idea of the accuracy of the computation.
I agree. That's the default in Sage now, though (and led to this patch, as it was hiding too much in my numerical analysis class!)
So changing it should probably be a different ticket, and after this patch, should just be a one liner change to the defaults.
About reducing or increasing the number of printed zeroes with respect to the internal precision, I don't see why this could be desirable. If we reduce the number of printed zeroes, then if we copy/paste the number, we will loose some accuracy (because of the decimal<->binary conversion). If we increase the number of printed zeroes, the user will see more significant digits (due to the internal binary representation) and this will lead to more user questions:
sage: a=n(pi); a 3.14159265358979 sage: print '%.3f'%a 3.142 sage: b=3.142; a-b -0.000407346410206788 sage: print '%.30f'%a 3.141592653589793115997963468544In addition I don't understand how you achieve this:
sage: RR.print_trailing_zeros=False sage: RR.print_digits=None sage: 3.09384 3.09384What happens with
RR.print_digits=16
?Also, what happens with numbers with tiny or huge exponent, say
3.09384e-100
or3.09384e+100
?
Good questions. It's been a while since I worked with this patch (other than the rough patch from yesterday). I'll try to see what changes are changes I made, as opposed to what things were already in Sage. The things that were already in Sage can be dealt with on another ticket.
Just my 2 cents.
Paul
PS: however, the patch for #9261 looks very nice. Can't you make it independent of that ticket?
Yes, though it's easier to build on top of the framework here, and I hope better in the long run.
comment:27 Changed 8 years ago by
Applying these patches to 4.4.2 gives several doctest errors like this:
sage -t "4.4.2-test3/devel/sage-main/sage/rings/rational_field.py" ********************************************************************** File "/Users/grout/sage-4.4.2-test3/devel/sage-main/sage/rings/rational_field.py", line 26: sage: QQ(RealField(9).pi()) Exception raised: Traceback (most recent call last): File "/Users/grout/sage/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/Users/grout/sage/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/Users/grout/sage/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_0[4]>", line 1, in <module> QQ(RealField(Integer(9)).pi())###line 26: sage: QQ(RealField(9).pi()) File "parent.pyx", line 854, in sage.structure.parent.Parent.__call__ (sage/structure/parent.c:6332) File "coerce_maps.pyx", line 82, in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (sage/structure/coerce_maps.c:3108) File "coerce_maps.pyx", line 77, in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (sage/structure/coerce_maps.c:3010) File "rational.pyx", line 367, in sage.rings.rational.Rational.__init__ (sage/rings/rational.c:5781) self.__set_value(x, base) File "rational.pyx", line 455, in sage.rings.rational.Rational.__set_value (sage/rings/rational.c:6223) set_from_Rational(self, x.simplest_rational()) File "real_mpfr.pyx", line 2762, in sage.rings.real_mpfr.RealNumber.simplest_rational (sage/rings/real_mpfr.c:17811) return hp_intv.simplest_rational(low_open=odd, high_open=odd) File "real_mpfi.pyx", line 2742, in sage.rings.real_mpfi.RealIntervalFieldElement.simplest_rational (sage/rings/real_mpfi.c:14640) highprec = RealIntervalField_class(int(self.prec() * 1.2))(self) File "real_mpfi.pyx", line 472, in sage.rings.real_mpfi.RealIntervalField_class.__init__ (sage/rings/real_mpfi.c:3522) for key,val in print_options.items(): AttributeError: 'NoneType' object has no attribute 'items'
comment:28 Changed 8 years ago by
It appears that the problem above occurs with just the last patch.
comment:29 follow-up: ↓ 31 Changed 8 years ago by
- Description modified (diff)
Paul: I think I understand your comment now. I did not implement the original suggestion, but instead provided a framework for field-wide printing options and just wrapped what Sage currently provides. You bring up some good questions about the design which are out of scope for the current patch attached. Given this, I think it would be best to either change the scope of the ticket to reflect what the patch actually does, or make a new ticket for the patch and keep this ticket around for a design discussion of how (or whether it is desirable!) to implement the features described in the description.
comment:30 Changed 8 years ago by
- Description modified (diff)
comment:31 in reply to: ↑ 29 Changed 8 years ago by
Replying to jason:
it would be best to either change the scope of the ticket to reflect what the patch actually does
I would prefer this.
Paul
comment:32 follow-up: ↓ 33 Changed 8 years ago by
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.
comment:33 in reply to: ↑ 32 Changed 8 years ago by
Replying to 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.1415926535897932384626433832795028842e0Then, 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.4142135623730950488016887242096980786e0Why 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.
comment:34 Changed 8 years ago by
So do you propose eliminating the sci_not options to RealField??? Do you propose eliminating the arguments to the str function?
Yes, my vote would be to eliminate sci_not in RealField
. No, I don't see any reason to eliminate the arguments to str(); if you want to convert a single number to a string in some special way (with scientific notation, say), then it's a lot easier to call .str(scientific_notation='always') than to type something like:
old = sage.rings.real_mpfr._PRINT_OPTIONS['scientific_notation'] sage.rings.real_mpfr._PRINT_OPTIONS['scientific_notation'] = 'always' foostr = foo.str() sage.rings.real_mpfr._PRINT_OPTIONS['scientific_notation'] = old
Further comments:
I haven't really reviewed the actual patch, but I did just notice that the new docstring for .str() has no doctests for no_sci. I think it should end with something like:
TESTS: Here we test the deprecated no_sci argument to .str()::
followed by the tests for no_sci that used to be there (assuming there were some, I haven't actually checked).
comment:35 Changed 7 years ago by
ping (?)
comment:36 Changed 7 years ago by
pong. I would love to see this ticket resolved, but as you can see, there is another major rewrite needed before it is ready.
comment:37 Changed 6 years ago by
- Cc kcrisman added
comment:38 Changed 5 years ago by
- Milestone changed from sage-5.11 to sage-5.12
comment:39 Changed 5 years ago by
- Milestone changed from sage-6.1 to sage-6.2
comment:40 Changed 4 years ago by
- Milestone changed from sage-6.2 to sage-6.3
comment:41 Changed 4 years ago by
- Milestone changed from sage-6.3 to sage-6.4
comment:42 Changed 4 months ago by
How lovely to revive an 8 year old ticket ...
In the mean time, python has grown a new string formatting method. If we implement a __format__
method on our mpfr wrapper, one could just do something like
sage: a=RealField(200)(2).sqrt() sage: "{:.20e}".format(a) '1.414213562373095049e0'
No need to fuss with global state ... if people want more control over the typesetting of their floats, they can just use the standard python tools (or the tools already available on str
).
It might be a nice beginner's exercise to write the appropriate __format__
.
comment:43 Changed 4 months ago by
- Cc egourgoulhon added
Note that these extra zeros were introduced in the printing by the switch to pynac. They were eliminated a while ago in maxima by #4572.