There is no question that getting rigorous, tight bounds is going to cost something compared to the guesswork of conventional floating point. Interval arithmetic has failed for the last fifty years because it requires a LOT of work and expertise to keep the bounds from exploding; the ubox method requires no expertise but puts the burden on the computer. And it's a massively parallel burden, providing something to do with all those cores we never seem to be able to fully utilize. And if you don't like the ubox approach, unums can perfectly emulate existing floating point, so every algorithm that works for floats also works for unums.
I made considerable effort not to "cherry pick" examples because I've seen far too much of that in papers about computation. So I used problems from others, not of my own invention, and the classic problems of numerical methods texts: polynomial evaluation, systems of linear equations, ordinary and partial differential equations, Fast Fourier Transforms, etc. On Wednesday, July 29, 2015 at 7:10:53 AM UTC-7, Job van der Zwan wrote: > > On Wednesday, 29 July 2015 16:50:21 UTC+3, Steven G. Johnson wrote: >> >> Regarding, unums, without hardware support, at first glance they don't >> sound practical compared to the present alternatives (hardware or software >> fixed-precision float types, or arbitrary precision if you need it). And >> the "ubox" method for error analysis, even if it overcomes the problems of >> interval arithmetic as claimed, sounds too expensive to use on anything >> except for the smallest-scale problems because of the large number of boxes >> that you seem to need for each value whose error is being tracked. >> > > Well, I don't know enough about traditional methods to say if they're > really as limited as Gustafson claims in his book, or if he's just > cherry-picking. Same about the cost of using uboxe > > However, ubound arithmetic tells you that 1 / (0, 1] = [1, inf), and that > [1, inf) / inf = 0. The ubounds describing those interval results are > effectively just a pair of floating point numbers, plus a ubit to signal > whether an endpoint is open or not. That's a very simple thing to > implement. Not sure if there's any arbitrary precision method that deal > with this so elegantly - you probably know better than I do. >
