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

Date: Mon, 24 Feb 2003 13:59:27 -0000

Message-ID: <b3de03$nfa$2_at_sp15at20.hursley.ibm.com>

"Bob Badour" <bbadour_at_golden.net> wrote in message
news:8sl5a.167$Nn.17704103_at_mantis.golden.net...

> In their treatment of temporal databases, Date, Darwen and Lorentzos rely

*> quite heavily on interval type generators. An interval type generator can
**> generate an interval for any type with a total ordering. ie. a type with a
**> unique first, a unique last, a successor for every value except the last and
**> a predecessor for every value except the first.
**>
**> One could define a view for every totally ordered type using their UNPACK
**> operator and the interval type generator. Interestingly, such a view might
**> also be considered a literal because it specifies a selector for a relation
**> whose arguments are all literals.
**>
**>
**> > Bob where do you get the 'named literal' concept from? Sounds like a
**> Dateism
**> > but I can't recall seeing it.
**>
**> Literals are very common in programming so it's really not a new concept for
**> me. I work with named literals all the time. 'Nothing' and "vbCRLF" in
**> visual basic, for instance. Pi is defined in some languages I have worked
**> with. True and False are often named literals for 1 and 0. However, I do
**> believe Date and Darwen deal with literals in TTM. For instance, a selector
**> whose arguments are all literals is a literal so they have to deal with the
**> concept at some point.
*

Thanks. I happen to have mislaid by copy of TTM otherwise that it where I
would have looked.

So

Literal == Named Constant

> > Any datatype should define *precisely* the set of values that it contains.

*>
**> A precise definition need not enumerate all possible values. A stream
**> datatype would have a large number of possible values as would a variable
**> length character string type.
*

I did not say that enumeration was the only way to precisely define a set of values, although I guess that I am assuming that if there does not exist a possiable enumeration, then the set of values are not well defined.

Anyhow, variable length types can still be enumerated assuming that they do have some specifed maximum possiable length.

> > I suggest that the type INTEGER has an infinite number of values, and

*> > therefore is at best an 'abstract' type.
**>
**> Of course. Real is an abstract type too. On any physical computer system, we
**> make do with a tiny, tiny subset of Rationals when we really want Reals.
**>
**>
**> Examples of practical types might be
**> > INGEGER_+/-_10^31
**> > INGEGER_+/-_2^63
**> > INGEGER_+/-_2^31
**> > INGEGER_+/-_2^15
**> >
**> > with INGEGER_+/-_2^15 being a subtype of INGEGER_+/-_2^31.
**> >
**> > This is the kind of idea Date & Darwen propose when considering interval
**> types
**> > based on DECIMAL(n,m) in their new book on temporal data. They show a nice
**> > type lattice for DECIMALs where n < 4 and m < 4.
**> >
**> > All very interesting, although I did note that it rather messes up thier
**> usual
**> > example of a type with mutiple possiable representations. I.e.
**> >
**> > A geometric POINT type with both CARTESIAN and POLAR possible
**> representations
**> > that use RATIONAL numbers only (for the representations) would be rather
**> > limited because many rational CARTESIAN representations map to
**> non-rational
**> > POLAR representations and vis-versa.
**> > x = 1, y = 1 <-> r = SQRT(2), theta = 45 degrees
**> >
**> > but SQRT(2) is not a rational number.
**> >
**> > Without say a non-abstract REAL number type, a POINT type with rational
**> > CARTESIAN and POLAR poss representations would need to be limited to
**> exactly
**> > those point values that are expressable using RATIONALs in both of the two
**> > representations. Ruling out X=1, Y=1 for one.
**>
**> I disagree that it really messes anything up. The rationals are already
**> approximations. X=1 and Y=1 really represents a point in some small area of
**> 1-epsilon to 1+epsilon.
*

Let me put it this way. If a type has 2 possiable representations, then

- the number of values represented by PosRep1 must equal the number of values represented by PosRep2
- each value represented by PosRep1 must 'map' to exactly one value represented bt PosRep2, and versa.

If we use say INTEGER_+/-_2^32 as the type for the x & y attributes of PosRepCARTESIAN and as the type for attributes r & theta of PosRepPOLAR, then my critera A) and B) are obviously not met.

> 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.

I.e. just as long as we never get

var p POINT := CARTESION(x := 1, y := 1); var q POINT := POLAR( r:= 1.41411, theta := 45); var r POINT := POLAR( r:= 1.41412, theta := 45);

and

q <> r

but

p = q AND p = r

then I'd be happy, but from my experience of floats I can see the above occurring and so surly really messing things up?

Regards

Paul Vernon

Business Intelligence, IBM Global Services
Received on Mon Feb 24 2003 - 14:59:27 CET