Re: Extending my question. Was: The relational model and relational algebra - why did SQL become the industry standard?

From: Paul Vernon <paul.vernon_at_ukk.ibmm.comm>
Date: Wed, 26 Feb 2003 18:53:12 -0000
Message-ID: <b3j2nl$ops$>

"Mikito Harakiri" <> wrote in message news:3v77a.8$
> "Paul" <> wrote in message
> > "Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
> news:<b3de03$nfa$>...
> > > > As long as the polar representation has a
> > > > representable value in that area, I see no problems. Even if the polar
> > > > representation has no value in that area, but a point near that area
> I'm
> > > > still okay with it.
> > >
> > > But what happens if many polar points are 'near' that area?. If you can
> define
> > > a way of having exactly one polar point 'near' every Cartesian point
> (and vis
> > > versa), then ok.
> >
> > When we have domains of "rationals" or "reals" in a database, really
> > we're just talking about domains of integers with the scale shifted.
> > So for theoretical purposes we can ignore any basic number domain
> > except integers.


> It seems that your starting point is not properly established. What do you
> mean by "rationals" or "reals" in a database?

> NUMBER domain in the SQL database implentation is confusing. There is no
> reason to beleve that a decent theory can be build around such an ugly
> construction. I suggest droping it from any theoretical discussion
> altogether.

> For ideal world we have to look into computer algebra systems: Maple,
> Mathematica, etc. They have integers that are not limited by some silly
> 32/64 bit bound. They have true rational numbers. They do represent
> algebraic numbers like sqrt(2) and other reals like 'pi', 'e' *exactly*.
> The size of the number affects only the speed of calculation, nothing else.

> At any point, user can resort to approximate evaluation -- floating point
> number representation of complex expression. This can be postponed to the
> end of the calculation, or can be done early. Similar to the duplicates
> elimination story, early approximation results in larger error.

> There is no reason why databases can't follow the suit and introduce better
> real numbers domain.

Humm. I think I can counter my argument:

POSREP( {-1.5 PI, -1 PI, -.5 PI, 0 PI, 0.5 PI, 1 PI, 1.5 PI, 2 PI } ); TYPE TINY_R2 POSREP( { 0 SQRT2, 1 SQRT2 } ); TYPE TINY_POINT

                CONSTRAINT IF R = 0 SQRT2 THEN T = 0 PI );

Now both poss reps are equivalent, so this is a well constructed type and as such not a bad example of a type with more than one possible representation.


Paul Vernon
Business Intelligence, IBM Global Services Received on Wed Feb 26 2003 - 19:53:12 CET

Original text of this message