On Wed, Mar 31, 2004, Andrew Koenig wrote:
>Aahz:
>>
>> I've read the whole thread, and I wanted to repeat a critical point for
>> emphasis:
>>
>> This doesn't help
>>
>> No matter what you do to improve conversion issues, you're still dealing
>> with the underlying floating-point problems, and having watched the
>> changing discussions in c.l.py since we moved to the different conversion
>> system, it seems clear to me that we've improved the nature of the
>> discussion by forcing people to get bitten earlier.
>
> On the other hand, it is pragmatically more convenient when an
> implementation prints the values of floating-point literals with a
> small number of significant digits with the same number of significant
> digits with which they were entered.
Pragmatically more convenient by what metric? No matter how you slice
it, binary floating point contains surprises for the uninitiated. The
question is *WHEN* do you hammer the point home? I've yet to see you
address this directly.
> If I can enter a number as 0.1, printing that number as 0.1 does not
> introduce any errors that were not already there, as proved by the
> fact that reading that 0.1 back will yield exactly the same value.
It's not a matter of introducing errors, it's a matter of making the
errors visible. Python is, among other things, a language suitable for
introducing people to computers. That's why the Zen of Python contains
such gems as
Explicit is better than implicit.
Errors should never pass silently.
In the face of ambiguity, refuse the temptation to guess.
If you're going to continue pressing your point, please elucidate your
reasoning in terms of Python's design principles.
--
Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/
"usenet imitates usenet" --Darkhawk
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4