13|10^100 0 NB. No indication that things are not so good
The problem is that | has no idea that the right argument had been promoted from integer to float. If someone actually wanted to calculate 13|(some float) the answer returned by J is good. What you expected is integer to be promoted a to new type of float which can provide hint to | that it should raise an error instead of giving 0 (or other value) as result. Вс, 08 окт 2017, JBeta написал(а): > 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 -- regards, ==================================================== GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
