Re: About exact results and exact endpoints
On Feb 13 2013, Michel Hack wrote:
On the first point, namely Richard Fateman's example. I'm afraid Richard
is correct. The literal 0.1d0 does not denote the fraction 1/10, but the
DOUBLE representation thereof, in the programming languages (Fortran, C)
that he mentioned. Indeed, only a language with first-class interval
support (such as some versions of Fortran) *could* use context to perform
outward rounding on literals -- but I don't know if Fortran does. When
the same value comes in through assignment (x = 0.1d0; yy = [0, x]) this
is not possible anymore (in general), so perhaps the consistent position
is to treat the literal the same way.
It's much more fundamental than that. All or almost all modern languages
(including Fortran) use a form of BNF to specify their syntax and type
rules, and use a degree of context independence for that. Fortran allows
quite complicated expressions in initialisation, unlike C and C++, and
doing that would be very unclean. Some older Fortrans did, as you say,
but as far as I know they were all Fortran 77 or Fortran IV.
This is why explicit interval literal support of some kind is needed,
logically through the text2interval() primitive, which optimization can
then replace with a constructed interval via constant propagation.
That is correct. And it is true irrespective of the base, when one
needs to encode constants like one third, pi or e - all of which are
supported by Fortran by the ability to write constant expressions.
C++ has sort-of headed down the same path, too, but I would rather not
describe that.
On the second point, the justification of decimal floating-point (DFP)
compared to binary (BFP) is indeed legal rather than mathematical, and
the primary advantage of 754-2008 DFP is that it supports efficient
emulation of decimal FIXED-point arithmetic as required in financial
calculations. That's why there is quantum support and cohorts, and
why the always-normalized IEEE 854 failed to gain acceptance.
I disagree with the claim of efficiency, given the completely alien rules
for precision and rounding required by many laws, but this is not the
list to reopen that one. I agree that is the reason. My point was
that the floating-point base is an irrelevance at that level - and there
is no particular reason why floating-point should be used for numeric
approximation rather than an alternative representation (say, continued
fractions). Indeed, Fortran 77 allowed that, and the changes to modern
Fortran to restore it would be small.
Yes, I know that I am a dangerous heretic :-)
Regards,
Nick Maclaren.