| Re: Incorrect behavior of /NAN [message #30021] |
Thu, 04 April 2002 11:38  |
Paul van Delst
Messages: 364
Registered: March 1997
|
Senior Member |
|
|
Jaco van Gorkom wrote:
>
> "Paul van Delst" <paul.vandelst@noaa.gov> wrote in message
> news:3CAC9914.B52D1669@noaa.gov...
>> Kenneth Bowman wrote:
>>> ....
>>> IDL> print, mean([a, a], /nan)
>>> NaN
>>
>> I think the last result *here* is wrong :o) Shouldn't it be 1.0? What is
> MEAN in this case
>> but:
>>
>> total([a,a],/NAN) / n_elements(non-nan values only)
>>
>> Both the numerator and denominator are 0.
>
> So you mean that 0 / 0 = 1.0 ? Or 0. / 0. = 1.0 ?
> In any case, IDL seems to disagree with you here: :-)
>
> IDL> print, 0./0.
> -NaN
> % Program caused arithmetic error: Floating illegal operand
>
> IDL> print, 0/0
> 0
> % Program caused arithmetic error: Integer divide by 0
>
Maybe a holistic division operator is required in these sorts of cases. :o)
paulv
--
Paul van Delst Religious and cultural
CIMSS @ NOAA/NCEP purity is a fundamentalist
Ph: (301)763-8000 x7274 fantasy
Fax:(301)763-8545 V.S.Naipaul
|
|
|
|
|
|
| Re: Incorrect behavior of /NAN [message #30025 is a reply to message #30024] |
Thu, 04 April 2002 10:19  |
Paul van Delst
Messages: 364
Registered: March 1997
|
Senior Member |
|
|
Kenneth Bowman wrote:
>
> I tried to incite some interest in this last week, but had no takers,
> so I'll try again. ;-)
>
> I believe that the behavior of the TOTAL function is incorrect in
> the case where all of the data are NaN and the /NAN keyword is set.
>
> Here are several possible cases:
>
> IDL> a = !values.f_nan
> IDL> print, total([a, 1.0])
> NaN
> IDL> print, total([a, 1.0], /nan)
> 1.00000
> IDL> print, total([a, a])
> NaN
> IDL> print, total([a, a], /nan)
> 0.00000
>
> I believe that the last case is incorrect.
>
> The documentation for /NAN says "Elements with the value NaN are treated
> as missing data." In the last case there are no valid data, so how can
> their sum be zero?
>
> I think this is probably a simple error in the TOTAL algorithm.
> Rather than computing the "sum of all the non-NaN values", it is
> probably doing "set sum to zero and then add all non-Nan values".
Seems reasonable to me. It only sums the data not flagged as missing. If all the data is
missing, the sum of nothing is, well, nothing.
> For comparison, the MEAN function does not behave this way.
>
> IDL> print, mean([a, 1.0])
> NaN
> IDL> print, mean([a, 1.0], /nan)
> 1.00000
> IDL> print, mean([a, a])
> NaN
> IDL> print, mean([a, a], /nan)
> NaN
I think the last result *here* is wrong :o) Shouldn't it be 1.0? What is MEAN in this case
but:
total([a,a],/NAN) / n_elements(non-nan values only)
Both the numerator and denominator are 0.
> Before I submit something (at least a question) to RSI, does anyone
> have comments?
Yes. Check your data *before* you TOTAL or MEAN them. :o)
paulv
--
Paul van Delst Religious and cultural
CIMSS @ NOAA/NCEP purity is a fundamentalist
Ph: (301)763-8000 x7274 fantasy
Fax:(301)763-8545 V.S.Naipaul
|
|
|
|
| Re: Incorrect behavior of /NAN [message #30027 is a reply to message #30025] |
Thu, 04 April 2002 09:32 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
Kenneth Bowman <k-bowman@null.tamu.edu> writes:
> I tried to incite some interest in this last week, but had no takers,
> so I'll try again. ;-)
>
> I believe that the behavior of the TOTAL function is incorrect in
> the case where all of the data are NaN and the /NAN keyword is set.
>
> Here are several possible cases:
>
> IDL> a = !values.f_nan
> IDL> print, total([a, 1.0])
> NaN
> IDL> print, total([a, 1.0], /nan)
> 1.00000
> IDL> print, total([a, a])
> NaN
> IDL> print, total([a, a], /nan)
> 0.00000
>
> I believe that the last case is incorrect.
>
> The documentation for /NAN says "Elements with the value NaN are treated
> as missing data." In the last case there are no valid data, so how can
> their sum be zero?
Hi Ken--
If all the data are missing, how can the sum be NaN? Neither a return
value of 0, nor a return value of NaN, seems to be appropriate to
me. This appears to be an undefined case.
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
|
|
| Re: Incorrect behavior of /NAN [message #30163 is a reply to message #30021] |
Thu, 04 April 2002 18:26 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
Paul van Delst <paul.vandelst@noaa.gov> writes:
>
> Maybe a holistic division operator is required in these sorts of cases. :o)
Or should IDL apply L'Hopital's rule? :-)
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
| Re: Incorrect behavior of /NAN [message #30168 is a reply to message #30025] |
Thu, 04 April 2002 13:06 |
Mark Hadfield
Messages: 783
Registered: May 1995
|
Senior Member |
|
|
"Paul van Delst" <paul.vandelst@noaa.gov> wrote in message
news:3CAC9914.B52D1669@noaa.gov...
> Seems reasonable to me. It only sums the data not flagged as missing. If
> all the data is missing, the sum of nothing is, well, nothing.
And IDL normally uses NaN ("Not a Number") to represent nothing. I rest
Kenneth's case
Though one could argue that since the IDL language is just a collection of
special cases, cobbled together over the years and thinly papered over in
places, one cannot say anything about what it *normally* does. Perhaps the
RSI developers could start to prove me wrong by fixing this anomaly.
--
Mark Hadfield
m.hadfield@niwa.co.nz Ka puwaha et tai nei
http://katipo.niwa.co.nz/~hadfield Hoea tatou
National Institute for Water and Atmospheric Research (NIWA)
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
