Re: Demo: Modelling Cost of Travel Paths Between Towns

"Ja Lar" <ingen_at_mail.her> wrote in message news:4194ed13$0$245$edfadb0f_at_dread11.news.tele.dk...

> I was considering a type (-engine?) as "DATETIME". An attribute of this
type
> holds values that may be represented in various ways, but the VALUE
doesn't
> depend on HOW it is represented to "the outside world" (and neither should
a
> comparator on that type). Just nit-picking again <g>.
> (For reference and to educate myself: where can I find your term "type
> engine" defined as you use it?)

I don't have a formal definition. I was just picking up on the term as I saw it used in this newsgroup.

But maybe this will help: when I tried to distinguish between the "naive comparator" and the "intelligent comparator" my point was precisely that the naive comparator compares representations, while the intelligent comparator compares values. Maybe "aware comparator" would have been better than "intelligent comparator"

Thus the question 2004.11.11.24.00 =? 2004.11.12.00.00 is "no" when you compare the representations, but "yes" when you compare the values. This is why engines that allow user defined datatypes require the definer to supply the comparator.

I don't think this is very educative, and there's probably a better way to say it. But this is the best I can come up with.

Ideally, there is a 1 for 1 homomorphism between representations and values. When it isn't 1 for 1 it behooves us to normalize, if a given value has more than one representation, and it really behooves us to disambiguate if a single representation stands for more than one value. Does this settle the matter? Received on Fri Nov 12 2004 - 21:01:08 CET