Re: The current proposal
I am resending an email I have sent only to Professor Rump by error...
==================================================
Dear Professor Rump and colleagues,
I like the idea of listing the properties that should be enforced by
the standard and then find an implementation of the standard that
satisfies them. Although Professor Rump's four properties sound
important, I am not sure I understand them in details.
The constructor interval(x) can have three kinds of arguments:
(FR) x is a real number that is also a floating point number. In this
case interval(x)=[x,x]
(RnF) x is a real number that is not a floating point number. In this
case interval(x)=[x^-,x^+], the first being the largest floating point
number less than x, and the second the smallest bigger than x.
(FnR) x is a floating point number that is not a real number (0^-,
0^+, infinities or NaN). In this case, I am not sure of what is
interval(x).
> (1) For a given function F, for example, X=F(interval(A.sup)) should give
> an inclusion of the value of F at the right bound of A.
A.sup is a floating point number, so we have two cases: (FR) and (FnR)
For Case (FR), property (1) is trivial since it holds by definition of
interval arithmetic. I am not sure of what (1) means in Case (FnR),
like A=[0,+oo] or A=[0,0^+].
> (2) [a,b] = hull(interval(a),interval(b))
This property is trivial in Case (FR). I think it is meaningful and
important in Case (RnF), but again I can't see its meaning in Case
(FnR).
> (3) 0*A=0 under any circumstances.
If for example A=[1,+oo] then Property (3) means that whatever is the
real number x inside A, 0 times x is 0. We can also understand that
the range of f(x) := 0*x over the interval [1,+oo] is [0,0].
What about special cases like 0/[0,0] or 0/[0,0+] ? Defining f(x)=0/x,
(3) seems to be a consequence of
f(A) = range( f , A intersect dom(f) )
> (4) xx=interval(x) implies xx.inf==xx.sup.
In the case (RnF), interval(x) return the smallest standard interval
that contains x, and thus is not degenerated. So Property (4) seems to
be violated in this case, isn't it?
Kind regards,
Alexandre Goldsztejn
On Mon, Feb 23, 2009 at 4:56 AM, Siegfried M. Rump <rump@xxxxxxxxxxxxx> wrote:
> On Sun, 22 Feb 2009 18:22:00 -0100, Michel Hack <hack@xxxxxxxxxxxxxx> wrote:
>
>> Siegfried Rump wrote, concerning whether intervals
>> should or should not contain Infinity as a number:
>>>
>>> Imagine the question "What is the result of -0==0" is at stake.
>
>
> NO, whether intervals should contain Infinity as a member is NOT the point!
>
> The point is that always, without case distinction, the following
> should be true:
>
> (1) For a given function F, for example, X=F(interval(A.sup)) should give
> an
> inclusion of the value of F at the right bound of A.
>
> and
>
> (2) [a,b] = hull(interval(a),interval(b)).
>
> Both is very natural in interval computations.
>
> My point is to START with PROPERTIES we wish to maintain, not
> with solutions.
>
> Such properties are (1) and (2), and also
>
> (3) 0*A=0 under any circumstances.
>
> This is a very nice property and an argument against Infinity
> being a member of intervals. Another property is
>
> (4) xx=interval(x) implies xx.inf==xx.sup.
>
> This is also nice property and an argument against
> interval(Infinity)=[realmax,Infinity].
>
> IMHO, the properties (1), (2) are mandatory, (3) is important,
> (4) is nice to have. Note that I am mainly speaking as a potential
> USER of the interval arithmetic standard, not as an implementer.
>
> If there is no acceptable way to maintain all properties (1..4)
> we may think about workarounds and look for the best compromise.
> Of course, the speed is important as well.
>
> I would like to hear opinions from people working with interval
> arithmetic what properties for them are mandatory, important or
> nice to have.
>
> Best wishes
>
> Siegfried M. Rump
>
>
>
>
>
>>> Imagine the question "What is the result of -0==0" is at stake.
>>
>> Good example. There are indeed two ways to look at this, and each
>> is convenient for some things and inconvenient for others. So 754
>> picked the one that seems most convenient for most cases -- but ALSO
>> provides the totalOrder() predicate to accomodate the other cases.
>>
>> Incidentally, if they/we had made the other choice (-0 != +0), there
>> would have been a branchless way to compute (x==y) in the (-0==+0)
>> sense -- i.e. without undue performance penalty: ((x+(+0))==(y+(+0)).
>>
>> So, with respect to IA, when the decision to chose whether or not
>> standard intervals can contain infinities comes up for a vote, we
>> should try to make sure that there are viable constructs to deal
>> with cases that would have preferred the other approach.
>>
>> Michel.
>> Sent: 2009-02-22 19:39:22 UTC
>
>
>
> --
> =====================================================
> Prof. Dr. Siegfried M. Rump
> Institute for Reliable Computing
> Hamburg University of Technology
> Schwarzenbergstr. 95
> 21071 Hamburg
> Germany
> phone +49 40 42878 3027
> fax +49 40 42878 2489
> http://www.ti3.tu-harburg.de
>
> and
>
> Visiting Professor at Waseda University
> Faculty of Science and Engineering
> Shinjuku Lambdax Bldg. 902
> 2-4-12 Okubo, Shinjuku-ku
> Tokyo 169-0072
> Japan
> phone/fax in Japan +81 3 5286 3414
>
--
Dr. Alexandre Goldsztejn
CNRS - University of Nantes
Office : +33 2 51 12 58 37 Mobile : +33 6 78 04 94 87
Web: www.goldsztejn.com
Email: alexandre.goldsztejn@xxxxxxxxxxxxxx