Re: Demo: Modelling Cost of Travel Paths Between Towns
From: Rok Debeljak <rok.debeljak_at_milenij.si.remove>
Date: Fri, 12 Nov 2004 14:01:28 +0100
Message-ID: <Ru2ld.5529$F6.1282471_at_news.siol.net>
> convert it to 2005.11.12 00:00. And I would call this final step
>
>
> Believe it or not, this is a problem in "normalization". Not "data
> normalization" as we ordinarily speak of it in database discussions, but
> normalizations nonetheless.
>
> Let's say that we are given two times, and asked whether they are equal or
> not.
>
> Here are the two times:
>
> 2004.11.11 24:00
> 2005.11.12 00:00
>
> The above form is for illustration purposes only.
>
> Now a naive comparator would answer the question "no". But a comparator
> that really understands what we are talking about
> might take a closer look, and come up with the answer: "yes". I like the
> answer "yes", myself, better.
>
> In fact, I would like the "time type engine" whenever it's done some
> calculation on time, (like adding an "interval" to a "base time") to
> perform one final step, before delivering the result to the outside world.
> If a computation happened to result in 2004.11.11 24:00, I would want it to
> convert it to 2005.11.12 00:00. And I would call this final step
> "normalizing the result".
>
> Once the results of a computaion have been "normalized" , a naive comparator
> can test for equality by just comparing the representations. Right?
>
>
>
>
Received on Fri Nov 12 2004 - 14:01:28 CET
Date: Fri, 12 Nov 2004 14:01:28 +0100
Message-ID: <Ru2ld.5529$F6.1282471_at_news.siol.net>
> Here are the two times: > > 2004.11.11 24:00 > 2005.11.12 00:00 > ... > If a computation happened to result in 2004.11.11 24:00, I wouldwant it to
> convert it to 2005.11.12 00:00. And I would call this final step
One year up or down does not really make any difference for a comparator that really understands what we are talking about ;-)
Rokson
Laconic2 wrote:
> "Alan" <alan_at_erols.com> wrote in message
> news:2vhas0F2lnpsgU1_at_uni-berlin.de...
>
>>According to ISO, we can assign the value 0000 or 2400 to midnight. Let's >>look at another time, say 2 PM, or 1400 . Do we assign two values to 1400?
>
>
> Believe it or not, this is a problem in "normalization". Not "data
> normalization" as we ordinarily speak of it in database discussions, but
> normalizations nonetheless.
>
> Let's say that we are given two times, and asked whether they are equal or
> not.
>
> Here are the two times:
>
> 2004.11.11 24:00
> 2005.11.12 00:00
>
> The above form is for illustration purposes only.
>
> Now a naive comparator would answer the question "no". But a comparator
> that really understands what we are talking about
> might take a closer look, and come up with the answer: "yes". I like the
> answer "yes", myself, better.
>
> In fact, I would like the "time type engine" whenever it's done some
> calculation on time, (like adding an "interval" to a "base time") to
> perform one final step, before delivering the result to the outside world.
> If a computation happened to result in 2004.11.11 24:00, I would want it to
> convert it to 2005.11.12 00:00. And I would call this final step
> "normalizing the result".
>
> Once the results of a computaion have been "normalized" , a naive comparator
> can test for equality by just comparing the representations. Right?
>
>
>
>
Received on Fri Nov 12 2004 - 14:01:28 CET