I expect this would tend to decay rather rapidly, for example if you did something like -/x where x was long and not integer.
Thanks, -- Raul On Fri, Sep 8, 2017 at 5:47 AM, Skip Cave <s...@caveconsulting.com> wrote: > Raul said: Note that unums are limited precision also, and have their own > edge cases. > > Yes, but unums will let you know when an edge case occurs, and give you an > interval within which the correct answer will reside. > > Skip > > > Skip Cave > Cave Consulting LLC > > On Fri, Sep 8, 2017 at 3:37 AM, Raul Miller <rauldmil...@gmail.com> wrote: > >> 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 >> > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
