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

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