In these slides (Ulrich) Kulisch was mentioned from which I downloaded a recent 
paper 
"Up-to-date Interval Arithmetic: From Closed Intervals to Connected Sets of 
Real Numbers" (2016).
Anyone interested for a digital copy, contact me off-forum.


R.E. Boss



> -----Original Message-----
> From: Chat [mailto:[email protected]] On Behalf Of Jo
> van Schalkwyk
> Sent: donderdag 28 april 2016 9:50
> To: [email protected]
> Subject: Re: [Jchat] Unum, new number format
> 
> 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

Reply via email to