Sage: Ticket #7682: Customize printing of real numbers
https://trac.sagemath.org/ticket/7682
<p>
From <a class="ext-link" href="http://groups.google.com/group/sage-support/browse_thread/thread/06756df51d828bf4"><span class="icon"></span>http://groups.google.com/group/sage-support/browse_thread/thread/06756df51d828bf4</a>
</p>
<pre class="wiki">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.
</pre><p>
Additionally, and more flexibly, we could just have something like:
</p>
<pre class="wiki">
sage: RR.set_print_format('%.3f')
sage: RR(pi)
3.142
</pre><p>
or more pythonically
</p>
<pre class="wiki">sage: RR.print_format = '%.3f'
sage: RR(pi)
3.142
</pre><p>
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).
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/7682
Trac 1.1.6jasonMon, 14 Dec 2009 20:29:37 GMT
https://trac.sagemath.org/ticket/7682#comment:1
https://trac.sagemath.org/ticket/7682#comment:1
<p>
Note that these extra zeros were introduced in the printing by the switch to pynac. They were eliminated a while ago in maxima by <a class="closed ticket" href="https://trac.sagemath.org/ticket/4572" title="defect: [with patch, positive review] maxima output has misleading precision (closed: fixed)">#4572</a>.
</p>
TicketwasThu, 24 Dec 2009 07:07:39 GMTmilestone changed
https://trac.sagemath.org/ticket/7682#comment:2
https://trac.sagemath.org/ticket/7682#comment:2
<ul>
<li><strong>milestone</strong>
changed from <em>sage-4.3</em> to <em>sage-4.3.1</em>
</li>
</ul>
<p>
I'm declaring a total feature freeze on sage-4.3.
</p>
TicketjasonMon, 25 Jan 2010 13:43:01 GMTstatus changed; cc set
https://trac.sagemath.org/ticket/7682#comment:3
https://trac.sagemath.org/ticket/7682#comment:3
<ul>
<li><strong>cc</strong>
<em>robertwb</em> added
</li>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_work</em>
</li>
</ul>
<p>
Here is a first cut of a print_options model for <a class="missing wiki">RealField?</a> that lets you specify default printing options for any <a class="missing wiki">RealField?</a>, all <a class="missing wiki">RealFields?</a>, and still lets you override the defaults when you actually print the numbers.
</p>
<p>
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!).
</p>
TicketjasonMon, 25 Jan 2010 13:43:27 GMTcc, component changed
https://trac.sagemath.org/ticket/7682#comment:4
https://trac.sagemath.org/ticket/7682#comment:4
<ul>
<li><strong>cc</strong>
<em>jkantor</em> added
</li>
<li><strong>component</strong>
changed from <em>basic arithmetic</em> to <em>numerical</em>
</li>
</ul>
TicketjasonMon, 25 Jan 2010 13:43:39 GMTauthor set
https://trac.sagemath.org/ticket/7682#comment:5
https://trac.sagemath.org/ticket/7682#comment:5
<ul>
<li><strong>author</strong>
set to <em>Jason Grout</em>
</li>
</ul>
TicketjasonTue, 26 Jan 2010 05:50:36 GMT
https://trac.sagemath.org/ticket/7682#comment:6
https://trac.sagemath.org/ticket/7682#comment:6
<p>
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.
</p>
TicketjasonTue, 26 Jan 2010 06:16:16 GMT
https://trac.sagemath.org/ticket/7682#comment:7
https://trac.sagemath.org/ticket/7682#comment:7
<p>
Okay, patch passes all (non-long) doctests in Sage.
</p>
TicketrobertwbTue, 26 Jan 2010 06:26:07 GMTstatus changed
https://trac.sagemath.org/ticket/7682#comment:8
https://trac.sagemath.org/ticket/7682#comment:8
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_info</em>
</li>
</ul>
<p>
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.)
</p>
TicketjasonTue, 26 Jan 2010 06:41:30 GMT
https://trac.sagemath.org/ticket/7682#comment:9
https://trac.sagemath.org/ticket/7682#comment:9
<p>
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)
</p>
<p>
On another note, I just changed the latexing of a real field to indicate the precision and rounding, so that <a class="missing wiki">RealField?</a>(100,rnd='RNDD') prints as \Bold{R}<sup>{-}_<a class="missing report" title="report does not exist">{100}</a>. 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.
</sup></p>
TicketjasonTue, 26 Jan 2010 06:44:34 GMT
https://trac.sagemath.org/ticket/7682#comment:10
https://trac.sagemath.org/ticket/7682#comment:10
<p>
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.
</p>
TicketjasonTue, 26 Jan 2010 07:38:30 GMT
https://trac.sagemath.org/ticket/7682#comment:11
https://trac.sagemath.org/ticket/7682#comment:11
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7682#comment:8" title="Comment 8">robertwb</a>:
</p>
<blockquote class="citation">
<p>
it's probably be better to have a RR.print_options(...) that takes keywords. (This way it could have a nice docstring as well.)
</p>
</blockquote>
<p>
Yes, but how do you get the value of a specific option (as opposed to setting it).
</p>
TicketjasonTue, 26 Jan 2010 07:44:20 GMT
https://trac.sagemath.org/ticket/7682#comment:12
https://trac.sagemath.org/ticket/7682#comment:12
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7682#comment:8" title="Comment 8">robertwb</a>:
</p>
<blockquote class="citation">
<p>
(This way it could have a nice docstring as well.)
</p>
</blockquote>
<p>
The Cython "property" construct can also take a nice docstring. Is anything ever done with this docstring?
</p>
TicketjasonTue, 26 Jan 2010 09:37:43 GMTattachment set
https://trac.sagemath.org/ticket/7682
https://trac.sagemath.org/ticket/7682
<ul>
<li><strong>attachment</strong>
set to <em>trac-7682-realfield-printing-options.patch</em>
</li>
</ul>
TicketjasonTue, 26 Jan 2010 09:40:28 GMT
https://trac.sagemath.org/ticket/7682#comment:13
https://trac.sagemath.org/ticket/7682#comment:13
<p>
Okay, this is getting big now. I went through real_mpfr.pyx and added a lot of doctests and documentation.
</p>
<p>
There are four doctests failing right now because I'm not sure if they are bugs or if they are right. Here they are:
</p>
<pre class="wiki">**********************************************************************
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
</pre><p>
Are those four answers right (the "Got:" parts)? See <a class="needs_info ticket" href="https://trac.sagemath.org/ticket/8074" title="defect: corner cases in RealField and real numbers (needs_info)">#8074</a> for more corner cases.
</p>
TicketjasonSat, 27 Feb 2010 22:34:21 GMTcc changed
https://trac.sagemath.org/ticket/7682#comment:14
https://trac.sagemath.org/ticket/7682#comment:14
<ul>
<li><strong>cc</strong>
<em>was</em> added
</li>
</ul>
<p>
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.
</p>
TicketjasonSun, 28 Feb 2010 04:58:59 GMTattachment set
https://trac.sagemath.org/ticket/7682
https://trac.sagemath.org/ticket/7682
<ul>
<li><strong>attachment</strong>
set to <em>trac-7682-realfield-printing-options.2.patch</em>
</li>
</ul>
<p>
apply instead of previous patch. Rebased to Sage 4.3.3
</p>
TicketjasonSun, 28 Feb 2010 05:00:02 GMT
https://trac.sagemath.org/ticket/7682#comment:15
https://trac.sagemath.org/ticket/7682#comment:15
<p>
I uploaded a new patch which corrects several doctests; all doctests in Sage now seem to pass with this patch applied.
</p>
TicketjasonWed, 17 Mar 2010 05:13:24 GMTtype changed
https://trac.sagemath.org/ticket/7682#comment:16
https://trac.sagemath.org/ticket/7682#comment:16
<ul>
<li><strong>type</strong>
changed from <em>defect</em> to <em>enhancement</em>
</li>
</ul>
TicketjasonWed, 17 Mar 2010 05:13:51 GMTstatus changed
https://trac.sagemath.org/ticket/7682#comment:17
https://trac.sagemath.org/ticket/7682#comment:17
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>needs_review</em>
</li>
</ul>
TicketjasonFri, 14 May 2010 17:06:15 GMTattachment set
https://trac.sagemath.org/ticket/7682
https://trac.sagemath.org/ticket/7682
<ul>
<li><strong>attachment</strong>
set to <em>trac-7682-realfield-printing-options.3.patch</em>
</li>
</ul>
<p>
rebase to 4.4.1, apply only this patch
</p>
TicketjasonFri, 14 May 2010 17:07:52 GMTstatus changed
https://trac.sagemath.org/ticket/7682#comment:18
https://trac.sagemath.org/ticket/7682#comment:18
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
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
</p>
<pre class="wiki">----------------------------------------------------------------------
| 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
</pre>
TicketjasonFri, 14 May 2010 18:20:04 GMTattachment set
https://trac.sagemath.org/ticket/7682
https://trac.sagemath.org/ticket/7682
<ul>
<li><strong>attachment</strong>
set to <em>trac-7682-realfield-printing-options.4.patch</em>
</li>
</ul>
<p>
rebase to 4.4.1, fix startup bug, apply only this patch
</p>
TicketjasonFri, 14 May 2010 19:21:11 GMTattachment set
https://trac.sagemath.org/ticket/7682
https://trac.sagemath.org/ticket/7682
<ul>
<li><strong>attachment</strong>
set to <em>trac-7682-realfield-printing-options.5.patch</em>
</li>
</ul>
<p>
rebase to 4.4.1, fix startup bug, fix one doctest to test for the startup bug; apply only this patch
</p>
TicketleifFri, 28 May 2010 01:34:26 GMT
https://trac.sagemath.org/ticket/7682#comment:19
https://trac.sagemath.org/ticket/7682#comment:19
<p>
Slightly OT: Regarding the thread that started this, in finance you don't need less/limited precision, but <em>fixed</em>-point numbers. ;-)
</p>
TicketjasonFri, 28 May 2010 02:16:45 GMT
https://trac.sagemath.org/ticket/7682#comment:20
https://trac.sagemath.org/ticket/7682#comment:20
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7682#comment:19" title="Comment 19">leif</a>:
</p>
<blockquote class="citation">
<p>
Slightly OT: Regarding the thread that started this, in finance you don't need less/limited precision, but <em>fixed</em>-point numbers. ;-)
</p>
</blockquote>
<p>
Of course, then you would probably use the python Decimal module :).
</p>
TicketjasonFri, 28 May 2010 02:17:48 GMT
https://trac.sagemath.org/ticket/7682#comment:21
https://trac.sagemath.org/ticket/7682#comment:21
<p>
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.
</p>
TicketjasonFri, 18 Jun 2010 16:03:13 GMT
https://trac.sagemath.org/ticket/7682#comment:22
https://trac.sagemath.org/ticket/7682#comment:22
<p>
<a class="new ticket" href="https://trac.sagemath.org/ticket/9261" title="enhancement: RealIntervalField: enable option style='bracket' (new)">#9261</a> asks for one of the features implemented in this patch (setting the printing style for real interval fields).
</p>
TicketjasonFri, 18 Jun 2010 16:22:17 GMT
https://trac.sagemath.org/ticket/7682#comment:23
https://trac.sagemath.org/ticket/7682#comment:23
<p>
After experimenting for a few minutes, it looks like something like <a class="new ticket" href="https://trac.sagemath.org/ticket/9261" title="enhancement: RealIntervalField: enable option style='bracket' (new)">#9261</a> is almost implemented in this patch, but not quite.
</p>
TicketjasonFri, 18 Jun 2010 17:32:53 GMTattachment set
https://trac.sagemath.org/ticket/7682
https://trac.sagemath.org/ticket/7682
<ul>
<li><strong>attachment</strong>
set to <em>trac-7682-realintervalfield-printing.patch</em>
</li>
</ul>
<p>
apply on top of previous patch
</p>
TicketjasonFri, 18 Jun 2010 17:34:43 GMT
https://trac.sagemath.org/ticket/7682#comment:24
https://trac.sagemath.org/ticket/7682#comment:24
<p>
I added a patch which implements the feature wanted in <a class="new ticket" href="https://trac.sagemath.org/ticket/9261" title="enhancement: RealIntervalField: enable option style='bracket' (new)">#9261</a>:
</p>
<pre class="wiki">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]
</pre><p>
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 <a class="new ticket" href="https://trac.sagemath.org/ticket/9261" title="enhancement: RealIntervalField: enable option style='bracket' (new)">#9261</a> work).
</p>
TicketzimmermaSat, 19 Jun 2010 09:19:05 GMT
https://trac.sagemath.org/ticket/7682#comment:25
https://trac.sagemath.org/ticket/7682#comment:25
<p>
Jason,
</p>
<p>
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.
</p>
<p>
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:
</p>
<pre class="wiki">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
</pre><p>
In addition I don't understand how you achieve this:
</p>
<pre class="wiki">sage: RR.print_trailing_zeros=False
sage: RR.print_digits=None
sage: 3.09384
3.09384
</pre><p>
What happens with <code>RR.print_digits=16</code>?
</p>
<p>
Also, what happens with numbers with tiny or huge exponent, say <code>3.09384e-100</code> or
<code>3.09384e+100</code>?
</p>
<p>
Just my 2 cents.
</p>
<p>
Paul
</p>
<p>
PS: however, the patch for <a class="new ticket" href="https://trac.sagemath.org/ticket/9261" title="enhancement: RealIntervalField: enable option style='bracket' (new)">#9261</a> looks very nice. Can't you make it independent of that ticket?
</p>
TicketjasonSat, 19 Jun 2010 12:24:51 GMT
https://trac.sagemath.org/ticket/7682#comment:26
https://trac.sagemath.org/ticket/7682#comment:26
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7682#comment:25" title="Comment 25">zimmerma</a>:
</p>
<blockquote class="citation">
<p>
Jason,
</p>
<p>
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.
</p>
</blockquote>
<p>
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!)
</p>
<p>
So changing it should probably be a different ticket, and after this patch, should just be a one liner change to the defaults.
</p>
<blockquote class="citation">
<p>
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:
</p>
<pre class="wiki">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
</pre><p>
In addition I don't understand how you achieve this:
</p>
<pre class="wiki">sage: RR.print_trailing_zeros=False
sage: RR.print_digits=None
sage: 3.09384
3.09384
</pre><p>
What happens with <code>RR.print_digits=16</code>?
</p>
<p>
Also, what happens with numbers with tiny or huge exponent, say <code>3.09384e-100</code> or
<code>3.09384e+100</code>?
</p>
</blockquote>
<p>
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.
</p>
<blockquote class="citation">
<p>
Just my 2 cents.
</p>
<p>
Paul
</p>
<p>
PS: however, the patch for <a class="new ticket" href="https://trac.sagemath.org/ticket/9261" title="enhancement: RealIntervalField: enable option style='bracket' (new)">#9261</a> looks very nice. Can't you make it independent of that ticket?
</p>
</blockquote>
<p>
Yes, though it's easier to build on top of the framework here, and I hope better in the long run.
</p>
TicketjasonSun, 11 Jul 2010 06:51:54 GMT
https://trac.sagemath.org/ticket/7682#comment:27
https://trac.sagemath.org/ticket/7682#comment:27
<p>
Applying these patches to 4.4.2 gives several doctest errors like this:
</p>
<pre class="wiki">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'
</pre>
TicketjasonSun, 11 Jul 2010 06:57:44 GMT
https://trac.sagemath.org/ticket/7682#comment:28
https://trac.sagemath.org/ticket/7682#comment:28
<p>
It appears that the problem above occurs with just the last patch.
</p>
TicketjasonSun, 11 Jul 2010 07:12:42 GMTdescription changed
https://trac.sagemath.org/ticket/7682#comment:29
https://trac.sagemath.org/ticket/7682#comment:29
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/7682?action=diff&version=29">diff</a>)
</li>
</ul>
<p>
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.
</p>
TicketjasonSun, 11 Jul 2010 07:13:44 GMTdescription changed
https://trac.sagemath.org/ticket/7682#comment:30
https://trac.sagemath.org/ticket/7682#comment:30
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/7682?action=diff&version=30">diff</a>)
</li>
</ul>
TicketzimmermaSun, 11 Jul 2010 16:41:08 GMT
https://trac.sagemath.org/ticket/7682#comment:31
https://trac.sagemath.org/ticket/7682#comment:31
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7682#comment:29" title="Comment 29">jason</a>:
</p>
<blockquote class="citation">
<p>
it would be best to either change the scope of the ticket to reflect what the patch actually does
</p>
</blockquote>
<p>
I would prefer this.
</p>
<p>
Paul
</p>
TicketcwittySun, 11 Jul 2010 19:30:02 GMT
https://trac.sagemath.org/ticket/7682#comment:32
https://trac.sagemath.org/ticket/7682#comment:32
<p>
I actually dislike the goal of this patch: I don't think it's a good idea to have <code>RealNumber</code> printing varied per-parent, and certainly not if the printing is mutable. Consider:
</p>
<p>
Somebody wants to know what 128 bits of $\pi$ prints as in scientific notation:
</p>
<pre class="wiki">sage: RR128 = RealField(128)
sage: RR128.print_options['scientific_notation'] = 'always'
sage: RR128(pi)
3.1415926535897932384626433832795028842e0
</pre><p>
Then, days later (but in the same Sage session) they're playing around with the internals of AA/QQbar:
</p>
<pre class="wiki">sage: rt2 = AA(sqrt(2))
sage: rt2._value.center()
1.41421356237309505
sage: RealIntervalField(100)(rt2)
1.414213562373095048801688724210?
sage: rt2._value.center()
1.4142135623730950488016887242096980786e0
</pre><p>
Why is that last number printed in scientific notation? Oh yes, it's because we changed RR128 days ago.
</p>
<p>
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.
</p>
<p>
I can think of two ways to fix this:
</p>
<p>
1) Get rid of per-field printing options altogether; only have a single global setting that affects all <code>RealField</code>s.
</p>
<p>
2) Make the print options immutable, so that creating RR128scientific_notation doesn't affect anybody else who might create RR128 without scientific notation.
</p>
<p>
My vote would be for option 1, but I could live with either option.
</p>
TicketjasonMon, 12 Jul 2010 14:40:56 GMT
https://trac.sagemath.org/ticket/7682#comment:33
https://trac.sagemath.org/ticket/7682#comment:33
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7682#comment:32" title="Comment 32">cwitty</a>:
</p>
<blockquote class="citation">
<p>
I actually dislike the goal of this patch: I don't think it's a good idea to have <code>RealNumber</code> printing varied per-parent, and certainly not if the printing is mutable. Consider:
</p>
<p>
Somebody wants to know what 128 bits of $\pi$ prints as in scientific notation:
</p>
<pre class="wiki">sage: RR128 = RealField(128)
sage: RR128.print_options['scientific_notation'] = 'always'
sage: RR128(pi)
3.1415926535897932384626433832795028842e0
</pre><p>
Then, days later (but in the same Sage session) they're playing around with the internals of AA/QQbar:
</p>
<pre class="wiki">sage: rt2 = AA(sqrt(2))
sage: rt2._value.center()
1.41421356237309505
sage: RealIntervalField(100)(rt2)
1.414213562373095048801688724210?
sage: rt2._value.center()
1.4142135623730950488016887242096980786e0
</pre><p>
Why is that last number printed in scientific notation? Oh yes, it's because we changed RR128 days ago.
</p>
<p>
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.
</p>
<p>
I can think of two ways to fix this:
</p>
<p>
1) Get rid of per-field printing options altogether; only have a single global setting that affects all <code>RealField</code>s.
</p>
<p>
2) Make the print options immutable, so that creating RR128scientific_notation doesn't affect anybody else who might create RR128 without scientific notation.
</p>
<p>
My vote would be for option 1, but I could live with either option.
</p>
</blockquote>
<p>
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.
</p>
<p>
For my use-case (teaching numerical analysis), option (1) is better than the patch on this ticket.
</p>
<p>
So do you propose eliminating the sci_not options to <a class="missing wiki">RealField?</a>? Do you propose eliminating the arguments to the str function?
</p>
<p>
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.
</p>
TicketcwittyMon, 12 Jul 2010 16:25:01 GMT
https://trac.sagemath.org/ticket/7682#comment:34
https://trac.sagemath.org/ticket/7682#comment:34
<blockquote>
<p>
So do you propose eliminating the sci_not options to <a class="missing wiki">RealField?</a>?? Do you propose eliminating the arguments to the str function?
</p>
</blockquote>
<p>
Yes, my vote would be to eliminate sci_not in <code>RealField</code>. 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:
</p>
<pre class="wiki"> 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
</pre><p>
Further comments:
</p>
<p>
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:
</p>
<pre class="wiki">TESTS:
Here we test the deprecated no_sci argument to .str()::
</pre><p>
followed by the tests for no_sci that used to be there (assuming there were some, I haven't actually checked).
</p>
TicketleifFri, 22 Jul 2011 09:34:11 GMT
https://trac.sagemath.org/ticket/7682#comment:35
https://trac.sagemath.org/ticket/7682#comment:35
<p>
ping (?)
</p>
TicketjasonFri, 22 Jul 2011 14:55:56 GMT
https://trac.sagemath.org/ticket/7682#comment:36
https://trac.sagemath.org/ticket/7682#comment:36
<p>
pong. I would love to see this ticket resolved, but as you can see, there is another major rewrite needed before it is ready.
</p>
TicketkcrismanFri, 09 Nov 2012 18:40:22 GMTcc changed
https://trac.sagemath.org/ticket/7682#comment:37
https://trac.sagemath.org/ticket/7682#comment:37
<ul>
<li><strong>cc</strong>
<em>kcrisman</em> added
</li>
</ul>
TicketjdemeyerTue, 13 Aug 2013 15:35:53 GMTmilestone changed
https://trac.sagemath.org/ticket/7682#comment:38
https://trac.sagemath.org/ticket/7682#comment:38
<ul>
<li><strong>milestone</strong>
changed from <em>sage-5.11</em> to <em>sage-5.12</em>
</li>
</ul>
Ticketvbraun_spamThu, 30 Jan 2014 21:20:52 GMTmilestone changed
https://trac.sagemath.org/ticket/7682#comment:39
https://trac.sagemath.org/ticket/7682#comment:39
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.1</em> to <em>sage-6.2</em>
</li>
</ul>
Ticketvbraun_spamTue, 06 May 2014 15:20:58 GMTmilestone changed
https://trac.sagemath.org/ticket/7682#comment:40
https://trac.sagemath.org/ticket/7682#comment:40
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.2</em> to <em>sage-6.3</em>
</li>
</ul>
Ticketvbraun_spamSun, 10 Aug 2014 16:51:03 GMTmilestone changed
https://trac.sagemath.org/ticket/7682#comment:41
https://trac.sagemath.org/ticket/7682#comment:41
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.3</em> to <em>sage-6.4</em>
</li>
</ul>
TicketnbruinSun, 20 May 2018 06:28:27 GMT
https://trac.sagemath.org/ticket/7682#comment:42
https://trac.sagemath.org/ticket/7682#comment:42
<p>
How lovely to revive an 8 year old ticket ...
</p>
<p>
In the mean time, python has grown a new string formatting method. If we implement a <code>__format__</code> method on our mpfr wrapper, one could just do something like
</p>
<pre class="wiki">sage: a=RealField(200)(2).sqrt()
sage: "{:.20e}".format(a)
'1.414213562373095049e0'
</pre><p>
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 <code>str</code>).
</p>
<p>
It might be a nice beginner's exercise to write the appropriate <code>__format__</code>.
</p>
TicketegourgoulhonSun, 20 May 2018 15:45:52 GMTcc changed
https://trac.sagemath.org/ticket/7682#comment:43
https://trac.sagemath.org/ticket/7682#comment:43
<ul>
<li><strong>cc</strong>
<em>egourgoulhon</em> added
</li>
</ul>
Ticketgh-sheerluckSun, 14 Apr 2019 09:21:25 GMT
https://trac.sagemath.org/ticket/7682#comment:44
https://trac.sagemath.org/ticket/7682#comment:44
<p>
I wanted to have fun with <code>e</code> to the power of <code>π√163</code>
</p>
<p>
I expected Sage would print me <code>262537412640768743.99999999999925</code>
</p>
<pre class="wiki">sage: R = RealField(1500)
sage: a = R(e) ** (R(pi) * R(163).sqrt())
sage: a.n(digits=33)
2.62537412640768743999999999999250e17
sage: "{:.70f}".format(a)
TypeError: unsupported format string passed to sage.rings.real_mpfr.RealNumber.__format__
</pre><p>
is there a way to print <code>2.62537412640768743999999999999250e17</code> as <code>262537412640768743.99999999999925</code>?
</p>
TicketegourgoulhonSun, 14 Apr 2019 09:56:48 GMT
https://trac.sagemath.org/ticket/7682#comment:45
https://trac.sagemath.org/ticket/7682#comment:45
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7682#comment:44" title="Comment 44">gh-sheerluck</a>:
</p>
<blockquote class="citation">
<p>
I wanted to have fun with <code>e</code> to the power of <code>π√163</code>
</p>
<p>
I expected Sage would print me <code>262537412640768743.99999999999925</code>
</p>
<pre class="wiki">sage: R = RealField(1500)
sage: a = R(e) ** (R(pi) * R(163).sqrt())
sage: a.n(digits=33)
2.62537412640768743999999999999250e17
sage: "{:.70f}".format(a)
TypeError: unsupported format string passed to sage.rings.real_mpfr.RealNumber.__format__
</pre><p>
is there a way to print <code>2.62537412640768743999999999999250e17</code> as <code>262537412640768743.99999999999925</code>?
</p>
</blockquote>
<p>
A solution is:
</p>
<pre class="wiki">sage: n(exp(pi*sqrt(163)), digits=33).str(no_sci=2)
'262537412640768743.999999999999249212'
</pre>
Ticketgh-sheerluckSun, 14 Apr 2019 10:13:40 GMT
https://trac.sagemath.org/ticket/7682#comment:46
https://trac.sagemath.org/ticket/7682#comment:46
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7682#comment:45" title="Comment 45">egourgoulhon</a>:
</p>
<blockquote class="citation">
<p>
A solution is:
</p>
<pre class="wiki">sage: n(exp(pi*sqrt(163)), digits=33).str(no_sci=2)
'262537412640768743.999999999999249212'
</pre></blockquote>
<p>
Thank you!
</p>
Ticket