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

Motion M0035.01 -- Overflow: NO



I vote NO on Nate's Motion 35 - Overflow.

Unbounded intervals occur in math problems (as input and/or output),
and there must be a way to express them in interval arithmetic. I'm
not opposed a priori to the introduction of some alternate, complex
way to handle such unbounded intervals internally, but there must
be a clear reason to do this, which would justify the complexity,
and this must solve more problems than it introduces new ones.

The problems with the new Level 1: It is no longer possible to
consider f(I), where I is not a subset of the natural domain of f,
e.g. 1 / [0,1]. Said otherwise, Level 1 is not closed, i.e. there
are operations on intervals that are undefined, like 1 / [0,1],
while they are defined in standard math.

Let's recall that the main critic against interval arithmetic with
unbounded intervals is that some interval-to-number functions, like
midpoint, are not defined at Level 1 on unbounded intervals (only).
But with this new Level 1 model, even interval-to-interval functions
become undefined on some interval inputs!

Level 1a appears to be supposed to solve such problems. But it is
very confusing. The concept of overflow threshold has nothing to do
with unbounded intervals, i.e. from a mathematical point of view,
the notion of Fmax is meaningless and an unbounded interval is not
related to a particular "number format". It seems however that the
overflow threshold can be ignored.

Now, what does this new model bring?

Section 3.1 is useless: with unbounded intervals, rules on the
endpoints can be determined from simple math reasoning, simpler
to what is introduced in this motion. I doubt that new elements
+omega and -omega would ever be added to IEEE 754; alternate rules
for the multiplication would be more likely, but this motion won't
change anything in this respect.

About the midpoint of unbounded intervals, this motion doesn't solve
anything, because at Level 2, the choice is already open. NaN would
strictly follow the IEEE 754 ideas, but if need be, other values
could be chosen (e.g. those given by Table 1 of the May 14 version).
Having special cases is in general not a good idea, but still better
than a complex model that would try to hide these specificities.
Actually these are not really special cases since the midpoint
operator considered here is more like a multi-valued function with
a "best choice", which is the mathematical midpoint, when it is
defined; this could be documented for Level 1.

The choice for the midpoint of an unbounded interval is open, and
even if NaN is chosen in the standard, the user can still replace
it by an adequate value, possibly more adequate than some arbitrary
choice made by the standard.

About the bisection methods, according to past discussions, P1788
will not specify ones because there are too many ways to bisect.
What's important is that the current model with unbounded intervals
doesn't prevent one from implementing bisection. Note: at Level 2,
[x,+Inf] can still be split into [x,Fmax] and [Fmax,+Inf]. That's
true that it is not possible to bisect [Fmax,+Inf], but the same
problem occurs for bounded intervals like [x,nextafter(x)].

About the other algorithms, ditto.

About interior, I don't see any problem with the usual topological
definition, that applies to unbounded intervals too. The motion
would make it more complex, because the interior doesn't have a
conventional definition on families of intervals.

About Kaucher arithmetic, the fact that the new model would make it
always defined at Level 1 only is useless, because in practice, the
standard gives Level 2 specifications. I suspect that if you try to
extend Kaucher arithmetic to families of intervals, you would have
the same kind of problems as with unbounded intervals.

-- 
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)