Comparison with NaN

[Michael Goffioul]

On Thu, May 14, 2009 at 9:33 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
> Though avoiding implicit Array instantiations is indeed a good policy,
> I don't like the system being so fragile; such an issue seems likely
> to be repeated unless we take some countermeasures. One possibility is
> to use xisnan rather than sort_isnan, and introduce a default template
> for it in lo-mappers.h. Another option is to provide at least the
> basic sort_isnan specializations/overloads (double, float, Complex,
> FloatComplex) directly in Array.cc, to combat the effect you
> discovered. The problem could still arise with third-party Array
> instantiations, but I think the danger would be much smaller.

As a side note, I have a similar effect, though I couldn't find an
easy workaround, with Array<octave_value> instantiation. When
compiling oct-stream.cc, Array.cc gets included. However, Cell.h
also gets included (mainly because of <oct-obj.h>, which is needed
to have octave_value_list defined). Cell.h defines an Array<octave_value>-
inherited class decorated with dllexport, so MSVC instantiates it,
including all known members, that is (for instance) Array::find.
However, Array<octave_value>::find cannot be instantiated, because
for instance of the line 2485:

    cnt += src[i] != zero;

where "cnt" is of type "octave_idx_type" and "src[i] != zero" is of
type "octave_value" ("src" is of type "const octave_value*" and
"zero" is of type "const octave_value").

The only (ugly) worked around I could find is to comment out that
part of Array.cc (all the find and sort related members), as is it not
needed anyway by oct-stream.cc.


>> ***** test
>>  [v, i] = sort ([NaN, 1i, -1, Inf, 1, 1i]);
>>  assert (v, [1, 1i, 1i, -1, Inf, NaN])
>>  assert (i, [5, 2, 6, 3, 4, 1])
>> !!!!! test failed
>> assert (i,[5, 2, 6, 3, 4, 1]) expected
>>   5   2   6   3   4   1
>> but got
>>   5   6   2   3   4   1
>>
>>
>
> It is indeed a problem, because the sort is supposed to be stable.
> Unfortunately, I can't reproduce it.
> can you run the infringing "sort" statement and verify that v(2) == v(6)?

I'm not I'm following...
As the test result shows, the second "assert" fails, meaning that
the first one succeeded, so v = [1, 1i, 1i, -1, Inf, NaN]. Of course
v(2) != v(6). However, in the original unsorted array, elements 2 and 6
are the same.

> what does
> [v,i] = sort([NaN, 2, 3, Inf, 1, 2])
> return?

I'll try this evening.

Michael.