Zenna, If unums are used without the ubox method and some of the other techniques described in the book (like tightest-possible evaluation in the *g*-layer for a well-defined set of functions), they will indeed fall prey to two of the main problems of interval arithmetic: the dependency problem and the wrapping problem. That is why it is essential to use the ubox method, and not blindly replace all the floats in a calculation with unums and expect magical things to happen. Unlike interval arithmetic, though, the ubox method requires no expertise. It's a brainless, brute force approach.
On Wednesday, July 29, 2015 at 1:59:02 PM UTC-7, Zenna Tavares wrote: > > I read the book (well, somewhere between a skim and a proper read). It's > not formal but it is clear and the ideas are concise. > I actually think it's a pretty good example of how to explain an idea > without unnecessary jargon. > > As for unums themselves, I am mostly convinced of his arguments on unums. > I am less convinced on ubounds. > > My main takeaways are that a unum may represent a set of values, and it's > most salient properties are: > > - Explicit (via ubit) handling of exact and inexact (i.e. set of) real > number > - Correct handling of open/closed bounds for sets of reals > - Variable size with size of number stored in number > - With hardware they could be as or more efficient in energy and speed as > floating arithmetic but hardware would be more complex > > As a result of these properties, unums can be closed under arithmetic > operations and won't hide your errors due to approximation. > > I don't buy the advantages he suggests over interval arithmetic; unums > don't solve the dependency problem. > > I have been meaning to start a Unum.jl package myself. > > Zenna > > > > On Saturday, July 25, 2015 at 9:11:54 AM UTC-4, Job van der Zwan wrote: >> >> So I came across the concept of UNUMs on the Pony language mailing list >> <http://lists.ponylang.org/pipermail/ponydev/2015-July/000071.html> this >> morning. I hadn't heard of them before, and a quick search doesn't show up >> anything on this mailing list, so I guess most people here haven't either. >> They're a proposed alternate encoding for numbers by John L. Gustafson. >> This presentation by him sums it up nicely: >> >> http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf >> >> “Unums”(universal numbers) are to floating point what floating point is >>> to fixed point. >>> Floating-point values self-describe their scale factor, but fix the >>> exponent and fraction size. Unums self-describe the exponent size, fraction >>> size, and inexact state, and include fixed point and IEEE floats as special >>> cases. >>> >> >> The presentation can be seen here, provided you have the Silverlight >> plugin: >> >> >> http://sites.ieee.org/scv-cs/archives/right-sizing-precision-to-save-energy-power-and-storage >> >> Now, I don't know enough about this topic to say if they're a good or bad >> idea, but I figured the idea is interesting/relevant enough to share with >> the Julia crowd. >> >> I'm also wondering if they could be implemented (relatively) easily >> within Julia, given its flexible type system. If so, they might provide an >> interesting advanced example, no? >> >
