Re: Time problem again?
От | Karsten Hilbert |
---|---|
Тема | Re: Time problem again? |
Дата | |
Msg-id | 20030930111304.D11005@hermes.hilbert.loc обсуждение исходный текст |
Ответ на | Re: Time problem again? (Bjørn T Johansen <btj@havleik.no>) |
Список | 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
В списке pgsql-general по дате отправления: