If correct rounding is a goal: For almost all Float64 arguments to elementary functions, working with 120bit significands will assure an accurately rounded result almost always and working with 168bit significand obtains a correctly rounded Float64 value all the time (at least for the functions I have seen analyzed). An accurately rounded result is obtainable working with less precision much of the time, say 80bits of significand (just a guess); rarely will the required precision be that of the input.
see the papers of Vincent Lefevre e.g. Worst Cases for Rounding Elementary Functions in Double Precision <http://perso.ens-lyon.fr/jean-michel.muller/TMDworstcases.pdf> Worst Cases for the Exponential Function in decimal64 <http://perso.ens-lyon.fr/damien.stehle/downloads/decimalexp.pdf> On Thursday, July 30, 2015 at 11:08:50 AM UTC-4, Tom Breloff wrote: > > It's better in the sense that you have a reason to try it with a larger > type. You know exactly how much precision you've lost, and so you can > decide to use up to 1024 bits for intermediate calculations if you need > to. If "sqrt(2)" is part of your calculation, the inexact field for floats > will be set no matter the calculation, and you only know that "my answer is > always wrong". I wouldn't exactly call this a useful/actionable statement. > > On Thu, Jul 30, 2015 at 10:58 AM, Stefan Karpinski <[email protected] > <javascript:>> wrote: > >> This doesn't seem any better than "try the computation with Float128s". >> >> On Thu, Jul 30, 2015 at 10:27 AM, Tom Breloff <[email protected] >> <javascript:>> wrote: >> >>> Steven: There is a section in the book dedicated to writing dynamically >>> scaling precision/accuracy into your algorithms. The idea is this: >>> >>> - Pick a small format unum at the start of your algorithm. >>> - During the algorithm, check your unums for insufficient >>> precision/accuracy in the final interval. >>> - As soon as you discover the intervals getting too large, restart with >>> a new "unum environment". >>> >>> Obviously this type of resetting shouldn't be default behavior, but the >>> point is that you have as much flexibility as you need to precisely define >>> the level of detail that you care about, and there is sufficient >>> information in your result that you can re-run with better settings if the >>> result is unsatisfactory. >>> >>> The problem with floats is that you can get the result of a black-box >>> calculation and have NO IDEA how wrong you are... only that your solution >>> is not exact. This concept should make you skeptical of every float >>> calculation that results with the inexact flag being set. >>> >>> >>> On Thu, Jul 30, 2015 at 10:07 AM, Steven G. Johnson <[email protected] >>> <javascript:>> wrote: >>> >>>> On Wednesday, July 29, 2015 at 5:47:50 PM UTC-4, Job van der Zwan wrote: >>>>> >>>>> On Thursday, 30 July 2015 00:00:56 UTC+3, Steven G. Johnson wrote: >>>>>> >>>>>> Job, I'm basing my judgement on the presentation. >>>>>> >>>>> >>>>> Ah ok, I was wondering I feel like those presentations give a general >>>>> impression, but don't really explain the details enough. And like I said, >>>>> your critique overlaps with Gustafson's own critique of traditional >>>>> interval arithmetic, so I wasn't sure if you meant that you don't buy his >>>>> suggested alternative ubox method after reading the book, or indicated >>>>> scepticism based on earlier experience, but without full knowledge of >>>>> what >>>>> his suggested alternative is. >>>>> >>>> >>>> From the presentation, it seemed pretty explicit that the "ubox" method >>>> replaces a single interval or pair of intervals with a rapidly expanding >>>> set of boxes. I just don't see any conceivable way that this could be >>>> practical for large-scale problems involving many variables. >>>> >>>> >>>>> Well.. we give up one bit of *precision* in the fraction, but *our >>>>> set of representations is still the same size*. We still have the >>>>> same number of floats as before! It's just that half of them is now exact >>>>> (with one bit less precision), and the other half represents open >>>>> intervals >>>>> between these exact numbers. Which lets you represent the entire real >>>>> number line accurately (but with limited precision, unless they happen to >>>>> be equal to an exact float). >>>>> >>>> >>>> Sorry, but that just does not and cannot work. >>>> >>>> The problem is that if you interpret an exact unum as the open interval >>>> between two adjacent exact values, what you have is essentially the same >>>> as >>>> interval arithmetic. The result of each operation will produce intervals >>>> that are broader and broader (necessitating lower and lower precision >>>> unums), with the well known problem that the interval quickly becomes >>>> absurdly pessimistic in real problems (i.e. you quickly and prematurely >>>> discard all of your precision in a variable-precision format like unums). >>>> >>>> The real problem with interval arithmetic is not open vs. closed >>>> intervals, it is this growth of the error bounds in realistic computations >>>> (due to the dependency problem and similar). (The focus on infinite and >>>> semi-infinite open intervals is a sideshow. If you want useful error >>>> bounds, the important things are the *small* intervals.) >>>> >>>> If you discard the interval interpretation with its rapid loss of >>>> precision, what you are left with is an inexact flag per value, but with >>>> no >>>> useful error bounds. And I don't believe that this is much more useful >>>> than a single inexact flag for a set of computations as in IEEE. >>>> >>>> >>> >> >
