# 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

Message-ID: <zst6a.297$9O1.43758648_at_mantis.golden.net>

"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