Drexel dragonThe Math ForumDonate to the Math Forum



Search All of the Math Forum:

Views expressed in these public forums are not endorsed by Drexel University or The Math Forum.


Math Forum » Discussions » sci.math.* » sci.math.independent

Topic: Does ANYONE here believe there is fraud and incompetence in
logic/computer science publishing?

Replies: 4   Last Post: Jun 13, 2013 11:40 PM

Advanced Search

Back to Topic List Back to Topic List Jump to Tree View Jump to Tree View   Messages: [ Previous | Next ]
Charlie-Boo

Posts: 1,585
Registered: 2/27/06
Re: Does ANYONE here believe there is fraud and incompetence in
logic/computer science publishing?

Posted: Jun 13, 2013 11:40 PM
  Click to see the message monospaced in plain text Plain Text   Click to reply to this topic Reply

On Jun 10, 12:19 am, Graham Cooper <grahamcoop...@gmail.com> wrote:
> On Jun 9, 11:55 pm, Charlie-Boo <shymath...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>

> > For years I have studied computer science and logic which overlaps
> > it.  One by one I have discovered weaknesses, omissions, mistakes and
> > outright fraud.  Here are just a few examples:

>
> > 1. E.F. Codd's Relational Model - SQL: Codd was trying to develop a
> > mathematical model of database systems.  He pointed out that records
> > in database systems are relations in math.  That is true and a good -
> > the correct - start.  But he was never able to model files or general
> > file manipulations.  He said a flat file is a relation.  In a sense it
> > is - its functionality relates to just one relation.  But files in
> > general consist of (a) multiple capabilities (programs), each of which
> > is defined by a wff that (b) can reference multiple relations.  Codd
> > never figured that out or what to do with hierarchies, so he declared
> > them illegitimate.  So SQL has no hierarchies.  It has simple indexes,
> > otherwise it would be unbearable.  But Codd says that doesn't count as
> > data so he lets them in.  Actually, indexes are no different from
> > files in general and should not be treated any differently.  One file
> > is an inversion of another.  The result is database systems are based
> > on SQL, have no hierarchies beyond little indexes (not general ones),
> > and are terribly inefficient.  The notion that "hierarchies are not
> > relational and so cannot be used" is ridiculous.

>
> Well half right.
>
> I think of SQL as a low-level 4GL and Prolog as a high level 4GL as
> the tuples are recursively nested into hierarchies (and predicates
> themselves are interpreted)
>
> Here is a PROLOG formula
>
> AXIOM:
> p1( p11, p12, ...)
>
> INFERENCE RULE:
> p2( p21, p22, ...) ^ p3( p31, p32, ...) ^ ... ^ pn( pn1, pn2, ...)
> ->
> p1( p11, p12, .. )
>
> ------------------
>
> where each term can recursively embed another predicate by adding
> arguments.
>
> AXIOM:
> p1( p11, p12( p121, p122,  ...) ... )
>
> which you CANNOT DO WITH SQL which is based on the field Relational
> Algebra.
>
> -----------------
>
> It's not that Heirarchies are not "allowed" it is merely that they are
> superfluous and redundant.
>
> The process of Normalisation of the relations will not work with
> embedded sub-tuples.
>
> e.g.
>
> TABLE BOOKS
>
> IBN#  |    TITLE   |   AUTHOR  |   AUTHORS WEBSITE
>   23          MAGIC       TOM                www.tomssite.com
>   32          MATHS      JANE              www.wolfram.com
>   83          SPELLS     TOM                www.tomssite.com
>
> You might use an XML style to embed details about the AUTHOR in the
> BOOKS table.
>
> IBN#  |    TITLE   |   ( AUTHOR , AUTHORS WEBSITE)
>   23          MAGIC       ( TOM      www.tomssite.com )
>   32          MATHS      ( JANE    www.wolfram.com )
>   83          SPELLS    ( TOM      www.tomssite.com )
>
> -------------------
>
> But if the Author changes his website name, then instead of
> updating 1 record, you have to update 2 records.
>
>  ( TOM      www.tomssite.com )
>  ( TOM      www.tomssite.com )
>
> Now your database is no longer normal, it has a redundancy.
>
> If you EDIT one record and don't edit the other record as well,
> then when you query:
>
> SELECT  AUTHORSWEBSITE  FROM  BOOKS
> WHERE AUTHOR = tom
>
> RESULT
>
> www.tomsnewsite.comwww.tomssite.com
>
> -------------------------
>
> There should be an index from
>
> IBN to BOOK
> and
> AUTHOR to AUTHORSWEBSITE
>
> The reason for the indexes is two-fold, to speed up the queries
> and enforce referential integrity.
>
> In fact, phpPROLOG is the first database to do exactly what you said,
> use a flat table to represent hierarchies in tuples.
>
> I use a REF=1  REF=2  REF=3  REF=31  REF=32...
>
> system for super-fast Prolog processing!
>
> Herc
> --
>
> http://phpPROLOG.com
> A.I. Software / Database on the Web!
>
> Powered By SQL
>   SELECT HEADS.id
>     FROM QUERY
>     INNER JOIN HEADS
>     ON QUERY.ref=HEADS.ref
>     AND QUERY.term=HEADS.term
>
>          DATABASE                    QUERY
>     id      ref     term           ref     term
>    ----------------------        ----------------
>     6       1       test1
>     6       2       aaa
>     7       1       test1   <=>    1       test1
>     7       2       bbb     <=>    2       bbb
>    ----------------------        ----------------


That is all fine and dandy, a noble cause and laudable effort. But
let us look at the complete picture of Codd's goal of formalizing
database (management) systems. We need:

1. A model for databases.
2. A formalization of querying a database.
3. A model of manipulations of a database to process a query.
4. An algorithm to generate possible manipulations that process a
given query.

(Do you agree this list is complete and not superfluous?)

How would you do each of these in Prolog?

(1) Codd omits hierarchies. (2) Predicate Calculus does fine - his
"tuple variables" et. al. are unnecessary. (3) His Relational Algebra
(this you also use) is special cases and incomplete. (4) He wrote a
paper once seemingly addressing this. After working through its
massive details for a couple of days, I discovered that he was merely
saying to take the cartesian cross product of all relations involved
and them walk through all of the tuples and apply logic to evaluate
each to see if it passes, a totally unworkable algorithm. A few years
later he dismissed that algorithm as not a solution.

After axiomatizing program synthesis I realized that (4), the database
query processing problem, is a corollary, a special case.of program
synthesis. Also note that nobody writes about both much less shows
that they are the same problem. Manna/Waldinger and Codd/Date are
strangers. Database relations are defined in the same terms as
mathematical relations, but they neglect to apply the mathematical
solution to their problems in the database context. However, this is
understandable to a degree because they never did solve the program
synthesis problem itself, as I noted elsewhere above. [I collaborated
with Manna/Waldinger on a number of occasions, but in the end
Waldinger simply said he was unable to utilize my solution because it
was "a difficult paper". He then said he liked his better because
more people wrote about it.]

C-B











Point your RSS reader here for a feed of the latest messages in this topic.

[Privacy Policy] [Terms of Use]

© Drexel University 1994-2014. All Rights Reserved.
The Math Forum is a research and educational enterprise of the Drexel University School of Education.