The basic problem here is the limits of the IEEE-754 floating point representation. When you are computing with numbers that are near the max or min values of the range of numbers representable in the IEEE format, strange things can happen. Over the years, programmers have learned to live with this problem, and they have devised various workarounds: switch from 32-bit to 64-bit precision (128 bit?), or use something like J's extended precision (slow, but more accurate.).
John Gustafson, a computer scientist (https://goo.gl/W5T5Gd), got fed up with this problem and proposed a fix for the IEEE 754 limitations in his book, which is rather confidently named "The End of Error" ( https://goo.gl/t5AZ1k). The primary goal of the new number format, which John called "unums" (for universal numbers) was to minimize the probability of error in computations, while maintaining some compatibility with the IEEE-754 standard. Probably more important, by incorporating the concepts of interval arithmetic, the unum format provided the capability for the programmer to know when the result of a computation was imprecise, and even know the boundaries of the impreciseness. Gustafson's book caused a bit of a stir in the computer world, particularly from William Kahan, the principal architect of IEEE 754 standard. Gustafson and Kahan debated the issues in a recorded presentation ( https://goo.gl/bkU3ab). Responding to Kahan's criticism, Gustafson proposed Unum 2.0, which discards the attempts at IEEE 754 compatibility by using variable-length words. (https://goo.gl/JwCEsY) This improved storage efficiency and accuracy, but complicated the hardware design. Recently John and Isaac Yonemoto proposed yet another tweak on John's unum ideas in their new paper, again rather confidently titled "Beating Floating Point at its Own Game: Posit Arithmetic" https://goo.gl/Gpvm9q. They call this number format Unum Type 3, which is more hardware-friendly, as it eliminates variable-length words. In the paper, John & Isaac give a nice overview of the unum development path that was taken through unums type 1, 2, and 3. Like J, Gustafson he tends to repurpose English words for unum's concepts. There are two types of results in type 3 unums: "posits" and "valids". You should read the paper to understand these concepts. Gustafson has made a significant attempt to solve the problem that Rob encountered, and which programmers have learned to live with since the beginning of electronic computers. However, the IEEE 754 standard is currently ubiquitous, and it will take a long time (if ever) to unseat it. Roger Stokes has provided a learning lab for unum 2.0 in the J language. The discussion about this lab is in the J Programming forum archives at: https://goo.gl/qDQ9vC There is a Conference for Next Generation Arithmetic scheduled in Singapore next year https://posithub.org/ where these issues will be discussed. In any case, running on a computer using something like Gustafson's unums would likely have prevented the problem Rob encountered. Skip Skip Cave Cave Consulting LLC On Thu, Sep 7, 2017 at 8:19 PM, Don Kelly <d...@shaw.ca> wrote: > Yet this works > > n=:14 > > (n^2x) |5729082486784839 > > 147 > > > Don Kelly > > > On 2017-09-07 11:40 AM, Erling Hellenäs wrote: > >> Hi all ! >> >> Case 1: >> 3!:0 [ (n^2) >> >> 8 >> >> (n^2) | 5729082486784839 >> >> 0 >> >> It is non-intuitive that an integer raised to an integer is a float, but >> I think it is normal. It would be possible with a performance penalty to >> get an integer result. One problem with that is that it would easily >> overflow. It would also be possible to have a special operation for this >> case. >> When the left argument is a float the right argument has to be converted >> to a float. It must be assumed that this conversion is intentional, even >> though it is implicit. >> >> Case 2: >> 3!:0 [ (n^2) >> >> 8 >> >> (n^2) | 5729082486784839x >> >> 0 >> >> 3!:0 (n^2) | 5729082486784839x >> >> 8 >> >> Here the rational seems to be converted to a float and the result is >> float. Shouldn't we have an error instead of converting rationals to float? >> >> Case 3: >> >> 3!:0 (x: n^2) >> >> 128 >> >> (x: n^2) | 5729082486784839 >> >> 0 >> >> 3!:0 (x: n^2) | 5729082486784839 >> >> 128 >> >> I have a hard time understanding what happens here. This result seems >> very peculiar. Is the left and right argument converted to float and the >> float result converted to rational?! >> Shouldn't we have an error instead of converting rationals to float? >> We could not have floats auto-converted to rationals? >> In this case the integer should be converted to rational and we should >> get a rational result? >> >> It is non-intuitive that (*: n) does not give the same result as (n^2). >> Maybe once this was decided because of performance reasons. >> >> Cheers, >> >> Erling Hellenäs >> >> On 2017-09-05 18:41, Rob B wrote: >> >>> Could someone explain this please? >>> >>> n=.14 >>> n >>> 14 >>> (*: n) | 5729082486784839 >>> 147 >>> 196 | 5729082486784839 >>> 147 >>> (n^2) | 5729082486784839 >>> 0 >>> (n^2) | 5729082486784839x >>> 0 >>> (x: n^2) | 5729082486784839 >>> 0 >>> (x: n^2) | 5729082486784839x >>> 147 >>> >>> >>> Regards, Rob Burns >>> ---------------------------------------------------------------------- >>> For information about J forums see http://www.jsoftware.com/forums.htm >>> >> >> >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm >> > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
