Re: Programming language and IDE design

Martin Ward <martin@gkc.org.uk> wrote:
> (2) Absolutely no behaviour should be "implementation dependent"
> or "undefined". Every syntactically valid program should have
> a single semantically valid meaning (even if that meaning
> is "halt with an error message").


This is really problematic in the area of floating-point arithmatic.
For example, at what point should floating-point arithmetic overflow
or underflow, and what should be the consequences of this happening?
To be very precise, what "single semantically valid meaning" should we
perscribe for trying to compute the square of 1.0e300?


If we say "the answer should be 1.0e600" then we're forbidding the
efficient use of hardware floating-point on machines that provide
IEEE-double (for which the multiplication of 1.0e300 by itself will
overflow).


If we say "the answer should be a floating-point overflow" then we're
forbidding the efficient use of hardware "double extended" floating-point
on machines that provide extended-precision floating-point registers
with a wider exponent range (so that the multiplication of 1.0e300 by
itself will not overflow).


And if we don't use hardware floating-point, on some codes we lose
a lot of performance.




Underflow presents even worse problems: Apart from the question of
just where the underflow threshold should be, what happens after an
underflow? Should our "single semantically valid meaning" specify
gradual underflow or flush-to-zero or underflow-is-an-error?




And dwarfing all of these problems are the question of what to do about
trancendental (math) functions? Just what should we specify the result
of cos(x) to be? Some possibilities include
* specify one particular approximation (this is what Java did at first)
    --> blocks the use of better approximations if/when they're developed
            in the future
* specify "the floating-point number closest to the exact result"
    --> is rather hard to implement; it's doable for cos(x) but pow(x,y)
            is still an active (not-yet-solved) research problem




Java encountered all of these problems, and eventually chose to back
off its "precise specification" to allow implementation-defined
semantics for floating-point arithmetic.


Most other languages which have or want to have substantial use for
scientific computation left floating-point arithmetic machine-dependent
from the start.


--
-- "Jonathan Thornburg [remove -animal to reply]" <jthorn@astro.indiana-zebra.edu>
      Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
      "There was of course no way of knowing whether you were being watched
        at any given moment. How often, or on what system, the Thought Police
        plugged in on any individual wire was guesswork. It was even conceivable
        that they watched everybody all the time." -- George Orwell, "1984"

Return to the comp.compilers page.
Search the comp.compilers archives again.