Re: [sage-support] Inconsistency between Sage and Python
Hi João,
If you want precise control on the output, you might use the python
formatting (see
https://docs.python.org/2/library/string.html#formatstrings)
sage: x = RR(pi)
sage: print x
3.14159265358979
sage: print {:.3}.format(x)
3.1
sage: print {:.5}.format(x)
3.141
But perhaps it is not an answer to your question, is it?
Vincent
2014-10-06 18:03 UTC+02:00, João Alberto joa...@gmail.com:
I am plotting some graphs, but the plot becomes cluttered because of
the long labels. The labels are result of a conversion from a Real
number to a string. The problem here is that Sage is not consistent
with Python, as shown in the example below.
Python:
multiplier = [1.0e0, 1.0e1, 1.0e2]
multiplier
[1.0, 10.0, 100.0]
str(multiplier[-1])
'100.0'
Sage:
sage: multiplier = [1.0e0, 1.0e1, 1.0e2]
sage: multiplier
[1.00, 10.0, 100.]
sage: str(multiplier[-1])
'100.'
Is this a correct behavior of Sage? at least for me, the excess of
trailing zeros is causing some trouble.
--
You received this message because you are subscribed to the Google Groups
sage-support group.
To unsubscribe from this group and stop receiving emails from it, send an
email to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
sage-support group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] Inconsistency between Sage and Python
On 2014-10-06 18:03, João Alberto wrote: Is this a correct behavior of Sage? It's a feature, not a bug. The reason is that the number of digits gives an idea about the precision of the number. Compare sage: RealField(20)(1) 1. sage: RealField(100)(1) 1. If both these would be printed as 1.0, you would lose this information about the precision. Python has a fixed precision of 53 bits and prints a minimal number of digits. -- You received this message because you are subscribed to the Google Groups sage-support group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] Inconsistency between Sage and Python
Yes, I know Vincent, thank you, but this would complicate my code
unnecessarily.
I used Samuel idea. But I still think that the extra trailing zeros have no
reason to exist.
On Monday, October 6, 2014 1:08:23 PM UTC-3, vdelecroix wrote:
Hi João,
If you want precise control on the output, you might use the python
formatting (see
https://docs.python.org/2/library/string.html#formatstrings)
sage: x = RR(pi)
sage: print x
3.14159265358979
sage: print {:.3}.format(x)
3.1
sage: print {:.5}.format(x)
3.141
But perhaps it is not an answer to your question, is it?
Vincent
2014-10-06 18:03 UTC+02:00, João Alberto joa...@gmail.com javascript::
I am plotting some graphs, but the plot becomes cluttered because of
the long labels. The labels are result of a conversion from a Real
number to a string. The problem here is that Sage is not consistent
with Python, as shown in the example below.
Python:
multiplier = [1.0e0, 1.0e1, 1.0e2]
multiplier
[1.0, 10.0, 100.0]
str(multiplier[-1])
'100.0'
Sage:
sage: multiplier = [1.0e0, 1.0e1, 1.0e2]
sage: multiplier
[1.00, 10.0, 100.]
sage: str(multiplier[-1])
'100.'
Is this a correct behavior of Sage? at least for me, the excess of
trailing zeros is causing some trouble.
--
You received this message because you are subscribed to the Google
Groups
sage-support group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to sage-support...@googlegroups.com javascript:.
To post to this group, send email to sage-s...@googlegroups.com
javascript:.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
sage-support group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] Inconsistency between Sage and Python
Ok, I had to make a huge effort to accept this, but it's more clear now. One last question: Why RDF does not incorporate this feature? because it comes from the GSL library, that is an independent project? or because its precision is known a priori, like the float type in Python? On Monday, October 6, 2014 3:39:32 PM UTC-3, Jeroen Demeyer wrote: On 2014-10-06 18:03, João Alberto wrote: Is this a correct behavior of Sage? It's a feature, not a bug. The reason is that the number of digits gives an idea about the precision of the number. Compare sage: RealField(20)(1) 1. sage: RealField(100)(1) 1. If both these would be printed as 1.0, you would lose this information about the precision. Python has a fixed precision of 53 bits and prints a minimal number of digits. -- You received this message because you are subscribed to the Google Groups sage-support group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
