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
"Bob Badour" <bbadour_at_golden.net> wrote in message
> 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
> > 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.
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.
> > 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
> > 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
> > example of a type with mutiple possiable representations. I.e.
> > A geometric POINT type with both CARTESIAN and POLAR possible
> > that use RATIONAL numbers only (for the representations) would be rather
> > limited because many rational CARTESIAN representations map to
> > 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
> > 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.
- 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.
I.e. just as long as we never get
q <> r
p = q AND p = r
then I'd be happy, but from my experience of floats I can see the above
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);
q <> r
p = q AND p = r
then I'd be happy, but from my experience of floats I can see the aboveoccurring and so surly really messing things up?
Business Intelligence, IBM Global Services Received on Mon Feb 24 2003 - 14:59:27 CET