Actually, Jason, the book went through intense peer review repeatedly for over a year before it hit the shelves. Horst Simon, the series editor, vetted the manuscript and made sure William Kahan saw it as well. Kahan, the guy behind the IEEE 754 Standard for floats and a Turing Award recipient, was surprisingly unable to punch holes in it the way he has always torn down proposed alternatives to existing floats. David Bailey and John Runnels were two of the formal referees, and another referee preferred to remain anonymous. If you look at the Acknowledgments section in the prefatory material, you can see a list of all the people who pored over the material and made sure it was sound. No one has found any *conceptual* errors yet, though there are some minor Errata and they are posted on the CRC Press site for the book. There was also one minor typo in a subscript in the Mathematica notebook, now corrected, but other than that no one has found any bugs in it. Jack Dongarra, Gordon Bell, and Ulrich Kulisch (interval arithmetic expert and inventor of the exact dot product accumulator) also gave it a thumbs-up.
I knew I was going out on a limb with this idea, so I sought out the harshest critics I could find and made sure it could pass their tests before going to press. That said, I agree with the "grain of salt" comment, because the Mathematica notebook is too slow to try unum math out on *really* large problems. It may turn out that the ubox method becomes intractable even though the number of uboxes expands linearly instead of exponentially, and that will mean using unums as float-imitators to get things to run. What we need now is a much faster implementation. Which is exactly why putting unums in Julia is such a great idea! On Thursday, July 30, 2015 at 10:07:01 AM UTC-7, Jason Merrill wrote: > > On Wednesday, July 29, 2015 at 5:31:12 PM UTC-4, Stefan Karpinski wrote: >> >> The most compelling part of the proposal to me was the claim of >> associativity, which I suppose comes along with the variable precision >> since you can actually drop trailing bits that you can't get right. >> > > I bought a copy of the book, because I'm a sucker for this kind of thing. > There's a lot of fascinating material in the book, and I would generally > recommend it, with the caveat that it seems like some of it needs to be > taken with a grain of salt. Remember that it's a manuscript that hasn't > gone through the kind of peer review that journal articles do. > > Associativity sounded pretty exciting to me, too, but you have to do > special work to get it. If a, b, and c are unums or ubounds, it is *not* > the case that you will always have (a+b)+c=a+(b+c), if you write the > calculation that way. Like other kinds of interval arithmetic, ubounds obey > sub-associativity, which says that the two sides of that equation are "not > nowhere equal", and that their intersection contains the exact answer. > > The way you get associativity is by using a fused sum operation that > internally accumulates sums with enough precision to restore associativity > of the rounded end results. Here's a page from the book: > > > https://books.google.com/books?id=fZsXBgAAQBAJ&pg=PA164&lpg=PA164&dq=subassociative+interval+arithmetic&source=bl&ots=MH0veKCw9Y&sig=sq9atiYn46w2rvuT26E3fLbUnOg&hl=en&sa=X&ved=0CDYQ6AEwA2oVChMIi7Dyt6eDxwIVA24-Ch3gjg-7#v=onepage&q=subassociative%20interval%20arithmetic&f=false > > Gustafson's whole proposal involves standardizing several layers of > computation, including what happens in a higher precision scratchpad that > is imagined to be in hardware and fenced off from the user. IEEE floating > point arithmetic also works with a higher precision scratchpad, but exactly > what happens there is a little bit under constrained, and has varied > between different processors. Standardizing the scratchpad, and which fused > operations will keep their operands there, seems to be an important part of > the proposal. > > I'm pretty interested in more discussion of the book, but this mailing > list probably isn't the right place for a wide ranging discussion to > happen. Does anyone have any advice about other appropriate forums? >
