Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> comp.databases.theory -> 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
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 - 07:59:27 CST