On Jun 6, 2:19*pm, vadim... (AT) gmail (DOT) com wrote:
Yes, these are both things my program can handle. The theoretical
aspects are fairly far along; what is killing me is the practical
aspects.
Namely, the number of possible expressions in even mildly complex
algebras is mega gigantic, and in algebras with operators that
are both commutative and associative, simply noting that two
complex terms of the same size are syntactically equivalent
is excruciatingly slow. I have recently purchased a much
more powerful machine but I'm not sure how much this will
help; the big wins have all been the results of greater
understanding of the nature of Universal Algebra.

I still have good ideas left for how to do better, and I
believe a complete equational theory of Vadim's algebra
is mechanically achievable.


Marshall

On Jun 6, 2:19*pm, vadim... (AT) gmail (DOT) com wrote:
Neither complement (x') nor double inversion (x``) change the header
of an input relation. Therefore, they are set operations affecting
relation tuples only. Complement (x') is the set complement, and
double inversion (x``) is a closure:

(x``)`` = x``.

I vaguely remember an exercise in Kuratovski and Mostovski "Set
Theory" book that asserts that starting with an arbitrary set one can
build no more than 13 different sets by interleaving application of
closure and complement.

On 7 juin, 01:09, Marshall <marshall.spi... (AT) gmail (DOT) com> wrote:

For what it's worth...

For having been involved in the exercice of attempting to build a
logical machine to be a sound evaluator for relational operations, I
have discovered that there is an intricate relationship between the
coherence of relation equation solving and the logical computing model
used to actually represent a single relation, given current
constraints imposed by memory/cpu architectures. In other words, the
two aspects simply can hardly be dissociated: building an relation
equation expressor without considering a serious work onto how there
are to be represented logically (and physically as a consequence) will
not only put such effort in jeopardy but will make one hit a stone
dead end due to the fact that a logical expression solvers built on
the principle of direct image systems relation representation, has a
very limited scope of verification.

I have designed a logical and computing model based on the principle
of representing relations thanks to fractal contructs which allows to
exploit other effective mathematical tools than traditional ra to
effectively operate relations and have the logical machine make
logical inferences as to the most appropriate formulation of a
relational operation. I am not sure that does make sense to somebody
who's involved deeply into the logical aspect of correctness but it is
a friendly word of warning.


taking into considerations the need for a sound logical representation
of relations.
> Marshall

On 6 juin, 23:19, vadim... (AT) gmail (DOT) com wrote:

specific problem which was adressed was the opportunity of using a new
operator to simplify relation handling in the context of relational
division. set equality is only but one aspect of operations that
could potentially be expressed more effectively using such operator.
I hoped that using questions would help clarify the scope but I am
realizing I was wrong.

operator is *only* about *set containment*. As expressed the example
provided (Question 1 to Question 8). The idea behind creating a new
operator was actually that such operators allows a simpler but
logically sound formulation of some operations that are tedious to
express using traditional operators.

I would really appreciate if you could express the Questions proposed
(and only the Questions proposed), using the relations proposed (and
only the relations proposed), but using the notation you are more
confortable with. It would help me greatly to relate to the arguments
you are developping to apprehend the problem I am trying to address,
but through your angle. It will also allow me adapt my communication
to the logical tools you are using to verify correctness... Too many
times, differences in notations make it difficult for people to
exchange information into an effective way and tend to create
dispersion as to solve well defined problems (call it another sign of
immaturity of relational theory). That is why, I promote first the
focus onto a single problem and make the effort of understanding
somebody else notation.

On Jun 7, 4:46 am, cim... (AT) hotmail (DOT) com wrote:
You are right, I didn't read your message carefully. It was "subset"
in the topic that confused me. None of your 5 questions require set
join/relational division.

Well, all the questions decompose into the two parts:
1. Find a subset of sales by a certain criteria
2. Aggregate/group by it
Inlike step 2, Step 1 is very well understood from relational theory
perspective. One can mix standard relational algebra operators,
rearrange their order under certain rules, etc. As soon as you lump 1
and 2 together, the optimization becomes much less clear (unless it is
just a shorthand/macro, which RDBMS engine expands into traditional
notation).

As I mentioned before there is no relational division anywhere in the
examples 1-5. Yet you introduced the "/" symbol and call it relational
division and later wrote an expression containing

CARSALE/salesman

This doesn't make any sense to me, how can you divide a relation
CARSALE by an attribute salesman?

Snipped
lot of people. I was hoping the examples would be sufficient to
express it but I should have stuck to traditional formalism. I have
been involved in such difficult effort for building a computing model
that I forget sometime relational formalism.

Allow me clarify again my position.

In a relational operation between 1 or more relations, a relation
whose body is subdivided into smaller tuple subsets as a *consequence*
of the operation (in this case a GROUP BY) may need to have
restrictions applied at two levels: the level of the relation
operation and the level of the subset that is a consequence of the
operation. I believe that creating operators that would symbolize the
the scope of such restrictions may simplify the expression of some
relation operations and have many more applications, such as
expressing specialization by constraints. I syntaxically designated
the operator */=* with */* symbolizing the higher level operation
(GROUP BY) and *=* the restriction applied to the subset subsequent to
the operation. Throughout examples 1 to 8 I have attempted
underlining that using such operator can express more concisely and
more systematically allow the formalization of relation operation.


advantage of some capabilities allowed by the computing model
representation of relations I developped. In such model, the internal
physical representation of relations is such as there is no one to one
mapping between the number of relational operations and the number of
physical operations performed on disk. In a word, the representation
makes it possible to have the same number of physical operations for
various combinations of basic elementary logical relational
operations. As a consequence, I am currently developping a language
for which I can afford to create pratical and unductive operators for
the compiler I am building.

I have used the */* symbol in the framework of thought of the
computing model I have developped which I consider relationally
inspired but unbound to relational formalism. I should have also
clarified this is not relational division defined according to the
assumption that relational division would be an opposite to cartesian
product. In fact, I should not have used relational division at all.

In this context when I wrote CARSALE/salesman I did mean CARSALE
grouped by salesman. In the broader context of the framework of the
computing model I am working onto, CARSALE/salesman means subdivision
of tuple set OR subtype OR subset of CARSALE according to a rule
carrying on salesman. This is not relational division in the
traditional sense but I should have indicated it.

As you mentionned, question 1 to 5 are not relational divisions
operation however you may have noticed that Question 8 mentionned is
(What are the total sales of each salesman who have sold ALL cars).
Still one can see that the pattern o programming proposed still
holds. I hope this has clarified and apologize again for the
confusions my notation has induced.

Regards...

On Jun 6, 4:09*pm, Marshall <marshall.spi... (AT) gmail (DOT) com> wrote:
I added expression generator facility to QBQL. The key to
combinatorial explosion is to do a targeted search, rather than be
overwhelmed by finding everything. The facility is not mature yet to
search for relational division, but the search for x`` discovered the
following amaizing identity:

x`` = ( x v R11 ) ^ ( x v R00 ).

P.S. I realize that until I write a decent tutorial and make a
friendly user interface not many people (and most likely nobody at
all) would bother checking up QBQL. However, it is so much fun to
program and discover things than to write documentation!