Re: A different definition of MINUS, Part 3


"paul c" <toledobythesea@xxxxxxxx> wrote in message
news:5h83l.48993$mY6.41775@xxxxxxxxxxxxxxx
Cimode wrote:
...
The whole notion that there is some algebraic solution to the "problem"
is
ludicrous.
paul c and Vadim never claimed that algebric expression of the problem
is the solution. They are only trying to rely on a formalism which
has proven to be effective.
...

Yes, nobody but Brian S has suggested that the A-algebra was put forth as
providing a solution to a language implementation problem.

There you go again attributing references to language implementation to me
when it was...wait for it...YOU that brought up the whole notion of
implementation.

How is the fact that only one of the possible values for a database can
actually be the value of the database at any given time and the fact that
database updates--including view updates--simply assert which possible value
is also the actual value a matter of language implementation? Do you really
think that you can ignore the fundamental nature of the Relational Model by
relegating my comments concerning your 'purely algebraic approach' to the
bin as implementation issues? Bottom line: the algebra is not an essential
part of the Model, nor is it even sufficent to describe the Model. It is
certainly not sufficient to describe database updates, which involve more
than one possible value for the database, since it cannot even operate
beyond the scope of a single value for the database.

My hope is to find a language definition (WITHOUT changing any existing
A-algebra operators, just to remind, there are fundamentally only three of
those, some of the ones typically used are merely derivations of those
three, you can say there are four if TCLOSE is included), that allows a
language implementation that is not only effective for some purpose, but
closed for the desired expressions of that language. In other words, one
of my guesses about the problem so far is that it is the language
definition that is preventing closure of certain language artifacts. So
far, I have no doubt that the A-algebra is closed, and determinate, where
its own defined artifacts and the results of its operators are concerned.


Well, I have no doubt that my sledge hammer is hard and heavy, but I don't
think it would be very effective for cutting paper :-)

At least one of the A-algebra operators is binary, and therefore some
information, while not necessarily lost, is not accessible through any view
whose definition invokes a binary operator. For example, without prior
knowledge of their values it is unclear from which operand or operands the
tuples in a relation derived from <OR> originate. In the same way it is
unclear why some tuples do not appear in a relation derived from <AND>--do
they not appear because they don't appear in the first operand or the second
or both? More obvious is that each tuple in the result of a projection only
indicates that at least one tuple appears in the original relation that has
the same values. You have to look at the original relation to find out how
many. What you should take away from this is that the fact that the
A-algebra is closed and determinate only guarantees that an algebraic
expression that involves a given set of operand values always yields the
same result; it does not guarantee the reverse--that is, that an algebraic
expression that yields a given result always involves a particular set of
operand values.

For example, if the language has a concept of 'relvar', I want to be able
to substitute not the concept, but merely the name of the relvar in an
algebraic equation (in order to compare language results to algebraic
results). While the name of the relvar no doubt has other significance in
a language implementation, its only significance in an algebra is to be a
shorthand for some extension. This is the algebraic advantage - such
language significance is stripped out of the language expressions, leaving
only algebraic formulas and equations, removing the otherwise problem of
having to make algebraic comparison of results and to deal with some
extraneous language 'meaning' at the same time. If the concept of relvar
in some language doesn't allow a one-for-one mapping of certain extensions
to relvars, then I want to change the language, not the algebra. Within
the algebra, asking what relvar values does a relation name signify is
like asking what colour a relation is. The algebra's results reduce to
extension values which the language definition must then map to its own
concepts, relvars with fixed headings, for one example. Same goes for any
talk of the Assignment Principle within the A-algebra - search the formal
definition at http://www.dcs.warwick.ac.uk/~hugh/TTM/APPXA.pdf}
and you will see that there is no mention of 'assignment' or 'principle.

As best as I can understand him, McGoveran wants to prohibit certain
relvar values. While I don't argue that this will solve the language
problem of 'view updating', it prevents a convenience in a dbms that I've
often use, eg., copying a table to one with a different name that I can
use for testing without a lot of tedious renaming (I suspect there are
many other such conveniences that people find 'ergonomic'). I'll grant
that there are other language or environmental devices that give me the
same ability and I'll admit that some expert language designers might say
that such devices ought, on principle, to involve orthogonal concepts, but
I'd just as soon not have to learn such concepts if re-defining the
implementation language more precisely will do instead.


.

Relevant Pages

  • Re: A different definition of MINUS, Part 3
    ... as providing a solution to a language implementation problem. ... but closed for the desired expressions of that language. ... I would assume that a computing model is to be ... algebra and a relational computing model is comparable to the ...
    (comp.databases.theory)
  • Re: algebra equations for Reference and FD constraints
    ... are both programming language concepts and are not necessarily present depending on the language, eg., some languages don't need assignment. ... Whereas I would say that if one can't express a concept with either an algebra or calculus, then the concept is not a 'model' concept in the first place. ... I suspect Codd used the word 'update' only to give his ideas some familiar link to the sloppy terminology that was in wide play more than thirty years ago and seems to persist, eg., 'file updating'. ...
    (comp.databases.theory)
  • Re: Steps towards writing a computer algebra system
    ... > computer algebra systems (CAS) such as Mathematica. ... Start by writing code to translate algebraic formulas to some useful ... language, for that matter. ...
    (sci.math.symbolic)
  • Re: A different definition of MINUS, Part 3
    ... as providing a solution to a language implementation problem. ... For example, if the language has a concept of 'relvar', I want to be able to substitute not the concept, but merely the name of the relvar in an algebraic equation. ... While the name of the relvar no doubt has other significance in a language implementation, its only significance in an algebra is to be a shorthand for some extension. ... This is the algebraic advantage - such language significance is stripped out of the language expressions, leaving only algebraic formulas and equations, removing the otherwise problem of having to make algebraic comparison of results and to deal with some extraneous language 'meaning' at the same time. ...
    (comp.databases.theory)
  • Re: A different definition of MINUS, Part 3
    ... Personally, I think calling it an operation takes a turn that might risk confusing a language implementation with the algebra the language interprets or, equally, is based on. ... Personally I am coming to believe that the only "dire consequences" one can encounter turn up when one talks about the RM in terms of a language implementation, instead of sticking either to the algebra or to the calculus. ...
    (comp.databases.theory)