[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comparison with NaN
From: |
Michael Goffioul |
Subject: |
Re: Comparison with NaN |
Date: |
Thu, 14 May 2009 10:22:45 +0100 |
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.
>> ***** 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.
- Re: Comparison with NaN, (continued)
- Re: Comparison with NaN, Michael Goffioul, 2009/05/11
- Re: Comparison with NaN, Jaroslav Hajek, 2009/05/11
- Re: Comparison with NaN, Michael Goffioul, 2009/05/11
- Re: Comparison with NaN, Jaroslav Hajek, 2009/05/11
- Re: Comparison with NaN, Michael Goffioul, 2009/05/11
- Re: Comparison with NaN, Jaroslav Hajek, 2009/05/11
- Re: Comparison with NaN, Michael Goffioul, 2009/05/11
- Re: Comparison with NaN, Michael Goffioul, 2009/05/11
- Re: Comparison with NaN, Michael Goffioul, 2009/05/11
- Re: Comparison with NaN, Jaroslav Hajek, 2009/05/14
- Re: Comparison with NaN,
Michael Goffioul <=
- Re: Comparison with NaN, Jaroslav Hajek, 2009/05/14
- Re: Comparison with NaN, Michael Goffioul, 2009/05/14
- Re: Comparison with NaN, Jaroslav Hajek, 2009/05/15
- Re: Comparison with NaN, Michael Goffioul, 2009/05/15
- Re: Comparison with NaN, Jaroslav Hajek, 2009/05/17
- Re: Comparison with NaN, Michael Goffioul, 2009/05/17
- Re: Comparison with NaN, Jaroslav Hajek, 2009/05/17
- Re: Comparison with NaN, Michael Goffioul, 2009/05/17
- Re: Comparison with NaN, Jaroslav Hajek, 2009/05/17
- Re: Comparison with NaN, Michael Goffioul, 2009/05/17