Re: Why are [Database] Mathematicians Crippled ?

From: Norbert_Paul <norbertpauls_spambin_at_yahoo.com>
Date: Mon, 02 Feb 2015 18:46:17 +0100
Message-ID: <maod46$2it$2_at_dont-email.me>


Tegiri Nenashi wrote:
> On Sunday, February 1, 2015 at 9:21:54 AM UTC-8, Norbert_Paul wrote:
>>> It is not a secret that [SQL] database applications in science are
>>> mediocre, at best.
>>
>> Actually, to me this is new. Can you give examples?
>
> I'm just relaying the message from somebody else, who famously said that
> databases are good at many things, but not especially good at any of them.

Who?

> It is tough call to prove that something is not the best, but let's try to
> find a reason. The most ubiquitous objects in physics are functions, and the
> most primitive functions are polynomials.

I would say the function

   f: {} -> {}

is even more primitive.

> .... How do you represent polynomials in
> database?

   CREATE TABLE Polynomials(
     id INTEGER NOT NULL PRIMARY KEY
   );

   CREATE TABLE Monomials(

     id INTEGER NOT NULL
     degree INTEGER NOT NULL,
     coefficient <YourFieldOfChoice> NOT NULL,
     PRIMARY KEY(id, degree),
     FOREIGN KEY(id) REFERENCES Polynomials(id)
   );

Let <YourFieldOfChoice> be DOUBLE (even when it is actually not a field)

   poyl42(X) := X^7 - 12 X^5 + 14.123 X^2 + 42 X + 7

Store this into the databse;

   INSERT INTO Polynomials(id) VALUES(42);

   INSERT INTO Monomials(id, degree, coefficient) VALUES(42, 7, 1.0);
   INSERT INTO Monomials(id, degree, coefficient) VALUES(42, 5, -12.0);
   INSERT INTO Monomials(id, degree, coefficient) VALUES(42, 2, 14.123);
   INSERT INTO Monomials(id, degree, coefficient) VALUES(42, 1, 42.0);
   INSERT INTO Monomials(id, degree, coefficient) VALUES(42, 1, 7.0);

> The simplest of all polynomials are linear polynomials, ...

No. The constant polynomials are even simpler, and the simplest polynomial is the zero polynomial:

   INSERT INTO Polynomials(id) VALUES(0); -- done no Monomials to store

(None of the queries above has been tested.)

> ... One can even be impressed by matrix
> multiplication query which is just relation's self-join followed by
> aggregation with group by. However, the success is short-lived, and query of
> matrix inverse is not expressible with standard relational operations.

I'd bet it is. You might first want to compute the determinant. Then use that query to compute the matrix inverse. I suppose this requires recursive join (transitive closure) iff the matrix size is not limited.

For an alternative approach you might want to read

   http://beza1e1.tuxen.de/articles/accidentally_turing_complete.html

and, in particular,

    http://wiki.postgresql.org/wiki/Cyclic_Tag_System .

>>> Still, I would suggest looking up there (rather than in "more practical"
>>> fields. For example, chemical databases do some nontrivial matching of
>>> substances. Likewise, in protein chemistry topology might be very
>>> important.
>>
>> I personally would stress "might" because I don't know how topology is
>> related to protein folding. This could be an interesting question, though.
>
> I'm just making a guess that application of topology would be something more
> significant that just architecture (or a similar level engineering
> discipline). ...

I started with architecture. I also think that there are more fields of application than architecture.

> ... Many CS researchers venture to do bold things, here is the
> example:
>
> http://arxiv.org/abs/1208.6416

This looks interesting. I like tha categorial viewpoint of the paper. So it might be worth reading it.

Norbert Received on Mon Feb 02 2015 - 18:46:17 CET

Original text of this message