Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Motion 4



	This was meant to go to stds-1788.  Bad fingers. :-)  - Dan

To: Vincent Lefevre <vincent@xxxxxxxxxx>
Cc: "stds-1788-er" <stds-1788-er@xxxxxxxxxxxxxxxxxxxxx>,
    Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
From: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
Subject: Re: Motion 4 
Date: Thu, 09 Apr 2009 09:37:25 -0700

> Date: Thu, 9 Apr 2009 17:52:31 +0200
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> To: stds-1788@xxxxxxxxxxxxxxxxx
> Subject: Re: Motion 4
> 
> On 2009-04-09 05:34:29 -0700, Dan Zuras Intervals wrote:
> > 	We have said nothing about NaN support yet.  And, indeed,
> > 	there are good reasons for excluding NaNs from valid
> > 	intervals.  I don't think we will attach any significance
> > 	to signed zeros for practical reasons (we cannot control
> > 	them) but I may be wrong.  So the compiler options you
> > 	speak of my be useful.
> 
> Motion 4 should be clear about what it requires.
> 
> > 	But if your real concern is for user defined precisions,
> > 	I will point out that they exist now in 754-2008.
> 
> Yes, but for instance, I don't think that supporting one of
> the basic formats should be required for P1788. And what about
> subnormal support[*]? (FYI, MPFR does not support subnormals
> directly, and it seems that users don't need them, except for
> emulating the IEEE 754 standard.)

	Very well.  I'm sure 1788 will not & indeed should not
	require everything that 754 requires.  A carefully worded
	normative statement to that effect would meet with little
	opposition.  (Carefully worded to admit systems that DO
	support subnormals & to maintain containment on systems
	that flush to zero.)

> 
> [*] The property x != y ==> o(x - y) != 0 may be useful in FP
> arithmetic, but I doubt that one needs something similar in IA,
> in particular because the returned interval will often contain 0
> in case of a cancellation.

	This property is useful in scale free linear algebra.  It is
	important in single because of the limited range.  Less so
	in double.  And probably never needed in MPFR.  It depends
	on your context.

	But you are more expert in this than I am.


> 
> Also, we may want to specify IA on elementary functions. In such
> a case, would Motion 4 imply that they need to be supported at
> the IEEE 754 level? IA may be less demanding, e.g. for trig
> functions (sin, cos, tan) on very large values.
> 
> -- 
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

	Of course not.  Not even 754 requires that correctly
	rounded transcendentals be supported.  It merely offers
	the implementer the OPTION to implement functions that
	will be considered conforming if they round correctly.
	Any other functions are outside the scope of 754 but not
	disallowed.

	You are correct that 1788 may be less demanding.  But
	1788 must also be more careful if containment is to be
	maintained.  Therefore, while a polynomial approximation
	may be less than correctly rounded & given a epsilon's
	push in one direction or another, the range reduction
	can afford no such sloppyness.  And since most of the
	difficulty is ultimately traced to the range reduction
	for large arguments I don't know how much you can save
	& still maintain containment.

	Again, between the two of us, your experience is more
	to be trusted.

	Yours,

				Dan