# Re: <OR> predicate?

Date: Mon, 27 Sep 2010 11:33:19 -0700 (PDT)

Message-ID: <f8554f2f-7d7f-42f6-8c76-9c99eb797385_at_a36g2000yqc.googlegroups.com>

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 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