I would not say 'capacity', or 'computer'. The problem is the precision
of floating-point numbers. Floating-point can store numbers that big,
but not exactly. If you did the computation with extended integers, you
could also get an exact answer, but much more slowly without the special
code.
Henry Rich
On 7/29/2018 2:10 PM, Brian Schott wrote:
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
---
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
