Henry Rich wrote: > 1. J uses 64-bit floating point, so 4*a can be > represented exactly. > > 2. If the exponent is big enough, the floating-point value > will be an integer. It may not be the integer you wanted, > but it can have only 54 or so bits of integer+fraction.
64 bit ieee floating point numbers explicitly represent 52 bits in the mantissa, with an extra bit implied by the representation. That's 53 bits of precision. http://en.wikipedia.org/wiki/IEEE_754#Double-precision_64_bit 4*!19 takes 59 bits to represent (##:4*!19). That's 6 bits more than can be represented by the mantissa. The difference (x&.#:4*!19)-x:4*!19 is about 27, which takes five bits to represent. #:27 1 1 0 1 1 In other words, the inaccuracy here is less than half of the magnitude of the least significant bit. Decimal fractions cannot be represented exactly in ieee floating point notation. 3!:3 %5 e1000000 08000000 01000000 00000000 9a999999 9999c93f And, it's my understanding that the current implementation of rationals and extended precision numbers in J is decimal in nature. In part, I think this is because the c language (on which J is based) isn't very good about dealing with the overflow which can happen when you multiply two numbers, which takes some of the luster out of trying to use the available bits efficiently. And, in part, I think this is because it's easy to implement ": for a decimal representation. If these numbers were represented in binary, ": would become more expensive, as would ". So what I think we're seeing here is a mis-match between ieee representation (where numbers are represented as binary fractions) and extended precision notation (where numbers are represented as hyper-decimal numbers. The details probably fall out of the specific implementation for x: -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
