Re: [Gretl-devel] msortby() stumbles over NA / nan
On Wed, 3 Dec 2014, Sven Schreiber wrote:
Am 03.12.2014 um 16:59 schrieb Allin Cottrell:
>
> It's more complicated than that, and msortby is actually not doing
> anything odd. What's odd, I gather, is the behavior of the Microsoft C
> library in the cases you said came out "OK".
How can I test the C library behavior? Maybe a simple C code snippet --
but compiling on a non-dev Windows machine is tricky I guess?
I can send a little test.exe. I'll do that tomorrow; I'd be quite
interested to find out what's actually happening on Windows.
> Therefore a NaN will never move in the sort, and it will create
a
> barrier such that sorting occurs only before and after. So the msortby
> behavior is expected.
Ok, I see. I searched a bit for other software's behavior, FWIW:
- Matlab: "If A includes any NaN elements, sort places these at the high
end." (http://matlab.izmiran.ru/help/techdoc/ref/sort.html)
[...]
Thanks, this is useful info.
I think there are various options: refuse to sort with NaNs and let
the
user deal with the NaNs. Or do as the other software does, put it at the
end or at the start. Or mimick the situation with series and leave them
in their original position. Or treat it as always bigger (if that is
what Matlab does). Any or all of this could be done as an optional user
choice. But the current situation is bad IMHO.
Granted. Our current behavior is no more defensible than sorting
NaNs high, and less convenient for the user. There's "safety in
numbers", proverbially, so maybe we'll just go with my modification
in yesterday's CVS and sort NaNs high like Matlab. This should be
documented, of course.
Allin