Re: overflow question
On Tue, May 8, 2012 at 3:01 PM, Nate Hayes <nh@xxxxxxxxxxxxxxxxx> wrote:
> Alexandre Goldsztejn wrote:
>>
>> On Mon, May 7, 2012 at 4:24 PM, Nate Hayes <nh@xxxxxxxxxxxxxxxxx> wrote:
>>>
>>> Alexandre Goldsztejn wrote:
>>>>
>>>>
>>>> As the discussion has eventually started, could you use my email as a
>>>> first
>>>> thread in this discussion and explain the interpretation in terms of
>>>> overflow of the computation
>>>>
>>>> f(x)= 1+x^2 (1+sin(x))
>>>> f((-oo,+oo))=[1,+oo]
>>>>
>>>> to the standard's list?
>>>
>>>
>>>
>>> Yes.
>>>
>>> The input to this function would be [-omega,+omega]. Since
>>> X = upsilon([-omega,+omega]) = [-oo,+oo]
>>> for FTIA we then have at Level 1a:
>>> f(X) = [1,+oo]
>>> which we may safely re-interpret as
>>> omega(f(X)) = [1,+omega].
>>> Nate
>>
>>
>> I am not sure of how this interpretation in term of overflow can be
>> used. In particular, is the non-existence of solution to f(x)=0 a
>> consequence of the overflow-interpretation of this computation?
>
> Zero is not an element of any interval in the overflow family [1,+omega];
> similarly, it is not an element of the unbounded interval
> upsilon([1,+omega]) = [1,+Inf]
> which represents the union of all intervals in the overflow family. Under
> either interpretation, it is proof of non-existence of the solution
> (c. f. Proposition 1).
> Nate
As far as I understand, if I want to compute the image of a function
over an unbounded interval X, then first I should build a family of
overflown intervals Upsilon(X), then compute the image of each
interval of this family of intervals by F(Upsilon(X)), and then
compute the union of the resulting intervals Omega(F(Upsilon(Z))).
Here, F applies to an infinite set of intervals and returns an
infinite set of intervals, so formally:
F: P(IR^n) --> P(IR)
F(XX)={hull(range(F,X)):X in XX}
where P(E) is the set of all (bounded nonempty) subsets of E. Am I correct?
To be more homogeneous, I think Omega should return a set containing
only one interval in case there is no overflow, so that the process
above applies to both bounded and unbounded intervals, otherwise two
cases have to be handled.
This sounds coherent (although has to be checked, e.g. what if there
are some unbounded intervals in the image of the overflow family
F(Upsilon(Z))), but infinitely more complex than the natural unbounded
intervals: f(X)=hull(range(f,X)) applies to all intervals and is so
natural and as powerful! I think any non-expert user of the standard
shall be lost reading these definitions in Level 1a! On the other hand
Now, let me comment the advantages of the overflow arithmetic you point out:
- Overflow arithmetic allows defining the midpoint in all cases at
level 1a and homogeneously at level 2. This is true. On the other
hand, the overflow arithmetic fixes the value of the midpoint of
unbounded intervals, while we may want to have a different value at
Level2 (I think there is currently no generally accepted definition of
what should be the midpoint of an unbounded interval at Level 2) !
Personally, I would feel ok to leave undefined the midpoint of an
unbounded interval at level 1 (indeed, there is no mathematical
definition of the midpoint of an unbounded interval), and define it at
Level 2 after discussing what is the best choice.
- Overflow arithmetic allows defining more complex comparison
operations. But do we need even more complexity?! You feel that the
claim "[2,+oo] is a subset of the interior of [1,+oo]" is
"astonishing", but this is a mathematical definition that makes a lot
of sense ! Who needs any other interpretation? You claim "While
technically correct, the comparison operations on unbounded intervals
give results that users may not expect.", I think users expect the
correct mathematical definition to me computed. You also claim "Also,
the implementation of comparison operations necessarily becomes more
complex to accommodate the special cases of unbounded intervals, as
well.", but I don't think we should return a mathematically wrong
result to save a if statement in the implementation!
- Kaucher arithmetic could be defined at Level 1. Cf. several previous
email providing arguments for not including the Kaucher arithmetic in
the standard.
Overall, I spend more time arguing on this topic because I think that
if this motion passes, and if such a Level 1a is introduced in the
standard, then it will become unpractical. I share the feeling of
Arnold that no standard would probably be better that such an
unpractical one. I think it is not realistic to standardize something
so new and complex where none of us has any experience! It is much
more reasonable to standardize thing that have been used for a long
time, where all people agree (isn't it the ways and means of a
standardization process?!).
Alexandre Goldsztejn
--
Dr. Alexandre Goldsztejn
CNRS - Laboratoire d'Informatique de Nantes Atlantique
Office : +33 2 51 12 58 37 Mobile : +33 6 78 04 94 87
Web: www.goldsztejn.com
Email: alexandre.goldsztejn@xxxxxxxxxxxxxx