| Re: the NaN effect :-| [message #54475 is a reply to message #54397] |
Wed, 13 June 2007 09:43  |
Jim Pendleton, ITT Vi
Messages: 13 Registered: August 2006
|
Junior Member |
|
|
<eddedmondson@hotmail.com> wrote in message
news:5d7uh7F33rq9aU1@mid.individual.net...
> metachronist <rkombiyil@gmail.com> wrote:
>> ; Now I increase number of NaN's in the array :D
>
> Note what you say here...
>
>>
>> IDL> a=[6.2,12.5,14.1,0.,!values.f_nan,22,!values.f_nan]
>> IDL> print,max(a)
>> 22.0000
>> IDL> print,min(a)
>> 0.00000
>>
>> ; go on, repeat this (it is 00:23 where I am @, so CARPE NOCTEM! ) :-P
>>
>
> and here
>
>> IDL> a=[!values.f_nan,6.2,12.5,14.1,0.,!values.f_nan,22,!values.f _nan]
>
> but note that now the first value is an NaN. I think the change has
> more to do with this - the positioning of the NaN - than the actual
> number of NaNs in your array.
>
>> If the MAX function is run on an array containing NaN values and the
>> NAN keyword is not set, an invalid result will occur.
>
> But yes, your getting invalid results, which isn't surprising if you
> put in invalid data, so best to check for it before you do it.
>
> --
> Edd
Another item of note; you may well get differing results across different
platforms if you execute MIN, MAX, TOTAL, MOMENT, etc., on
the same array containing NANs if you fail to use the NAN keyword.
My rule of thumb is to always use the NAN keyword when performing statistics
like these on derived floating point or double precision values when I
know there's not a guarantee that my floats will be bounded.
Jim P.
|
|
|
|