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

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message news: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

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
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 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
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
> A) the number of values represented by PosRep1 must equal the number
of
> 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
define
> a way of having exactly one polar point 'near' every Cartesian point (and
vis
> 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);
>
> 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?

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