Fused polynomials do seem like a good idea (again, can be done for intervals too), but what is the end game of this approach? Is there some set of primitives that are sufficient to express all computations you might want to do in a way that doesn't lose accuracy too rapidly to be useful? It seems like the reductio ad absurdum is producing a fused version of your entire program that cleverly produces a correct interval.
On Thu, Jul 30, 2015 at 5:20 PM, Jason Merrill <[email protected]> wrote: > On Thursday, July 30, 2015 at 4:22:34 PM UTC-4, Job van der Zwan wrote: >> >> On Thursday, 30 July 2015 21:54:39 UTC+2, Jason Merrill wrote: >> >>> <Analysis of examples in the book> >>> >> >> Thanks for correcting me! The open/closed element becomes pretty crucial >> later on though, when he claims on page 225 that: >> >> a general approach for evaluating polynomials with interval arguments >>> without any information loss is presented here for the first time. >>> >> >> Two pages later he gives the general scheme for it (see attached picture >> - it was too much of a pain to extract that text with proper formatting. >> This is ok under fair use right?). >> >> Do you have any thoughts on that? >> > > The fused polynomial evaluation seems pretty brilliant to me. He later > goes on to suggest having a fused product ratio, which should largely allow > eliminating the dependency problem from evaluating rational functions. You > can get an awful lot done with rational functions. > > > <https://lh3.googleusercontent.com/-f-sYnCMJFpQ/VbqE8zbN5AI/AAAAAAAAHOk/cNTnxAUAyoU/s1600/polynomial.png>I > actually think keeping track of open vs. closed intervals sounds like a > pretty good idea. It might also be worth doing for other kinds of interval > arithmetic, and I don't see any major reason that that would be impossible. > I didn't meant to say that open vs closed intervals doesn't matter--I just > meant that it doesn't seem to be the "secret sauce" in any of the challenge > problems in Chapter 14. To me, the fused operations are the secret sauce in > terms of precision, and the variable length representation *might be* the > secret sauce for performance, but I can't really comment on that. >
