Re: [prolog-standard] Re: log10/1, log/2, min/2, and max/2

Richard A. O'Keefe wrote:
> ...
>
> HOWEVER, floating-point contagion is NOT sufficient to satisfy this
> preference. According to IEEE rules, -0.0 =:= +0.0, so if we ask
> for max(-0.0, +0.0), which do we get? The answers *can* be told
> apart, and since the arguments are both floating-point numbers,
> floating-point contagion does nothing to answer the question.

A good point, which I had missed.

>
> ... [numerous further observations and suggestions]

Thanks for compiling those. I was going to comment on several
of them, but that got a bit lengthy, so let me focus on one point.

> *IS* max/2 just another "arithmetic function" in the sense required?
> To my mind, it clearly isn't. The result is one of the arguments,
> not a *combination* of information from the separate arguments,
> UNLESS you decide to MAKE it so.

Let me explain why it is not so clear.

In ECLiPSe, we have 4 arithmetic types: integer, rational, float
and bounded-real. The latter is used for safe interval arithmetic:
a bounded real is a pair of floats (written as <float>__<float>)
that represents a particular real which which is guaranteed to
lie somewhere between the bounds. (Bounded reals are not to be
confused with interval domain variables - they are constants!)

While the presence of rationals does not seem to have any bearing
on our problem (integer->rational contagion does not lead to loss
of precision or other representation problems), bounded reals do.

Consider the comparison of two reals, whose values are not very
precisely known, but which are both in the vicinity of 1:

?- X is max(0.9__1.0, 0.8__1.1).
X = 0.9__1.1
Yes (0.00s cpu)

Because of the fuzziness, we don't really know which argument is
the larger one, but we know in what range the result must fall.
The most precise result we can deliver is _not_ identical to
any of the arguments, it is a combination of information from
the arguments. With selection semantics, we would have to
raise an exception.

Similarly, with mixed types, we have the choice of making an
exception, or computing a result that is neither of the inputs:

?- X is max(1, 0.8__1.1).
X = 1.0__1.1
Yes (0.00s cpu)

Now, you may say that is ECLiPSe's problem, but I think it tells
us something about how to handle floats. If we subscribe to the
view that a float is an inaccurate representation of a real that
lies somewhere in the vicinity of the float, then the float 0.99
could really be an inaccurate representation of 1.01, resulting
from rounding error or whatever.

If we return 1 as the result of max(1, 0.99), then the integer
result gives a false sense of accuracy: we are pretending to
know, without any doubt, that the maximum is precisely 1.
But that would only be the case if the accuracy of 0.99 were
better than 0.01, and we can't be sure of that. If we return
1.0 instead, the it is clear that this is an inaccurate result,
implying that the true result might well be greater than 1.

My point is: the fact that a float was _involved_ in computing
the result, makes the result inaccurate, therefore the result
must be a float to reflect this. Incidentally, this seems to
be what the Scheme report is saying as well.

By the way, that's why it's called contagion: the inaccuracy of
the input "infects" the operation, so the result is inaccurate.
That's why I think the arguments about loss of accuracy don't
hold: the accuracy of the result depends on the accuracy of the
(float) input, both of which are not known, so cannot be lost.

-- Joachim

_______________________________________________
prolog-standard mailing list
prolog-standard_at_neve.di.ubi.pt
http://neve.di.ubi.pt/mailman/listinfo/prolog-standard
Received on Mon Jul 14 2008 - 13:01:03 EST