# Re: <OR> predicate?

From: Tegiri Nenashi <tegirinenashi_at_gmail.com>
Date: Mon, 27 Sep 2010 11:33:19 -0700 (PDT)

> 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 userdefined  operations with angle brackets much more elegant (and instantly appealing to Tutorial D enthusiasts)? Received on Mon Sep 27 2010 - 20:33:19 CEST

Original text of this message