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 <ste...@karpinski.org> wrote: > This doesn't seem any better than "try the computation with Float128s". > > On Thu, Jul 30, 2015 at 10:27 AM, Tom Breloff <t...@breloff.com> 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 < >> stevenj....@gmail.com> 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. >>> >>> >> >
