R. Baker Kearfott schrieb:
I'm getting a little confused here about the line between
syntax and semantics. Yes, say, if we want to use some kind
of epsilon inflation,
Nobody so far suggested seriously to convert by epsilon-inflation.
My proposal was to convert finite floats to a point interval,
and other floats to Empty.
Siegfried argued for treating inf as an uncertain number and
to convert it to [realmax,inf], reasoning that an inf would have
come from an intended finite number by overflow.
I find it strange that finite floats with an inaccurate past
are treated exactly but just inf is treated as inexact.
Siegfried finds it strange that computations which are finite in
exact arithmetic should become empty in mixed float/interval
arithmetic.
This is the conflict.
I suggested as a possible compromise to convert _all_ floats
to a finite point interval; this would remove both sources of
stangeness (at therisk of introducing another one).
The most natural values are then
inf -> realmax
-inf -> -realmax
NaN -> 0
Siegfried didn't respond to that so far.
If he is not satisfied with this, I'll stick with what
is in my proposal (v2.0).
we will start with a floating point
variable that is the result of a long computation (such as
a that done in an approximate solver for a system of
linear or nonlinear equations). However, isn't that
normally a single number in the constructor.
Yes, it is a single floating-point number, possibly +-inf or NaN.
Ultimately,
the actual constructor acts upon a single entity to
produce an interval, doesn't it?
Yes.
Furthermore, aren't we
looking at standardizing these underlying operations, as
opposed to the syntactic environment in which they occur?
Yes.
If the argument to the operation is the result of a long
computation, that argument (in Siegfried's case maxreal+maxreal)
could in principle be maxreal, inf, NaN, or anything else,
and I question whether it is practical or even possible
in general to figure out from the computation or the
syntax of the program what was originally intended.
I fully agree.
My original suggestion was therefore to treat each float at
face value; hence +-inf and NaN convert to Empty.
This is easiest to expain to the unsophisticated user.
(The sophisticated user has no problems anyway, no matter
which version is adopted by the standard.)
However, at the risk of seeming somewhat biased, it does not
make sense to me to convert any finite number, even maxreal,
into the empty set.
Nobody had suggested that. The question is only whether a
floating-point +-inf or NaN should be converted into Empty,
or into a substitute finite point interval, or into a substitute
interval of positive width.
This is a semantic issue that must be settled unambiguously
by the standard.
Arnold Neumaier
Arnold Neumaier wrote:
Siegfried M. Rump schrieb:
Although examples like
intval(maxreal+maxreal)
are a little constructed; usually we would assume the argument of
a constructor to be a constant.
No. Frequently one needs an enclosure of a function value at a point.
Then the argument of a constructor will be a float variable, computed
in an arbitrary way.
In any case, definitions in the standard must work for all allowed uses.