Note that unums are limited precision also, and have their own edge cases. Thanks,
-- Raul On Fri, Sep 8, 2017 at 3:25 AM, Skip Cave <s...@caveconsulting.com> wrote: > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
