Gradual-Underflow Wars

  • Thread starter Lawrence D'Oliveiro
  • Start date
L

Lawrence D'Oliveiro

Nowadays we take IEEE-754 arithmetic for granted (at least in the hardware;
language support is another matter, unless you’re using an enlightened
language like GCC or Python). It was a different matter in the late 1970s,
when the idea for a standard floating-point architecture first came
together, spurred by Intel’s development of its 8087 chip.

Hard to believe it now, but the most controversial aspect of the proposal
was its support for denormalized numbers, to fill in the underflow gap
between the closest normalized number to zero, and zero itself. In theory
you could write code that would work correctly without such help, but most
people didn’t have that kind of skill in numerics. And still don’t.

<http://www.eecs.berkeley.edu/~wkahan/ieee754status/754story.html>

Kahan also has a paper elsewhere deriding the floating-point limitations of
Java. Java does not distinguish between NaN and infinity, and provides no
way of querying and controlling floating-point exceptions (in the IEEE-754
sense of “exceptionâ€).

His paper was published in 1998, and is still a valid criticism today.
 
L

Lew

Nowadays we take IEEE-754 arithmetic for granted (at least in the hardware;
language support is another matter, unless you’re using an enlightened
language like GCC or Python). It was a different matter in the late 1970s,
when the idea for a standard floating-point architecture first came
together, spurred by Intel’s development of its 8087 chip.

Hard to believe it now, but the most controversial aspect of the proposal
was its support for denormalized numbers, to fill in the underflow gap
between the closest normalized number to zero, and zero itself. In theory
you could write code that would work correctly without such help, but most
people didn’t have that kind of skill in numerics. And still don’t.

<http://www.eecs.berkeley.edu/~wkahan/ieee754status/754story.html>

Kahan also has a paper elsewhere deriding the floating-point limitations of
Java. Java does not distinguish between NaN and infinity, and provides no

Bullshit. Ignorant bullshit.

<http://download.oracle.com/javase/6/docs/api/java/lang/Double.html#NaN>
<http://download.oracle.com/javase/6/docs/api/java/lang/Double.html#NEGATIVE_INFINITY>
<http://download.oracle.com/javase/6/docs/api/java/lang/Double.html#POSITIVE_INFINITY>

Stop lying.
way of querying and controlling floating-point exceptions (in the IEEE-754
sense of “exceptionâ€).

His paper was published in 1998, and is still a valid criticism today.

From the JLS, §4.2.4:
"Operators on floating-point numbers behave as specified by IEEE 754 (with the
exception of the remainder operator (§15.17.3)). In particular, the Java
programming language requires support of IEEE 754 denormalized floating-point
numbers and gradual underflow, ...

"An operation that overflows produces a signed infinity, an operation that
underflows produces a denormalized value or a signed zero, and an operation
that has no mathematically definite result produces NaN."

So much for "does not distinguish".
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,764
Messages
2,569,567
Members
45,041
Latest member
RomeoFarnh

Latest Threads

Top