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$1@sp15at20.hursley.ibm.com>

"Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message news:3v77a.8$Us3.88_at_news.oracle.com...
> "Paul" <pbrazier_at_cosmos-uk.co.uk> wrote in message
> news:51d64140.0302260614.2449aa2a_at_posting.google.com...
> > "Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
> news:<b3de03$nfa$2_at_sp15at20.hursley.ibm.com>...
> > > > 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:

TYPE TINY_INT POSREP( {-1,0,1 } ); TYPE TINY_PI
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
POSREP POINT_XY (X TINY_INT, Y TINY_INT) POSREP POINT_RT (R TINY_R2, T TINY_PI

                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.

:-)

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