4 ms·

This part is interesting: > "If better precision, directed roundings, and exception handling capabilities latent in hardware but linguistically inaccessible re

This part is interesting: > "If better precision, directed roundings, and exception handling capabilities latent in hardware but linguistically inaccessible remain unused, their mathematically provable necessity will not save them from atrophy. The new C9X proposal before ANSI X3J11 is a fragile attempt to insinuate their support into the C and C++ language standards. It deserves the informed consideration of the programmers it tries to serve, not indifference." And it's now 2013 and directed roundings and exception handling largely remain linguistically inaccessible. C99 did add them, but they remain fragile. And most other languages haven't added them. It seems that the programming community has largely settled on indifference.

fdej 13y ago
This is sadly true. If you want to do reliable floating-point computations beyond +, * and / with round-to-nearest (and even that isn't easy, since for example the use of x87 instructions can result in the wrong precision), the only portable solution is still to use a software implementation such as MPFR. Which is a shame because you're letting all that fast silicon go to waste.
- deleted 13y ago
  [deleted]
- stephencanon 13y ago
  Even if all the basic operations were fully specified and implemented identically on all architectures, you would still have a noticeable performance vs. reproducibility tradeoff across architectures for "real computation". For example, different architectures have different numbers of registers and different cache hierarchies, which favors different access patterns in a fast matrix multiplication; thus linear algebra routines that attempt to be as fast as possible will necessarily group the arithmetic operations differently, which leads to different results even if individual arithmetic operations are guaranteed to be identical. It's not insurmountable, but it's a thornier problem than it looks at first.
stephencanon 13y ago
Directed rounding as a thread-local state (or global state), which is what the first 25 years of IEEE-754 processors supported, turns out to be not a very useful model (except for debugging tricks like estimating stability, which is dear to Kahan); that's a big part of why directed rounding isn't widely used or supported. Several newer hardware designs have added per-instruction stateless directed rounding (the rounding direction is part of the opcode); this is a much more useful model (and its presence makes dynamic rounding modes more usable as well!). This feature was added to ieee-754 in the 2008 revision, too late for language bindings to be added to c[++]11, but there's already language support in OpenCL and other compute languages, and bindings have been proposed to the C committee. So, progress is being made, slowly but surely.
StefanKarpinski 13y ago
For what it's worth, Julia supports setting rounding modes in a way that works across both native floating-point types (Float32 and Float64) and BigFloats: http://docs.julialang.org/en/latest/stdlib/base/#Base.get_rounding http://docs.julialang.org/en/latest/stdlib/base/#Base.get_ro... This stuff is incredibly important for numerical work and it's really a shame that mainstream languages have effectively rejected this key piece of functionality – that the hardware supports. There's an open GitHub umbrella issue tracking support for all of the pieces of functionality that Kahan advocates: https://github.com/JuliaLang/julia/issues/2976 https://github.com/JuliaLang/julia/issues/2976 I'm not sure about signaling NaNs though. There have been rumblings that future hardware might not support them.

fdej 13y ago

This is sadly true. If you want to do reliable floating-point computations beyond +, * and / with round-to-nearest (and even that isn't easy, since for example the use of x87 instructions can result in the wrong precision), the only portable solution is still to use a software implementation such as MPFR. Which is a shame because you're letting all that fast silicon go to waste.

deleted 13y ago
[deleted]
stephencanon 13y ago
Even if all the basic operations were fully specified and implemented identically on all architectures, you would still have a noticeable performance vs. reproducibility tradeoff across architectures for "real computation". For example, different architectures have different numbers of registers and different cache hierarchies, which favors different access patterns in a fast matrix multiplication; thus linear algebra routines that attempt to be as fast as possible will necessarily group the arithmetic operations differently, which leads to different results even if individual arithmetic operations are guaranteed to be identical. It's not insurmountable, but it's a thornier problem than it looks at first.

stephencanon 13y ago

Directed rounding as a thread-local state (or global state), which is what the first 25 years of IEEE-754 processors supported, turns out to be not a very useful model (except for debugging tricks like estimating stability, which is dear to Kahan); that's a big part of why directed rounding isn't widely used or supported. Several newer hardware designs have added per-instruction stateless directed rounding (the rounding direction is part of the opcode); this is a much more useful model (and its presence makes dynamic rounding modes more usable as well!). This feature was added to ieee-754 in the 2008 revision, too late for language bindings to be added to c[++]11, but there's already language support in OpenCL and other compute languages, and bindings have been proposed to the C committee. So, progress is being made, slowly but surely.

StefanKarpinski 13y ago

For what it's worth, Julia supports setting rounding modes in a way that works across both native floating-point types (Float32 and Float64) and BigFloats: http://docs.julialang.org/en/latest/stdlib/base/#Base.get_rounding http://docs.julialang.org/en/latest/stdlib/base/#Base.get_ro... This stuff is incredibly important for numerical work and it's really a shame that mainstream languages have effectively rejected this key piece of functionality – that the hardware supports. There's an open GitHub umbrella issue tracking support for all of the pieces of functionality that Kahan advocates: https://github.com/JuliaLang/julia/issues/2976 https://github.com/JuliaLang/julia/issues/2976 I'm not sure about signaling NaNs though. There have been rumblings that future hardware might not support them.