Re: Comparisons and decorations
> Date: Sun, 26 Sep 2010 12:30:13 +0200
> From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>,
> 1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Comparisons and decorations
>
> Dan Zuras Intervals wrote:
> >> Subject: Re: Comparisons and decorations
> >> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> >> Date: Sat, 25 Sep 2010 16:48:40 +0100
> >> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> >>
> >> Nate
> >>
> >> On 24 Sep 2010, at 11:48, Arnold Neumaier wrote:
> >>> Nate Hayes wrote:
> >>>> special cases for
> >>>> A \interior B
> >>>> such as when A and B are both Entire or A=[1,Infnity]
> >>>> and B=[0,Infinity]. In these cases, the interior operator
> >>>> would need to return a different result than when A and B
> >>>> are compact intervals, such as A=[1,100] and B=[0,200].
> >>> ??? There is a uniform formula in 754:
> >>>
> >>> [al,au] interior [bl,bu] iff ~(bl-al>=0) and ~(au-bu>=0).
> >> Looking at 754-2008 §5.3.1, I think
> >> (nextDown(al) >= bl) and (nextUp(au) <= bu)
> >> also works, since nextDown(-oo) = -oo and nextUp(+oo) = +oo.
> >>
> >> John Pryce
> >
> > If the intention is that interior is subset with a
> > smidge at both ends except when that end is infinite,
> > then both formulas have performance problems.
> >
> > The first risks NaNs on the subtracts (which compares
> > false so the formula has the correct outcome). But
> > because of our decorations, implementations may end
> > up running with the invalid trap enabled which slows
> > things down by factors of 100x to 1000x when it
> > happens.
>
> Please explain.
>
> What does this have to do with decorations?
> They don't affect the formulas!
>
> What can enable an invalid trap?
>
Not these formulas.
I was thinking about decorations like Defined or
Domain or things like that.
The evaluation of a function (in floating-point)
outside its domain might lead to all sorts of
nasty things happening. One way to avoid that
might be to set the invalid trap so such things
are caught before they have a chance to pollute
things with NaNs. The downside is that it takes
a long time on most machines.
Now that you make me explain it, that's probably
not the best way to go. Chances are an
implementation would go ahead & let the NaN
happen, note it, set the appropriate decoration,
& then not store it back in the result interval.
In that case the original formula works just fine.
Well, I DID say such things were fleeting. :-)
Dan