Author mark.dickinson
Recipients alexandre.vassalotti, amaury.forgeotdarc, christian.heimes, gvanrossum, mark.dickinson, nascheme, noam, rhettinger, skip.montanaro, tim.peters
Date 2008-07-08.13:34:35
SpamBayes Score 0.000468461
Marked as misclassified No
Message-id <1215524077.61.0.934984393771.issue1580@psf.upfronthosting.co.za>
In-reply-to
Content
For what it's worth, I'm -0.1 (or should that be -0.10000000000000001?) on 
this change.  It seems better to leave the problems caused by binary 
floating-point out in the open than try to partially hide them, and the 
proposed change just seems a little bit too 'magic'.  The inconsistency in 
the following current behaviour *does* irk me slightly (but only 
slightly):

>>> 0.13
0.13
>>> 0.14
0.14000000000000001

But practical issues aside, my preference would be to go to the other 
extreme: fix this inconsistency by changing the first output to 
0.13000000000000000 rather than changing the second output to 0.14.  That 
is, have repr(float) *always* output 17 digits, possibly except when that 
float is *exactly* representable in 16 or fewer decimal digits (e.g. 3.5, 
0.125, ...).  All the zeros act as a subtle reminder that the stored value 
is not exactly 0.13.  But I suspect this, too, isn't very practical.
History
Date User Action Args
2008-07-08 13:34:38mark.dickinsonsetspambayes_score: 0.000468461 -> 0.000468461
recipients: + mark.dickinson, gvanrossum, tim.peters, skip.montanaro, nascheme, rhettinger, amaury.forgeotdarc, christian.heimes, alexandre.vassalotti, noam
2008-07-08 13:34:37mark.dickinsonsetspambayes_score: 0.000468461 -> 0.000468461
messageid: <1215524077.61.0.934984393771.issue1580@psf.upfronthosting.co.za>
2008-07-08 13:34:36mark.dickinsonlinkissue1580 messages
2008-07-08 13:34:35mark.dickinsoncreate