From: Joachim Schimpf <js10_at_crosscoreop.com>

Date: Mon, 20 Nov 2006 17:01:00 +0000

Date: Mon, 20 Nov 2006 17:01:00 +0000

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

*
This archive was generated by hypermail 2.2.0
: Wed Sep 08 2010 - 23:28:17 EST
*