ark Dickinson wrote:
> On Sun, Apr 26, 2009 at 10:42 PM, Scott David Daniels wrote:
>...
>> I had also said (without explaining:
only the trailing zeroes with the e, so we wind up with:
1157920892373161954235709850086879078532699846656405640e+23
or 1157920892373161954235709850
Mark Dickinson wrote:
(1) Currently, '%f' formatting automatically changes to '%g' formatting for
numbers larger than 1e50. For example:
'%f' % 2**166.
'93536104789177786765035829293842113257979682750464.00'
'%f' % 2**167.
'1.87072e+50'
I propose removing this feature for 3.1
I don't
it would make more sense to me if it
stayed fixed at 56 sig digits for numbers larger than 1e50.
So I agree with this, even if the default # of sig digits were less.
Several reasons to accept Mark's proposal:
* It matches what C does and many languages tend to copy the
C standards with
On Sun, Apr 26, 2009 at 10:42 PM, Scott David Daniels
wrote:
> I had also said (without explaining:
>> > only the trailing zeroes with the e, so we wind up with:
>> > 1157920892373161954235709850086879078532699846656405640e+23
>> > or 115792089237316195423570985008687907853269984665640564.0
Mark Dickinson wrote:
> On Sun, Apr 26, 2009 at 8:11 PM, Scott David Daniels
> wrote:
>> As a user of Idle, I would not like to see the change you seek of
>> having %f stay full-precision. When a number gets too long to print
>> on a single line, the wrap depends on the current window width, and
Mark Dickinson wrote:
I'd like to propose two minor changes to float and complex
formatting, for 3.1. I don't think either change should prove
particularly disruptive.
(1) Currently, '%f' formatting automatically changes to '%g' formatting for
numbers larger than 1e50. For example:
'%f' % 2*
On Sun, Apr 26, 2009 at 8:11 PM, Scott David Daniels
wrote:
> As a user of Idle, I would not like to see the change you seek of
> having %f stay full-precision. When a number gets too long to print
> on a single line, the wrap depends on the current window width, and
> is calculated dynamically.
Mark Dickinson wrote:
... """[5] These numbers are fairly arbitrary. They are intended to
avoid printing endless strings of meaningless digits without
hampering correct use and without having to know the exact
precision of floating point values on a particular machine."""
I don't f
On Sun, Apr 26, 2009 at 5:59 PM, Eric Smith wrote:
> Mark Dickinson wrote:
>> I propose changing the complex str and repr to behave like the
>> float version. That is, repr(4. + 10.j) should be "(4.0 + 10.0j)"
>> rather than "(4+10j)".
>
> I'm +0.5 on this. I'd probably be +1 if I were a big comp
Mark Dickinson wrote:
I'd like to propose two minor changes to float and complex
formatting, for 3.1. I don't think either change should prove
particularly disruptive.
(1) Currently, '%f' formatting automatically changes to '%g' formatting for
numbers larger than 1e50. For example:
...
I pro
Steven D'Aprano wrote:
On Sun, 26 Apr 2009 08:06:56 pm Mark Dickinson wrote:
I'd like to propose two minor changes to float and complex
formatting, for 3.1. I don't think either change should prove
particularly disruptive.
(1) Currently, '%f' formatting automatically changes to '%g'
formatt
On Sun, 26 Apr 2009 08:06:56 pm Mark Dickinson wrote:
> I'd like to propose two minor changes to float and complex
> formatting, for 3.1. I don't think either change should prove
> particularly disruptive.
>
> (1) Currently, '%f' formatting automatically changes to '%g'
> formatting for numbers la
I'd like to propose two minor changes to float and complex
formatting, for 3.1. I don't think either change should prove
particularly disruptive.
(1) Currently, '%f' formatting automatically changes to '%g' formatting for
numbers larger than 1e50. For example:
>>> '%f' % 2**166.
'93536104789177
13 matches
Mail list logo
