More specifically: to be mathematically accurate these intervals would have to represent worst case possibilities. But to be relevant they would have to represent typical case possibilities. There's an inherent tension there which really needs some contextual thought by the developer.
Thanks, -- Raul On Fri, Sep 8, 2017 at 6:46 AM, Raul Miller <rauldmil...@gmail.com> wrote: > 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
