Re: Demo: Modelling Cost of Travel Paths Between Towns
From: Nick Landsberg <SPAMhukolauTRAP_at_SPAMworldnetTRAP.att.net>
Date: Fri, 12 Nov 2004 18:48:36 GMT
Message-ID: <8A7ld.12053$7i4.5459_at_bgtnsc05-news.ops.worldnet.att.net>
>
>
>
> Ouch!!!! Of all the typos I've ever made, this is the worst. I don't know
> how I missed it. My proofreading skills are going down the drain!
>
> Let me try the whole thing over again, corrected:
>
>
>
>
>
>
> Believe it or not, this is a problem in "normalization". Not "data
> normalization" as we ordinarily speak of it in database discussions, but
> normalization 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
> 2004.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 2004.11.12 00:00. And I would call this final step
> "normalizing the result".
>
> Once the results of a computation have been "normalized" , a naive
> comparator
> can test for equality by just comparing the representations. Right?
>
>
>
>
>
Actually, IMO, this makes a strong argument for storing times internally as a certain number of "clock-ticks" since an "epoch".
Date: Fri, 12 Nov 2004 18:48:36 GMT
Message-ID: <8A7ld.12053$7i4.5459_at_bgtnsc05-news.ops.worldnet.att.net>
Laconic2 wrote:
> "Rok Debeljak" <rok.debeljak_at_milenij.si.remove> wrote in message
> news: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 would >>want 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
>
>
>
> Ouch!!!! Of all the typos I've ever made, this is the worst. I don't know
> how I missed it. My proofreading skills are going down the drain!
>
> Let me try the whole thing over again, corrected:
>
>
>
>>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
> normalization 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
> 2004.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 2004.11.12 00:00. And I would call this final step
> "normalizing the result".
>
> Once the results of a computation have been "normalized" , a naive
> comparator
> can test for equality by just comparing the representations. Right?
>
>
>
>
>
Actually, IMO, this makes a strong argument for storing times internally as a certain number of "clock-ticks" since an "epoch".
-- "It is impossible to make anything foolproof because fools are so ingenious" - A. BlochReceived on Fri Nov 12 2004 - 19:48:36 CET