Re: Demo: Modelling Cost of Travel Paths Between Towns

"Laconic2" <laconic2_at_comcast.net> skrev i en meddelelse news:xJCdnVoISasXiwjcRVn-gA_at_comcast.com...
>
> "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?
>
I think I understand what you mean, and from a practical view I can follow you.
(but I don't care if, or not, there is a 1-1 between value and representation - I know no case where that's the case! Do you have an example?)

The "matter" was: what is a "type engine". You defined it (loosely) as a feature that returns a representation of a value (of the type). That surprises me- I would expect that it created a value of the type, or (better) created a new type (as in CREATE DOMAIN). Is it not the latter you in fact refer to in your statement: "this is why engines that allow user defined datatypes..."? I.e.: "type engine" = "engine that allows user defined datatypes", rather than "type engine" = "engine that returns representation of values"

But now we are _really_ far OT in this thread. I'm inclined to leave it here. Received on Fri Nov 12 2004 - 21:41:04 CET