Re: Comparison with NaN

[Jaroslav Hajek]

On Thu, May 14, 2009 at 11:22 AM, Michael Goffioul
<address@hidden> wrote:
> On Thu, May 14, 2009 at 9:33 AM, Jaroslav Hajek <address@hidden> 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.

I think that's the most reasonable solution. I see no reason at all to
include it there - Array.cc should be *only* included in those .cc
sources instantiating Array for a particular type, and those sources
should probably not do anything else beyond the instantiation (and
possibly specializing). I'll remove the offending #include.

I think Octave should not depend on GCC's template instantiation model.

>
>>> ***** 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.

Yes, sorry. I said it wrong, but you understood correctly.

>> what does
>> [v,i] = sort([NaN, 2, 3, Inf, 1, 2])
>> return?
>
> I'll try this evening.
>
> Michael.
>

OK.

cheers

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz