Re: <OR> predicate?

On Sep 27, 12:25 pm, paul c <toledobythe..._at_oohay.ac> wrote:
> On 27/09/2010 11:33 AM, Tegiri Nenashi wrote:
>
>
>
>
>
> > On Sep 27, 11:22 am, Vadim Tropashko<vadim..._at_gmail.com>  wrote:
> >> On Sep 27, 10:57 am, paul c<toledobythe..._at_oohay.ac>  wrote:
>
> >>> On 26/09/2010 4:11 PM, paul c wrote:
> >>> ...
>
> >>>> ps:There might be occasional usefulness in making what one might call
> >>>> 'domain assertions', eg., in D&D Algebra, "there is a position called
> >>>> 'toilet scrubber'" could be assessed from R{position}<OR>  (<NOT>
> >>>> R{position})...
>
> >>> That makes me think of a question that may not have any practical point
> >>> except for understanding the 'A-algebra' (because it involves
> >>> non-union-compatible relations).
>
> >>> Suppose the predicate of R{Position} is "position Position is occupied".
>
> >>> I would think one possible predicate of R<OR>  (<NOT>  R) would be
> >>> something like "position Position is occupied OR unoccupied".
>
> >>> Seems that an even simpler expression, R<OR>  TABLE_DEE, gives the same
> >>> extension.  Is the predicate the same?  Or is there a good reason to
> >>> think instead of the predicate as something like "position Position Exists"?
>
> >>> (I'm asking this question even though I personally have some difficulty
> >>> reconciling parts of the A-algebra formal definitions, eg., on one hand,
> >>> the heading of R<OR>  TABLE_DEE must include the heading of TABLE_DEE
> >>> which is the empty set (in other words, the empty set is a
> >>> member/element of the heading and I presume being a member is not the
> >>> same as being a subset).  On the other hand, the definition of an
> >>> A-algebra heading says that it is a set of ordered pairs.  But the empty
> >>> set is certainly not an ordered pair.  I assume I must be making some
> >>> mistake, otherwise R<OR>  TABLE_DEE is not a valid expression.  By
> >>> 'valid' I mean theoretically possible.  Maybe somebody can point out how
> >>> I'm making this mistake.)
>
> >> This assertion (and any other) can be checked in QBQL; here is how:
>
> >> 1. Translate Tutorial D terms into QBQL:
> >>       TABLE_DEE = R01
> >>       <OR>  = _at_v  (former "+", seehttp://vadimtropashko.wordpress.com/relational-programming-with-qbql/...)
> >>       <NOT>  = _at_'  (former "'")
> >> 2. Write your assertion in QBQL
> >>       x _at_v (x @') = x @v R01.
> >> 3. Run the program containing this assertion.
>
> >> QBQL will iterate through all the relations in the database trying to
> >> find counterexample. In this case it finds none.
>
> > Why introduce awkward notation with the AT symbol? Wouldn't user-
> > defined operations with angle brackets much more elegant (and
> > instantly appealing to Tutorial D enthusiasts)?
>
> Personally, I think Vadim is right to use different symbols for his
> algebra, which as I recall, has more fundamental ops.  Although I can
> sympathize with the labels of the A-algebra <AND>, <OR> and <NOT>
> operators, one thing I don't like about them is that it's easy for a
> newcomer to fall into the trap of thinking that the implicit logical
> 'AND' of the propositions we use to interpret a relation is somehow the
> same <AND> that partly determines the predicate of those propositions.
> Likewise with <OR>, eg.,

Familiarity is definitely one of the major factors driving adoption. Witness the C -> C++ -> Java programming language evolution curve. I updated everything. Now at the end of database definition file we have

TABLE_DUM = R00;
TABLE_DEE = R01;

x <AND> y = x ^ y.
x <OR> y = (x ^ (y v R11)) v (y ^ (x v R11)).
( <NOT> x )  = (R11 v x) ^ x'.

Finally, the assertion you are after is: x <OR> ( <NOT> x ) = x <OR> TABLE_DEE.

Now I wonder if there are any other pieces left before one can claim QBQL as yet another Tutorial D implementation:-) Received on Mon Sep 27 2010 - 22:26:07 CEST