So, Henry (et al), I think you're suggesting an explanation like the following to replace the existing explanation which I include further below. Yes?
******proposed rewrite below ******* Although the example below does not suggest a problem because the numbers are relatively moderate here, terms like 15^22 which are embedded in this example can get very large very quickly with more realistic numbers and may exceed the capacity of the computer. cs=.29 15(cs&|@^)22 5 3 20 15 18 6 10 11 24 14 9 This is easily solved since ******proposed rewrite above ******* *******The existing example and wording are provided just below******* cs=.29 15(cs&|@^)22 5 3 20 15 18 0 10 11 0 0 0 The zeros in the above indicate that there is a problem, namely that numbers such as 1522 are very large and exceed the capacity of the computer. This is easily solved since *******The existing example and wording are provided just above******* On Sun, Jul 29, 2018 at 9:48 AM, Henry Rich <[email protected]> wrote: > Special code is not the problem, it's the solution. The system is doing > what you ask of it. > > 15(^)22 5 3 20 15 18 > 7.48183e25 759375 3375 3.32526e23 4.37894e17 1.47789e21 > > ^ produces floating-point results. If they require more than 53 bits of > significance you will lose low-order bits and the result after dividing by > cs will be garbage. > > cs&|@^ takes the modulus after each multiplication and avoids the loss of > significance. > > Henry Rich > > > -- (B=) ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
