Re: Cell arrays of strings in "sort" and "unique"

[Alois Schloegl]

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