Re: position paper on comparisons
P1788
With teaching to do I am not yet up to date with the large discussion on comparisons and trits and tetrits. But I put forward the following points.
A.
Despite my previous posting about this, and trying hard to answer it for myself, I have no answer to the question:
What practical use has the Kulisch comparison xx <= yy,
meaning (xx.inf <= yy.inf and xx.sup <= yy.sup) ?
The fact that it makes the intervals into a lattice is all very well, but what use could I make of, for instance, that in this lattice order,
[1,3] meet [0,6] = [0,3], and [1,3] join [0,6] = [1,6] ?
B.
I am concerned that no one has pointed out a serious confusion -- not even George when posting his list of "certainly" and "possibly" relations.
To remove ambiguity: when I write, say, "quantify over groiks" I refer to clauses like "for all x in S", "there exists x in S" where S is a set of groiks.
Most of the relations in George's list are of the form
(a relation xx r yy between sets of numbers) constructed from (a relation x r y between numbers)
in exactly the same way as, say,
(addition xx + yy of sets of numbers) is constructed from (addition x + y of numbers)
They involve quantifying over numbers, e.g.
xx (certainly <=) yy" means (for all x in xx)(for all y in yy) x <= y.
But a few in George's list are of quite different nature, such as
xx (possibly contained in) yy. (*)
"contained in" is not a relation between numbers, but one between sets.
I do not know what (*) means. The only sense I can make of it is that we are quantifying over sets of numbers (intervals), instead of over numbers. That is, xx represents a _set_ of intervals and yy similarly, and we are saying
"At least one of the intervals represented by xx
is contained in at least one of the intervals represented by yy."
It's P1788's business to quantify over numbers. I think it is NOT our business to quantify over sets of numbers. If some high level language likes to do such things, I wish it luck. As for P1788 -- we sure need to be aware, which of the two we are doing.
C.
Item B shows why I do not like the "bounded" trit. Here is an example.
Let aa be a decorated interval that holds ([0,oo],notBounded).
Let bb and cc be decorated intervals that each hold ([0,oo],isBounded).
Now aa has a unique meaning as _the_ interval that contains all reals x with 0<=x<oo.
But bb means "some interval [0,B] where B is finite". (And how big is B anyway?? Could it be 0.1?)
And cc similarly is some interval [0,C] where C is finite.
Therefore
(aa containedIn bb) is unambiguously false;
(bb containedIn aa) is unambiguously true.
But (bb containedIn cc) has to be "possibly true", because we are quantifying over sets: over the family of intervals of the form [0,B] and [0,C], for which B<=C is sometimes true, sometimes false.
Programs must do one thing or the other at a branch. So whatever mechanism of trits, tetrits etc., we use at a low level, the user program must translate it into 2-valued logic true or false.
In existing interval systems, "containedIn" returns a boolean: unambiguously false or true. But if P1788 includes the "bounded" trit with the meaning that (I think) is proposed for it, this is no longer the case. "containedIn" would have to return a multi-valued logic result. Programs that used to make sense would no longer make sense under P1788.
We could, of course, say that "containedIn" returns false in the indeterminate case, analogously to all floating-point comparisons, in which NaN appears, returning false. But that is almost as bad.
To me, all this seems so crazy that we must reject it.
Am I missing something?
John