Re: [Fwd: Re: Neumaier-Pryce proposed decoration system (v03.2)]
> Date: Thu, 16 Jun 2011 11:20:45 +0200
> From: Dominique Lohez <dominique.lohez@xxxxxxx>
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: [Fwd: Re: Neumaier-Pryce proposed decoration system (v03.2)]
>
> --
> Dr Dominique LOHEZ
> ISEN
> 41, Bd Vauban
> F59046 LILLE
> France
>
> Phone : +33 (0)3 20 30 40 71
> Email: Dominique.Lohez@xxxxxxx
>
> Date: Wed, 15 Jun 2011 18:58:57 +0200
> Subject: Re: Neumaier-Pryce proposed decoration system (v03.2)
> From: "Arnold Neumaier" <arnold.neumaier@xxxxxxxxxxxx>
> To: "Dominique Lohez" <dominique.lohez@xxxxxxx>
> Cc: "John Pryce" <j.d.pryce@xxxxxxxxxxxx>, "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>,
> "stds-1788" <stds-1788@xxxxxxxxxxxxxxxxx>
>
> On Wed, June 15, 2011 17:48, Dominique Lohez wrote:
> >
> > My position is that the case ein should be merged with safe by removing
> > the restriction that for saf the input is not empty;
>
> That's what we had before the discussion about empty input.
>
>
> > BTW bnd is not a level 1 concept
> > Any continuous function is bounded
> > if f (x) == 1/x
>
> f(x)=x is not bounded on [0,Inf], whereas f(x)=1/(1+x) is.
> The complicated rule stated in the draft is needed to make sure
> that [0,Inf]_bnd =sqr([0,realmax]_bnd) propagates correctly under
> another squaring.
>
> With the simplified rule one gets sqr([0,Inf]_bnd)=[0,Inf]_saf only.
> Thus some information is lost. Thus if we want the simplified rule
> then we should not track boundedness at all.
>
>
> Arnold Neumaier
>
Dominique, Arnold, et al,
On the issue of tracking (or indicating) boundedness, it is
true that in any given floating-point system with a bounded
exponent & a notion of infinity, there will be finite numbers
like huge such that huge^2 overflows to infinity. And, the
balance of numbers in a 754-like system is such that there
are veryTiny numbers with the property that 1/veryTiny also
overflows to infinity. Thus, unless someone removes the
computations entirely by some algebraic means, we will
inevitably have functions like f() & g() such that:
f(xx) = 1/(1/xx) & f([veryTiny,1]) = [0,1]
g(xx) = sqrt(xx^2) & g([1,huge]) = [1,+oo].
I think the solution both conceptually & computationally
is to interpret the decoration as "known to be bounded"
versus "not known to be bounded".
In that way, both results end up being tagged with "not
known to be bounded" which, in this case, may be regarded
as a slight widening of the resulting interval in analogy
to round-off error in floating-point.
The more complex approach of distinguishing the so called
"exact" infinities from overflows ends up with us having
endless fruitless debates about the nature of infinity.
If its all the same to you, I'd rather not.
Dan