RE: position paper on comparisons
In principle, there is an interpretation of new relations not using sets, coming from modal logic, where "necessary A" means that A is true for all possible values of the quantity, and "possibly A" means that A is true for some possible value of the quantity.
John is right that when we talk about possible _pairs_ (a,b), then the only possible relations are
* necessarily (aa <= bb) meaning that every possible value a from aa is <= every possible value b from bb, i.e., that
a+ <= b-, and
* possibly (aa <= bb), meaning that a- <= b+
However, we can also quantify over a single variable. For example, for each a, we can have the relation
P(a,bb) <=> possibly_b (a <= bb), meaning that a <= b for some value b from the interval bb
This relation is equivalent to a <= b+
This relation is true for some a and false for some other a. Now, a natural question is whether this statement is necessarly true for a in aa, i.e., whether it is true for all a from the interval aa. This new relation
Necessary_a P(aa,bb) <=> necessary_a possibly_b (aa <= bb) is equivalent to a+ <= b+
This type of combination is used in some approaches to solving linear equations: there is a control solution, tolerance solution, joint solution, etc., that differ by selecting quantifiers and their orders -- this was explored in modal interval arithmetic.
-----Original Message-----
From: stds-1788@xxxxxxxx [mailto:stds-1788@xxxxxxxx] On Behalf Of John Pryce
Sent: Saturday, April 17, 2010 6:00 AM
To: stds-1788
Subject: Re: position paper on comparisons
P1788
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