I finally get what Henry is talking about. Sorry to have misunderstood. And I have gone through similar calculations as Raul.
One point in this is that you have to be careful about powers of 2 and the exact way the calculation is done. In calculating !19, for example, powers of 2 in the product are in the characteristic not the mantissa. A further point is that x: has "implied tolerance": it is only producing an extended integer or rational number that is tolerantly equivalent to its argument. We can see more clearly what is going on by looking at: 'p q'=:2 x: 4*!19 p 33437550590372456995572480375 q 68719476736 _ q: q 36 2^.p 94.7555 So q is 2^36, and p is expressed with 95 significant bits, almost half of which are garbage. Factoring out the power of 2 in 4*!19 makes it a bit more murky. 1 q: 4*!19x 18 so 2^18 divides it. This knocks down the number of bits from 59 to 41 which is within reason. Best wishes, John Miller, Raul D wrote: > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
