Jose Mario Quintana wrote: >John > has exhibited several advantages of adopting the IEEE support which I find > quite convincing (search the forum: all IEEE; author randall). Yet it has > not happen, although (the IEEE) -0 might sneak into J it is virtually > useless. > > I can presume some potential reasons for not adopting it: > > 0. Backwards compatibility. However, J does not have a strong, to put it > mildly, tradition in this regard. > 1. It might be not that easy to implement. > 2. It is not a priority. > 3. It would make J less portable across different platforms. > 4. There could be unavoidable consequential disadvantages linked to the > adoption. > > Given what I know so far, I would go the IEEE way; and I, for one, would > like to know counterarguments related to 4 (even if only for academic > reasons). > I agree with reasons 0 through 2, and would also like to know more about 4.
I disagree with reason 3. Almost every modern computer has IEEE 754 doubles. The main problem is in library support. I have previously advocated using fdlibm rather than platform libms: it is not perfect, but it is better than most, and it is platform-independent. MATLAB, the leader in desktop floating-point applications, uses fdlibm, and enables 80-bit long doubles when available (that is, on all PC architecture except DEC Alpha and a couple of other dinosaurs). J's philosophy is not really compatible with the strict typing needed for serious floating-point calculations, so I am not pressing for language changes. Apropos this topic, some have suggested arbitrary precision floating-point numbers and symbolic calculations. I believe, from experience with languages that support them, that the precision/speed tradeoff with the former is prohibitive, and that the latter requires such a radically different execution model that it would lose many of J's advantages. I believe better directions are: - Developing better interfaces between J and numerical libraries written in other languages, and improving their performance. LAPACK and FFTW a good start, but the interfaces leave something to be desired, and they are not fast. There are many libraries that have been tested and developed over the years, and you would not want to start from scratch trying to implement them in pure J. We just need to be able to use them easily. - Achieving better performance through hardware (not platform) dependent code, as has been done successfully with the BLAS. This facilitates better performance across a variety of hardware and supplies an entry point to take account of future developments. For example, J's LAPACK uses a Fortran-to-C version and the reference (lowest common denominator) BLAS. It could run a lot faster. Of course, I am not implementing any of this myself, so it's all simple to me. I would be interested in any response from those who would do it. Best wishes, John ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
