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

From: Mikito Harakiri <>
Date: Wed, 26 Feb 2003 10:09:36 -0800
Message-ID: <3v77a.8$>

"Paul" <> wrote in message
> "Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
> > > 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
> > > still okay with it.
> >
> > But what happens if many polar points are 'near' that area?. If you can
> > 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. Received on Wed Feb 26 2003 - 19:09:36 CET

Original text of this message