Roger Hui wrote: > a. It would be useful to compile a list of the cases > where you feel J primitives return results that differ > from what "IEEE support" would provide. For example: > > 0. 0%0 > 1. tolerant comparison > etc. > > b. One possible approach for a programming language > to take is, for the arithmetic primitives, just > return what the hardware produces. For example, > 1234567890 + 2223334440 would be a negative integer > rather than the 64-bit floating point number 3.4579e9. > >
I remain unconvinced that "IEEE support" is completely relevant to J, since one of the strengths of the language is the ability to ignore actual types of numerical data. J can already represent _ and __ . I assume that NaN results in domain error. There is some argument for representing +/-0, but I am not sure this is completely helpful. It would change 0%0 in incompatible ways. I am happy with tolerant comparison. Most of the concerns about floating-point arithmetic come from inaccurate libraries, and some platform inconsistencies like the "Fused MAC" problem. J's policy of changing integer to floating-point rather than the overflow value is very useful. It gives a plausible rather than an unsignalled erroneous result. (Actually, with the example given, I get the integer 3457902330 on a 64-bit machine.) You can use x: if you really want bigger integers. If you are twiddling the bits of integers based on their hardware representation, J's numerical model is not completely helpful. On the other hand, sticking with hardware floating-point values seems fine. Any implementations of arbitrary precision floating-point arithmetic I have used (for example, in Maple and Mathematica) have been painfully slow. I would be reluctant to change the language, but I would be concerned about the quality of libraries, both in software and the microcoded functions like FSIN. Most of the topics raised on this forum about floating-point numbers have involved misunderstandings about their nature (e.g. printing numbers to greater precision than they are represented, value of pi, etc.) than the way J implements them, other than it ought to be magic. Best wishes, John ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
