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

"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

1. the number of values represented by PosRep1 must equal the number of values represented by PosRep2
2. 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);

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