[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: benchmarks - sort
From: |
David Bateman |
Subject: |
Re: benchmarks - sort |
Date: |
Thu, 22 Jan 2004 17:53:55 +0100 |
User-agent: |
Mutt/1.4.1i |
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 address@hidden
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
- Re: benchmarks - sort, (continued)
RE: benchmarks - sort, THOMAS Paul Richard, 2004/01/22
Re: benchmarks - sort, Paul Thomas, 2004/01/22