Re: Time problem again?

From: Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>
To: Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Time problem again?
Date: 2003-09-30 09:13:04
Message-ID: 20030930111304.D11005@hermes.hilbert.loc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> Why can't you just take my word for it, this is the way it should be
> sorted....
He *does* take your word that this is the way it should be
sorted. But without knowing WHY this is the way it should be
sorted it is hard to deduce an algorithm for doing so.

What you probably need to do is sort them lowest -> highest
and then slide a window across the range (and wrapping the
lower times that leave the window) until the difference
between the then-first and then-last time is minimized. Even
then you can't know for sure unless you have additional
knowledge.

data 2 22 4 23

-> 2 4 22 23 -> delta-t 21 hours -> wrong order
-> 4 22 23 2 -> delta-t 22 hours -> wrong order
-> 22 23 2 4 -> delta-t 6 hours -> candidate
-> 23 2 4 22 -> delta-t 23 hours -> wrong order

here you can find your sort order by (delta-t < 12).

But what if there's another 1300 data point in there ?

2 4 13 22 23 21
4 13 22 23 2 22
13 22 23 2 4 15
22 23 2 4 13 15
23 2 4 13 22 23

I assume you are telling us that won't happen, right, i.e. it
is one of the rules ?

And what do you make of this sequence:

data 22 10

-> 10 22 12 -> candidate
-> 22 10 12 -> candidate

You't want to make sure delta-t is LESS than 12 hours.

I am sure there's an efficient algorithm out there to do this.

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Richard Huxton 2003-09-30 09:24:53 Re: Time problem again?
Previous Message Bjørn T Johansen 2003-09-30 08:50:21 Re: Time problem again?