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

Date: Wed, 26 Feb 2003 18:53:12 -0000

Message-ID: <b3j2nl$ops$1_at_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 - 19:53:12 CET