|
From: | Alois Schloegl |
Subject: | Re: Cell arrays of strings in "sort" and "unique" |
Date: | Thu, 16 Sep 2004 09:55:46 +0200 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) |
David Bateman wrote:
If the position of NaN is important, its recommended doing explicit checks for NaN's - and if only for the sake of readibility of the code.You've not read sort.cc lately :-) ... If floating format is IEEE754, doubles are cast as "long long unsigned int" and with a bit of magic the NaN's are sorted correctly, where the operator < alone won't do it. This little trick gains a speed factor of 2.5 is sort, but readable it is not. Cheers David
In the statement above, I was refering to readability in user space m-files, not to readability within sort.cc. I'm aware that the bit of "magic" works very well and provides an very efficient implementation of SORT. From the implementation point of view - using the bit of "magic" and considering IEEE754 - it is reasonable to put NaN's at the same end of the sequence than +INF.
With the following example, I'll try to clarify the "user-point-of-view" (point of view in the m-domain).
If somebody needs to sort a sequence x, like mode = 'ascend'; % or mode='descend';[y,i]=sort(x,'mode') % x contains nan's
and if the position of NaNs in y is important (if not, who cares), than the user should explicitly check for NaNs using isnan(y).For example y(isnan(y)) = [] or alternatively y = y(~isnan(y)), would remove all NaN's.
The code in m-files becomes better readable, because one becomes aware that NaNs are important and have been considered.
This means, from a users-point-of-view, SORT can put NaNs in the beginning or at the end - it does not really matter. If you provide just the most efficient implementation of SORT, that's fine :-)
Alois
[Prev in Thread] | Current Thread | [Next in Thread] |