Re: Extending my question. Was: The relational model and relational algebra - why did SQL become the industry standard?
Date: Mon, 24 Feb 2003 12:59:07 -0500
"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
> "Bob Badour" <bbadour_at_golden.net> wrote in message
> > In their treatment of temporal databases, Date, Darwen and Lorentzos
> > quite heavily on interval type generators. An interval type generator
> > generate an interval for any type with a total ordering. ie. a type with
> > unique first, a unique last, a successor for every value except the last
> > a predecessor for every value except the first.
> > One could define a view for every totally ordered type using their
> > operator and the interval type generator. Interestingly, such a view
> > also be considered a literal because it specifies a selector for a
> > 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
> > 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
> > 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
> > whose arguments are all literals is a literal so they have to deal with
> > concept at some point.
> Thanks. I happen to have mislaid by copy of TTM otherwise that it where I
> would have looked.
> Literal == Named Constant
Nope. Literal == symbolic representation of a value. It need not be named.
Values, of course, are always constant.
The character-string literal, "Bob", is a literal, but it is not a named literal. The numeric literals, 0.0 and 0.314159E1, are also literals, but neither is a named literal.
In TTM, a selector whose arguments are all literals is a literal:
P#(100) == part number literal
POINT(DISTANCE(1.0),ANGLE(90)) == polar coordinate literal POINT(DISTANCE(x),ANGLE(90)) is not a literal but an expression calculating a point from a variable, x.
> > > Any datatype should define *precisely* the set of values that it
> > A precise definition need not enumerate all possible values. A stream
> > datatype would have a large number of possible values as would a
> > length character string type.
> I did not say that enumeration was the only way to precisely define a set
> 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
> have some specifed maximum possiable length.
I am not convinced that a stream type needs to have a maximum possible length. Certainly, streams have a unique first value. I would question whether streams have a last value and whether one can define successor and predecessor functions well.
> > > 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
> > 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
> > types
> > > based on DECIMAL(n,m) in their new book on temporal data. They show a
> > > type lattice for DECIMALs where n < 4 and m < 4.
> > >
> > > All very interesting, although I did note that it rather messes up
> > 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
> > > 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
> > > CARTESIAN and POLAR poss representations would need to be limited to
> > exactly
> > > those point values that are expressable using RATIONALs in both of the
> > > 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
> > 1-epsilon to 1+epsilon.
> Let me put it this way. If a type has 2 possiable representations, then
> A) the number of values represented by PosRep1 must equal the number
> values represented by PosRep2
> B) each value represented by PosRep1 must 'map' to exactly one value
> represented bt PosRep2, and versa.
While desirable whenever possible and while certainly possible in an ideal machine, I do not require this of physical implementations. For instance, if I have two functions, F and FINV, that are ideally inverses, I do not expect physical implementations to always evaluate the following comparison as TRUE: (x = F(FINV(x))). If F(x) == x^y and FINV(x) == x^(1/y), I fully expect the expression to return FALSE for many values of y.
> > 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
> a way of having exactly one polar point 'near' every Cartesian point (and
> versa), then ok.
Ties go to the winner. <g> As long as there is no systemic bias in the selection method, I don't care which of several equally close points are chosen. As long as no other points are closer.
> 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);
> q <> r
> 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?
Should I assume then that you generally won't use floats? Or should I assume you generally won't use equality comparisons with floats?
Personally, I sometimes use equality comparisons with impunity and other times I won't use them at all. It depends on the operations I am using and the risk of subtle rounding errors.
In my experience, it doesn't take much training to get users to change q=r to DISTANCE_BETWEEN(q,r) < 0.0001 for those situations where it will matter. Received on Mon Feb 24 2003 - 18:59:07 CET