[Cfp-interest] TS 18661-4/N1785 - Reduction functions, correct rounding

[Dan Zuras Intervals]

> Subject: Re: [Cfp-interest] TS 18661-4/N1785 - Reduction functions, correct rounding
> From: Jim Thomas <jaswthomas at sbcglobal.net>
> Date: Fri, 7 Feb 2014 10:45:33 -0800
> Cc: CFP <cfp-interest at ucbtest.org>
> To: Vincent Lefevre <vincent at vinc17.net>,
>  Dan Zuras <intervals08 at NONABELIAN.COM>
> 
> Thanks for the information. Expanding IEEE 754-2008 is generally out of =
> scope for the TS, but we=92ll take another look at this.
> 
> Dan, please see comments and questions  below.

	Jim,

	I'm not sure what comments you want me to speak on and I'm not
	sure I can answer your questions.  Still...

> 
> - Jim
> 
> On Feb 6, 2014, at 4:59 PM, Vincent Lefevre <vincent at vinc17.net> wrote:
> 
> > Jim,
> >
> > On 2014-02-05 11:35:06 -0800, Jim Thomas wrote:
> >> On Jan 8, 2014, at 7:34 AM, Vincent Lefevre <vincent at vinc17.net> =
> wrote:
> >>> * TS 18661-4 should reserve names for correctly rounded versions of
> >>> the reduction operations. Note that the current P1788 draft standard
> >>> for interval arithmetic requires correctly rounded reduction
> >>> operations sum, dot, sumSquare and sumAbs.
> >>
> >> IEEE 754-2008 specifies the reduction operations to allow high
> >> performance implementation for general use, and does not address
> >> correctly rounded reductions. I think doing so in TS 18661 would be
> >> out of scope.
> >
> > That's not what Dan Zuras (in Cc) says:
> >
> >  http://grouper.ieee.org/groups/1788/email/msg06382.html
> >
> > |Alas, Vincent may point out that we did NOT specify them as being
> > |exactly computed.  Indeed, we were not able to at the time, due
> > |to there being so many 754s out there that did not support it.
> > |So these functions are defined but without specified result
> > |precision.  (Although we DID specify exceptions in a standard way.)
> > |
> > |However, correctly rounded versions WERE our intention. 
> 
> 
> > Indeed,
> > |it is silly to define them just as they would come out of any
> > |C-compiler.
> 
> That would have been silly, but not what=92s in 754. C compilers are =
> limited to C semantics for evaluation order and types, which 754 =
> reduction functions are not.

	So we are agreed, doing that would be silly.  Only specifying
	correctly rounded operations has any meaning to us.

> 
> > |
> > |Then, shortly after the standard was published a number of papers
> > |appeared that show you how to correctly round your result in all
> > |cases using 754 arithmetic, just a bit of extra precision, &
> > |some sorting.  It is quite clever & not at all difficult to do.
> > |And, indeed, had we known they were possible (& fast) at the time
> > |we WOULD have required them as many (perhaps most) existing 754
> > |implementations have done now.
> 
> What 754 implementations are you referring to? Are you saying they =
> provide correctly rounded reductions now?

	They do but unfortunately, I don't remember which implementations
	they were.  They were likely academic implementations as the papers
	involved were academic in nature.  But as I don't remember what
	754 implementations they were I can't tell you.  I vaguely remember
	that Stanford may have been involved but I don't really remember.
	Perhaps if you put out a call to the 754 people someone else will
	remember who published these papers.

> 
> >
> > So, if the intention was correctly rounded results instead of
> > high performance, then TS 18661 should address that.
> >
> > --
> > Vincent Lef=E8vre <vincent at vinc17.net> - Web: =
> <https://www.vinc17.net/>
> > 100% accessible validated (X)HTML - Blog: =
> <https://www.vinc17.net/blog/>
> > Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
> 

	I am sorry but I am out of this business these days & out of
	touch with those involved as well.  Jim, you can rely on me
	to tell you what I remember but not much beyond that any more.

	I am truly sorry.

	Yours,

				Dan