4 ms·

Given the problems with Java's floating-point implementation [1], would this be reliable for statistical analysis? [1] https://news.ycombinator.com/item?id=658

by ubasu 13y ago

Given the problems with Java's floating-point implementation [1], would this be reliable for statistical analysis? [1] https://news.ycombinator.com/item?id=6585828 https://news.ycombinator.com/item?id=6585828

aardvark179 13y ago
The semantics of Java need not restrict what other languages on the JVM do, though it may make the generated byte code a little larger from the inclusion of f2d and d2f instructions.
pron 13y ago
1. It is more a philosophical disagreement than a problem, and whatever the semantics you want, the JVM does not limit you. The disagreement revolves around the Java compiler and language semantics, not the JVM. 2. The math in FastR, if I understand the presentation correctly, is performed by FORTRAN libraries anyway. Using battle tested FORTRAN libraries for matrix computations is common practice in C, Java, Julia, Matlab and most other environments. They basically all share the same underlying matrix math code.
- StefanKarpinski 13y ago
  I do think that Kahan's objections to Java's floating-point support were more than just philosophical, although it's unclear to me at this point how many of them still apply. The biggest issue that seems to still remain is that you can't change rounding modes or check flags, both of which are essential for verifying numerical stability and correctness. Far worse than any floating-point issues on the JVM is that your indices and integers are 32-bit, so you're limited to 2GB arrays before you have to take bizarre measures to access larger amounts of data. Although it is standard in high-level systems to call out to a BLAS library [1], for some inexplicable reason it seems that both R and NumPy use the reference BLAS by default, which is quite slow – around 4x slower than better BLASes. Matlab ships with Intel's proprietary MKL, which includes a very fast BLAS implementation, while Julia ships with OpenBLAS, which is a similarly fast open source BLAS implementation derived from the legendary GotoBLAS [2]. Since all BLAS implementations share a common Fortran ABI, it's easy to swap them out, but it's not quite true that all of these systems are using the exact same Fortran code. [1] https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprograms https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprogra... [2] https://en.wikipedia.org/wiki/GotoBLAS https://en.wikipedia.org/wiki/GotoBLAS
  - pron 13y ago
    There is a lot of work going into designing java arrays "2.0", including support for "long" arrays, immutable arrays, and arrays of structs.
bedatadriven 13y ago
These are points that need to be addressed for any implementation of R, or any other domain specific language for which numerical guarantees nearly always outweigh performance concerns. GNU R, for example, is implemented in C, and the implementations of R's basic arithmetic functions are actually quite complicated because they take care of so many of the edge cases cited in the cited post. For example, the round() function casts its argument first to a 64-bit before calling the C library's rint() function to preserve precision. [1] [1] http://svn.r-project.org/R/trunk/src/nmath/fround.c http://svn.r-project.org/R/trunk/src/nmath/fround.c

by ubasu 13y ago

aardvark179 13y ago

The semantics of Java need not restrict what other languages on the JVM do, though it may make the generated byte code a little larger from the inclusion of f2d and d2f instructions.

pron 13y ago

1. It is more a philosophical disagreement than a problem, and whatever the semantics you want, the JVM does not limit you. The disagreement revolves around the Java compiler and language semantics, not the JVM. 2. The math in FastR, if I understand the presentation correctly, is performed by FORTRAN libraries anyway. Using battle tested FORTRAN libraries for matrix computations is common practice in C, Java, Julia, Matlab and most other environments. They basically all share the same underlying matrix math code.

StefanKarpinski 13y ago
I do think that Kahan's objections to Java's floating-point support were more than just philosophical, although it's unclear to me at this point how many of them still apply. The biggest issue that seems to still remain is that you can't change rounding modes or check flags, both of which are essential for verifying numerical stability and correctness. Far worse than any floating-point issues on the JVM is that your indices and integers are 32-bit, so you're limited to 2GB arrays before you have to take bizarre measures to access larger amounts of data. Although it is standard in high-level systems to call out to a BLAS library [1], for some inexplicable reason it seems that both R and NumPy use the reference BLAS by default, which is quite slow – around 4x slower than better BLASes. Matlab ships with Intel's proprietary MKL, which includes a very fast BLAS implementation, while Julia ships with OpenBLAS, which is a similarly fast open source BLAS implementation derived from the legendary GotoBLAS [2]. Since all BLAS implementations share a common Fortran ABI, it's easy to swap them out, but it's not quite true that all of these systems are using the exact same Fortran code. [1] https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprograms https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprogra... [2] https://en.wikipedia.org/wiki/GotoBLAS https://en.wikipedia.org/wiki/GotoBLAS
- pron 13y ago
  There is a lot of work going into designing java arrays "2.0", including support for "long" arrays, immutable arrays, and arrays of structs.

bedatadriven 13y ago

These are points that need to be addressed for any implementation of R, or any other domain specific language for which numerical guarantees nearly always outweigh performance concerns. GNU R, for example, is implemented in C, and the implementations of R's basic arithmetic functions are actually quite complicated because they take care of so many of the edge cases cited in the cited post. For example, the round() function casts its argument first to a 64-bit before calling the C library's rint() function to preserve precision. [1] [1] http://svn.r-project.org/R/trunk/src/nmath/fround.c http://svn.r-project.org/R/trunk/src/nmath/fround.c