Re: A different definition of MINUS, Part 3

On 20 déc, 15:36, paul c <toledobythe...@xxxxxxxx> wrote:
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.  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.
There are a lot of problems related to deriving a language definition
directly from traditional algebra, one of them being determining a
semantics that maps to RL traditional formalism in an exhaustive
fashion, while remaining effective to be expressed semantically by a
programmer. Since defining a language does not answer the same
problem than establishing a theorem, it is difficult for me to imagine
they could both be similar solutions.

More reasonnably, I would assume that a computing model is to be
derived first (such model would be defined according to fundamental
and core RL principles). Then a subsequent language definition could
naturally be derived from the computing model.

There are many advantages to that approach, first being that
independence between the two layers allows verification of potential
contradictions between the fundamental concept and potentially
candidate computing model for implementation. Since they both are
based on common basic axiomatic, they should not contradict. And if
they do , that contradiction may just prove interesting to study.

As an analogy, I would say that the relation between relational
algebra and a relational computing model is comparable to the
relationship between mathematics and physics. Both respect same
fundamentals but do not respond to the same obligations. Physics has
its own set of constraints: observation, extrapolation. But physics
is not mere extension of math. It uses mathematical tools
selectively and is not exclusively driven by it. Physics has forced
on many instances the reformulation of equations that proved
inconsistent with observation.

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.
A relvar is a construct that may be practical in determining a theorem
but be unpractical in representing effective and pertinent semantics.
For instance, I do believe that a semantic JOIN represented *as-is* is
simply a poor unimaginative way to implement the relational JOIN. I
believe that subtyping on the other hand takes away the need for the
semantic JOIN while allowing an implicit JOIN operation. I do also
believe that such dissociation is becoming urgent as a lot has been
written about RM but too little about a computing model that could
allow to implement core relational concepts.

Regards...
[Snipped]

.

Relevant Pages

  • Re: A different definition of MINUS, Part 3
    ... There you go again attributing references to language implementation to me ... the algebra is not an essential ... While the name of the relvar no doubt has other significance in ...
    (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: Mathematical definition of automata?
    ... A Category is a typed algebra modelled on the monoid: ... The Algebraic Representation of Automata ... Context-Free Expressions and the Bra-Ket Algebra ...
    (comp.theory)