From: Joachim Schimpf <js10_at_crosscoreop.com>

Date: Tue, 21 Nov 2006 12:28:11 +0000

Date: Tue, 21 Nov 2006 12:28:11 +0000

Sorry, this is going a bit off-topic. Skip if you don't care about

intervals and the meaning of floats...

Richard A. O'Keefe wrote:

*> ...
*

*>
*

*> First, max/2 and min/2 are part of the algebra of LATTICES. They are
*

*> not about arithmetic, they are about ORDERING. And when we look at
*

*> intervals, we see that they form a PARTIAL order, not a total order.
*

*>
*

*> So when we
*

*>
*

*> 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)
*

*>
*

*> we see very clearly that the answer should be *NO*: NEITHER of the
*

*> arguments is greater than the other, so the maximum is simply undefined.
*

But I am not talking about an "interval data type", I am talking

about a numeric data type. Whether I choose intervals or black magic

to have my "accurate yet imprecise" representation of numbers, is

secondary. By not calling our "bounded reals" intervals, I had

hoped to make this clearer.

My aim is to compute

*a representation for* the maximum of two numbers, given

*a representation for* each of the two input numbers.

If I choose an interval representation, I can do this by computing

the supremum *on the representation*. The fact that there is

no maximum operation defined on intervals is irrelevant.

I may be mistaken, but you seem to argue that, because I cannot

compute the maximum via max(X,Y,M) :- (X>Y -> M=X ; M=Y)

because of the undecidability of the comparison, my max function

should also raise an exception. I would rather say the opposite:

all the more reason to have a working max/2 function, when

I cannot easily implement it via other means.

*>...
*

*>
*

*> (By the way, I have been arguing for the last 20 years or more that
*

*> we ought to allow underscores inside numbers to make them readable,
*

*> as Ada and some other languages do. It's rather upsetting to see
*

*> underscores used for separating the bounds of an interval.)
*

I know, but I needed a syntax that didn't conflict with other

valid Prolog syntax. An infix uppercase letter would also have

worked, though.

*>...
*

*> 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,
*

*>
*

*> I don't, for fairly obvious and practical reasons.
*

I did invite that response, didn't I?

I wonder how honest it is though: Another thread is happily

discussing float representations for pi and e. We claim to

be computing the cosine of something. We deliver a float result

to 1/10 rather than raising an exception. The whole notion of

accuracy makes no sense without assuming that there is something

elusive you are trying to approximate.

What is the alternative? Floats as a finite subset of the

rationals are quite unsatisfactory as a computation domain.

Would you at least accept "the presence of floats makes me wary

of rounding errors"?

-- 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
*