Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Distinction between 1/0 and 1/Empty

Nate Hayes wrote:

Arnold Neumaier wrote:

Nate Hayes wrote:

Arnolde Neumaier wrote:

Nate Hayes wrote:
> Michel Hack wrote:
>> Arnold's scheme lumps certain conditions together that
>> Nates' distinguishes -- but I doubt ALL distinctions are made, so in
>> general operands of suspicious operations have to be inspected
>> anyway,
>> at which point full discrimination is possible.
>>
>> So if Arnold's scheme has other advantages, they should not be >>
discarded
>> because of this quibble between undefined, ill-defined and empty.
>
> Well, we don't see there are other advantages.

Those who care to look for them, see.
I am still looking... since you still have shown no advantages of lumping 
decorations for 1/0 and 1/Empty together.


The uniform appearance to the user, especially the non-expert user, makes
for ease of use, which is a very significant advantage.

My choice uniformizes the performance of evaluating f([0,0]) for f(x)=1/x
and f(x)=1+1/x, where naive users would expect the decoration
D1=neverDefined because both functions are undefined at x=0, just as
they would expect the decoration D2=possiblyDefined for f([0,1]).

A decoration D0=ill suggests a bug in the program body. Your
interpretation provides the decoration D0=ill for f([0,0]) with
f(x)=1+1/x, although no bug is present. The function _has_ to be
programmed that way (or in another way also triggering a division
by zero) if one wants to evaluate them.

Thus with your semantics, syntactically and semantically correct
programs may generate the decoration ill.

Therefore users cannot be sure that the decoration ill reflects a
programming error, but must puzzle about the details of the definition
of decorations in order to detect the cause of the apparent failure.


With my semantics, the user never needs to know anything about
decorations if they are accessed only through standard-conforming
functions of decorated intervals, and an appropriate compiler handles all
decoration dependent issues, including switching and promotion.

Thus decorations can be left to the experts and those who want to play
with them, leaving a high degree of safety for the casual user.
That's all sensible, but I don't see it constitutes an advantage: it simply trades one shortcoming for another.
I would support adding a new decoration, i.e., expanding the total number of decorations from five to six: 

   D4 = safe (defined, continuous, bounded)
   D3 = everywhere defined
   D2 = somewhere defined, somewhere undefined
   D1 = everywhere undefined on real inputs (e.g., 1/0)
   D0 = everywhere undefined on empty input (e.g., 1/Empty)
   DX = ill-formed (bug)

Newbie-friendly functions such as isUndefined() can simply return TRUE if
the decoration is D1 or D0, and DX is then reserved as you and Jurgen would
like as special case for things such as invalid constructions and/or uninitialized data, etc.
My proposal allows to split decorations; but the splitting should not be made mandatory. So the standard should not distinguish between 1/0 and 1/Empty, but implementations that care for finer information are free to split it. 

Thus both you and I can be satisfied.