There is a Mathematica notebook on CRC's website at https://www.crcpress.com/The-End-of-Error-Unum-Computing/Gustafson/9781482239867 . Please look under "Downloads/Updates". I haven't looked at it to know what it contains. There's also a video corresponding to the pdf presentation that Jo van Schalykwyk shared at http://insidehpc.com/2015/03/slidecast-john-gustafson-explains-energy-efficient-unum-computing/
On Thu, Apr 28, 2016 at 6:04 AM, Raul Miller <[email protected]> wrote: > Well, I guess the thing to do is implement unums and try them out. > I'm not sure, though, if they have given enough information on how > they should work for us to implement them in J? > > (Given any system of numbers, there are going to be some things that > they are good at - but those particular calculations from that pdf > were not the ones that I have been using. Probably the first thing I > would try is a few A %. B examples, and then I might try something > which takes time and a lot of iterations to stabilize.) > > Thanks, > > -- > Raul > > > On Thu, Apr 28, 2016 at 3:50 AM, Jo van Schalkwyk > <[email protected]> wrote: >> Umm, Raul, I've had a glance at some of the documentation and I'm not sure >> you're right here. Check out: >> >> http://arith22.gforge.inria.fr/slides/06-gustafson.pdf >> >> The bit on "The Wrath of Kahan" struck me as fairly convincing. >> >> My 2c, Jo. >> >> On 28 April 2016 at 16:58, Raul Miller <[email protected]> wrote: >> >>> When I run through my head examples of how that would work in >>> algorithms I have worked on, it seems to me that it (a) it starts out >>> with less precision than floating point (because of the extra bits >>> being used for representing an estimate of accuracy), and (b) that it >>> would tend to also lose precision faster (because it started out with >>> less, so the fractional bits being lost are more significant). >>> >>> Put differently: as long as (a) this representation stays close to >>> original data, and (b) the people using it understand in detail how it >>> works, it will probably be ok. But run this through a lengthy sequence >>> of calculations and it'll mess up faster than floating point. >>> >>> Put differently: I prefer J's approach of providing ":!.precision (or >>> 9!:11) over these things. >>> >>> That said, running through the calculation once using unums (to get a >>> precision estimate) and then running through it again using floating >>> point (to get a more precise result) might be a useful approach (for >>> applications where the factor of 2 time and space cost is acceptable). >>> >>> That said, it is fun reading about how other people think about these >>> things. >>> >>> Then again, there presumably must be applications where unums are a >>> better fit than floating point? (I just don't know much about what >>> those might be, off the top of my head.) >>> >>> -- >>> Raul >>> >>> >>> >>> On Wed, Apr 27, 2016 at 11:36 PM, 'Jon Hough' via Chat >>> <[email protected]> wrote: >>> > This interview is pretty interesting, about a new number format that >>> will solve floating point related errors: >>> > http://ubiquity.acm.org/article.cfm?id=2913029 >>> > >>> > see also: >>> http://motherboard.vice.com/read/a-new-number-format-for-computers-could-nuke-approximation-errors-for-good >>> > >>> > I wonder about a J implementation of unums... ...it seems Julia (among >>> others) has one >>> > https://github.com/REX-Computing/unumjl >>> > >>> > ---------------------------------------------------------------------- >>> > For information about J forums see http://www.jsoftware.com/forums.htm >>> ---------------------------------------------------------------------- >>> For information about J forums see http://www.jsoftware.com/forums.htm >>> >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
