On 02/20/2011 06:17 AM, Jonathan M Davis wrote:
On Saturday 19 February 2011 20:46:50 Walter Bright wrote:
bearophile wrote:
Walter:
That'll just trade one set of problems for another.
But the second set of problems may be smaller :-)
There's a total lack of evidence for that. Furthermore,
1. Roundoff error is not of a fixed magnitude.
2. A user may choose to ignore roundoff errors, but that is not the
prerogative of the language.
3. What is an acceptable amount of roundoff error is not decidable by the
language.
4. At Boeing doing design work, I've seen what happens when engineers
ignore roundoff errors. It ain't pretty. It ain't safe. It ain't correct.
Honestly, the more that I learn about and deal with floating point numbers, the
more I wonder why we don't just use fixed point. Obviously that can be a bit
limiting for the size of the number (on either side of the decimal) -
particularly in 32-bit land - but with 64-bit numbers, it sounds increasingly
reasonable given all of the issues with floating point values. Ideally, I
suppose, you'd have both, but the CPU specifically supports floating point (I
don't know about fixed point), and I don't think that I've ever used a language
which really had fixed point values (unless you count integers as fixed point
with
no digits to the right of the decimal).
I don't see how fixed point would solve common issues with floats. Would you
expand a bit on this?
For me, the source of the issue is inaccurate and unintuitive "translations"
from/to decimal and binary. For instance (using python just for example):
0.1
0.10000000000000001
0.7
0.69999999999999996
0.3
0.29999999999999999
To solve this, one may use rationals (representing 0.1 by 1/10) or decimals
(representing decimal digits, each eg by half a byte). Both are costly, indeed.
I may ignore some other points, solved by fixed point arithmetics.
Denis
--
_________________
vita es estrany
spir.wikidot.com