From octave-maintainers-request at bevo dot che dot wisc dot edu Thu Jan 22 10:58:10 2004 Subject: Re: benchmarks - sort From: David Bateman To: THOMAS Paul Richard Cc: "'David Bateman'" , Paul Kienzle , octave-maintainers@bevo.che.wisc.edu Date: Thu, 22 Jan 2004 17:53:55 +0100 Thomas, I suspect I see where you get your speed-up. Check the line > return *p1<*p2; //*double less than that should read return (xisnan(*p2) || *p1<*p2); overwise NaN's aren't sorted correctly, or at ll. I'm sure Octave's sorting code can be made about twice as fast if it didn't have to check for NaN's... As a test try octave:1> a = rand(1,10); a(2) = NaN; b = mysort2(a) where is the NaN in b? It should be in b(10), but with your comparison test it'll end up in b(2). This is something that caused me a lot of pain, and has a lot of ugly additional code to treat correctly in merge.cc for the case of IEEE 754 integer compares.. Cheers David -- David Bateman David dot Bateman at motorola dot com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary