5 ms·
This is from March 1998, and predates JVM 1.2 which introduced strictfp (which is important because JVM was otherwise numerically IEEE 754 compliant before stri
by lifthrasiir 3y ago
This is from March 1998, and predates JVM 1.2 which introduced strictfp (which is important because JVM was otherwise numerically IEEE 754 compliant before strictfp). I believe the core point of this talk has not been "fixed" [1] because it completely missed the problem with IEEE 754 global states. Like, the talk says:
A flag is a type of global variable raised as a side-effect of exceptional floating-point operations. Also
it can be sensed, saved, restored and lowered by a program. When raised it may, in some systems,
serve an extra-linguistic diagnostic function by pointing to the first or last operation that raised it.
Any modern programmer knows that side effects are, while inevitable, hard to tame and some discipline is needed. Pure functional programming, mutable XOR shared, software transactional memory, you name it. This part of talk completely handwaves a difficulty of side effects and forces every language to be handcuffed with those global states and side effects. No good.
[1] Joe Darcy, one of the students of William Kahan, later went to Sun to improve fp support in Java; see https://web.archive.org/web/20090402234711/http://blogs.sun.com/darcy/entry/everything_old_is_new_again https://web.archive.org/web/20090402234711/http://blogs.sun.... and https://web.archive.org/web/20100224062224/http://blogs.sun.com/darcy/entry/everything_older_is_newer_once https://web.archive.org/web/20100224062224/http://blogs.sun.... for example. But his work was more about library supports AFAIK.
- smarks 3y agoThanks for mentioning Joe Darcy. He continues to work on the JDK at Oracle and occasionally works on numerics issues. Notable for this discussion, he recently updated the Java specifications for JDK 17 to remove non-strict FP semantics (which also entailed removal of the `strictfp` modifier, since the default now is always strict). See JEP 306. [1] [1]: https://openjdk.org/jeps/306 https://openjdk.org/jeps/306