comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: IDL sorting
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: IDL sorting [message #56353 is a reply to message #56347] Thu, 18 October 2007 08:50 Go to previous messageGo to previous message
wlandsman is currently offline  wlandsman
Messages: 743
Registered: June 2000
Senior Member
On Oct 18, 8:20 am, Wox <nom...@hotmail.com> wrote:

> Sorting the resulting 64-bit longs would do the trick, wouldn't it?
>
> function sort,array
> array64=ishft(long64(array),32)+lindgen(n_elements(array))
> return,sort(array64)
> end

That is clever. My tests on my V6.4 Linux box find that it is
usually faster than bsort.pro. It is somewhat slower when there are
only a few duplicate values


> Btw, I didn't want to ask this, but
> why is IDL's sort doing this?

IDL just uses the sort algorithm of the underlying OS. As far as I
am aware, the SORT function on Linux boxes *does* preserve the order
of equal values, but that on Mac and Windows machines does not. I
would be interested to hear if anyone finds any exceptions to this
rule.

> Is there any situation where mixing up
> the order of equal values has a benefit?

None that I can think of. But if you just want the fastest SORT
possible, you might not care what happens to the equal values.

Actually, I think a good suggestion to ITTVIS would be to add a /
preserve_equal keyword or something similar to SORT(). This topic
comes up repeatedly.
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: read_tiff only looks in current working directory?
Next Topic: ADF format in IDL

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Oct 09 23:07:08 PDT 2025

Total time taken to generate the page: 1.44059 seconds