Re: Re-submission of motion 5: multiple-format arithmetic.
Arnold Neumaier wrote:
> Nate Hayes schrieb:
>> John Pryce wrote:
>>> Some issues left open by this motion:
>>> - The existence and functionality of NaI. I think: the interval
>>> functions
>>> that are the subject of this motion should never give a NaI result
>>> from
>>> non-NaI arguments; they should always give NaI if any argument is
>>> NaI;
>>> only constructors (maybe other related functions) should create
>>> NaI (when given nonsense input); some interval mappings may be
>>> allowed to destroy NaI (e.g maybe hull(xx, NaI) should return xx).
>>> But that's my personal view of what NaI "is for". I know other
>>> folk have different views.
>>
>> Yes.
>>
>> I support your view of NaI, in general, but also believe users
>> should be able to obtain NaI as result of some interval operation
>> that is not well-defined.
>>
>>> - It is left open what exceptional action an implementation may make
>>> available, on evaluating ff(ss) when ff is an extension of
>>> a point function f, and ss is not a subset of the domain of f.
>>> However, my approach implies such exceptional action must be _in
>>> addition_ to returning an interval value (which might be ignored,
>>> by the user or at the language level). Again, I suspect this is
>>> controversial.
>>
>> If the only way to obtain NaI for an invalid operation, such as
>> division by interval containing zero, is by traps or flags, this is
>> what I object to. This implication is still main reason I don't
>> support this motion.
>>> R4. Overall Aims.
>>> -------------
>>>
>>> Ramon Moore's Basic Theorem of Interval Arithmetic (BTIA) is
>>> fundamental to interval computation. Roughly, it says that if E is
>>> an explicit real expression defining a real function f(x_1, ...,
>>> x_n), then evaluating E "in interval mode" over any interval inputs
>>> (xx_1, ..., xx_n) is guaranteed to give an enclosure of the range of
>>> f over those inputs.
>>
>> Moore's theorem uses real analysis, so operations like division by
>> interval containing zero are undefined (NaI in modern parlance).
>> This is different than your motion, though.
>>
>> I don't mind that the c-set extention you advocate in this motion is
>> included in 1788. However, the classical definitions should also be
>> included, in my opinion.
>
> This has nothing to do with c-sets.
>
> Moore's theroem remains valid with the proposed definition, since
> a real expression defines a real function f(x_1, ..., x_n) only
> on domains where no divisor is zero.
>
> Therefore, correctly, for xx=[0,1]
> {1/(x^2-x+1) | x in xx}
> subseteq 1/(xx^2-xx+1) = 1/([0,1]-[0,1]+1) = 1/[0,2]=[1/2,inf],
> while with your definition, division by an interval containing zero
> gives NaN), and we'd get NaN, violating Moore's law since
> {1/(x^2-x+1) | x in xx} subseteq NaI
> does not hold.
The reason it "violates Moore's law" is because x = 0 is not in the domain
of the function! That's the whole point of returning NaI...
>
> Thus to hawe Moore's law for not everywhere defined expressions
> _requires_ that NaI cannot arise as the result of an arithmetic
> operation if the arguments are intervals.
Thus, what you have done is artificially remove all such points from the
real analysis of the function, which is the c-set convention...
>>> The abstract objects and operations form interval level 2. To see
>>> its utility, ask yourself the question "How to prove the BTIA,
>>> starting from a procedural definition of the arithmetic operations
>>> as given, for instance, in the Einarsson-Kulisch position paper
>>> presently (May 2009) under discussion as Motion 5?"
>>
>> Moore defines division by zero as undefined result, i.e., NaI. But
>> there is not a definition in the motion that allows this result to
>> be obtained...
>
> and rightly so.
>
>
>>> I believe nothing in this motion and rationale hinders the
>>> implementation of various forms of non-standard intervals -- Kahan,
>>> modal, etc. -- as discussed at the end of Vienna/1.2.
>>
>> I've mentioned before this is simply not true. If traps or flags are
>> only way to obtain NaI result from an interval operation such as
>> 1/[-2,3], this is hinderance to efficient modal interval
>> implementations.
>
> This is another eason why modal intervals should not be part of
> the standard. It makes the latter unnecessarily complicated,
> only to introduce an error-prone technique that can be safely handled
> only by a tiny minority of users.
I don't agree at all. It opens 1788 to a wider audience by clarifying and
simplifing.
>
> Not deciding this issue (modal or not) very soon will constitute a
> major quarrel in each issue to be decided.
That's probably true, but using modal intervals as the lynch-pin is a false
argument, I believe.
>> As it stands, I'm not ready to vote "yes" to this motion. As I've
>> mentioned in the past, I believe a more balanced solution is to
>> provide two sets of operations:
>>
>> op1: { x op y | x in X and y in Y }
>> op2: { x op y | x in X and y in Y and x op y is defined }
>>
>> The first is Moore's classical definition and leads to NaI if x op y
>> is not well-defined (this is the definition compatible with modal
>> intervals). The second is c-set extention which returns {empty} for
>> those values, instead (this is what your motion provides).
>
> This ultimately amounts to requiring implementors to fully implement
> two interval arithmetics - one with a set of op1's suited for the tiny
> minority of modal interval users, with a fully functional modlaa
> interval arithmetic, and a second one with a set of op2's for the huge
> minority of ordinary interval users who want best achievable
> enclosures rather than noninformative NaI results.
>
> This would be a very regrettable state of affairs since it puts mostly
> unnecessary duties on the shoulders of _all_ implementors.
It would be a regrettable state of affairs if 1788 is purposefully designed
to cater only to c-set vendors at the exclusion of a wider view of
intervals. We do hope 1788 will be accepted world-wide, afterall. Such a
narrow view of things will certainly prevent this from being the case.
Nate