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
