Hmmm.
I see what you mean Bill. There really wasn't an "overflow" as such. The J
interpreter just switched from integer arithmetic to floating point because
the calculation had gotten larger than what could be handled in 64-bit
binary. It looks like the Residue primitive doesn't deal well with large
floating point numbers.
13|10^10
3 NB. Everything is good.
13|10^100
0 NB. No indication that things are not so good
(reasonable-seeming answer)
13|10^100x
3 NB. The right answer.
datatype 13|10^10
integer
datatype 13|10^100
floating
So the problem remains. The second answer is wrong, and there should be
some notification that we are in trouble. Maybe there should be a test in
the Residue primitive to check for floating point numbers that are too big
for it to find the residue.
The residue verb handles small floating point numbers fine:
5| 33 + %3
3.33333
However, at some point with large floating point numbers, the residue
function gets off track:
13 | 10^i.20
1 10 9 12 3 4 1 10 9 12 3 4 1 10 0 0 0 0 0 0
13 | 10^i.20x
1 10 9 12 3 4 1 10 9 12 3 4 1 10 9 12 3 4 1 10
Not sure how to fix this. Should the residue throw an error? It probably
can't switch to extended this late in the process, so that may be the best
approach.
Skip
Skip Cave
Cave Consulting LLC
On Sun, Oct 8, 2017 at 12:22 AM, bill lam <[email protected]> wrote:
> If I understand correctly, you meant J should raise an
> domain (or other type) error and abort execution. But since
> J does not look ahead, it can not know the overflow that
> promoting integer to float would cause wrong answer in the
> next step. We can implement different rules for integer
> overflow.
> 1. promote to float
> 2. promote to extended integer
> 3. ignore overflow (wrapping round)
> 4. raise an error
>
> 1 (current behavior) is what most of us expected
> 2 more suitable for solving problems in Euler project.
> 3 is excellent for speed efficiency
> 4 might be what you wanted
>
> Сб, 07 окт 2017, JBeta написал(а):
> > Bill Lam asked:
> >
> > What is your expected result for the case you quoted?
> >
> > The problem is:
> >
> > 13 | */ 13 | 10 # 19 29 59 79 89 109 119 139 149 179 199
> > 0
> >
> > Which is the wrong answer. However, there is no indication that anything
> > went wrong,
> > Since no error notification occurred, I would reasonably assume that I
> > have the right answer.
> > Actually, the result in this case should *not* be zero. It should be
> > something like:
> > "floating point overflow occurred", or "numeric value out of bounds"
> >
> > That would tell me that I need to do something like - try extended
> integers:
> >
> > 13 | */ 13 | 10 # 19 29 59 79 89 109 119 139 149 179 199x
> >
> > 9
> >
> > Which is the right answer.
> >
> > Skip
> >
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
