| n_elements and NaN [message #74563] |
Tue, 25 January 2011 12:26  |
R.Bauer
Messages: 1424
Registered: November 1998
|
Senior Member |
|
|
Just recognized some fun with NaN or more arguments against NaN.
n_elements haven't a NaN keyword
Reimar
|
|
|
|
| Re: n_elements and NaN [message #74613 is a reply to message #74563] |
Thu, 27 January 2011 07:24  |
Jeremy Bailin
Messages: 618
Registered: April 2008
|
Senior Member |
|
|
On Jan 26, 12:20 pm, Reimar Bauer <R.Ba...@fz-juelich.de> wrote:
> Am 26.01.2011 09:15, schrieb alx:
>
>> On 25 jan, 21:26, Reimar Bauer <R.Ba...@fz-juelich.de> wrote:
>>> Just recognized some fun with NaN or more arguments against NaN.
>
>>> n_elements haven't a NaN keyword
>
>>> Reimar
>
>> Why should it do ?
>> "N_elements(x)" is the old way for "(Size(x))[-1]" or "Size(x,/
>> N_ELEMENTS)".
>> What you want is "where(finite(x), COUNT=number_of_finite_elements,
>> NCOMP=number_of_nan)".
>> The two statements adress two different things: the x size and x
>> content.
>> alx.
>
> This is only a workaround. Until NaN is not completly supported we will
> always have risks to use it. Or having more complicated code as usually
> needed. If you for example expect only to have Long values you would
> never expect NaN numbers there and the data of type float.
>
> Reimar
I'm with alx on this - I would be very annoyed if n_elements looked at
the contents of what it's given rather than just the syntactic
structure (it would be *much* slower, for one thing!).
-Jeremy.
|
|
|
|
| Re: n_elements and NaN [message #74632 is a reply to message #74563] |
Wed, 26 January 2011 09:20 |
R.Bauer
Messages: 1424
Registered: November 1998
|
Senior Member |
|
|
Am 26.01.2011 09:15, schrieb alx:
> On 25 jan, 21:26, Reimar Bauer <R.Ba...@fz-juelich.de> wrote:
>> Just recognized some fun with NaN or more arguments against NaN.
>>
>> n_elements haven't a NaN keyword
>>
>> Reimar
>
> Why should it do ?
> "N_elements(x)" is the old way for "(Size(x))[-1]" or "Size(x,/
> N_ELEMENTS)".
> What you want is "where(finite(x), COUNT=number_of_finite_elements,
> NCOMP=number_of_nan)".
> The two statements adress two different things: the x size and x
> content.
> alx.
This is only a workaround. Until NaN is not completly supported we will
always have risks to use it. Or having more complicated code as usually
needed. If you for example expect only to have Long values you would
never expect NaN numbers there and the data of type float.
Reimar
|
|
|
|
| Re: n_elements and NaN [message #74648 is a reply to message #74563] |
Wed, 26 January 2011 00:15 |
lecacheux.alain
Messages: 325
Registered: January 2008
|
Senior Member |
|
|
On 25 jan, 21:26, Reimar Bauer <R.Ba...@fz-juelich.de> wrote:
> Just recognized some fun with NaN or more arguments against NaN.
>
> n_elements haven't a NaN keyword
>
> Reimar
Why should it do ?
"N_elements(x)" is the old way for "(Size(x))[-1]" or "Size(x,/
N_ELEMENTS)".
What you want is "where(finite(x), COUNT=number_of_finite_elements,
NCOMP=number_of_nan)".
The two statements adress two different things: the x size and x
content.
alx.
|
|
|
|
| Re: n_elements and NaN [message #74656 is a reply to message #74563] |
Tue, 25 January 2011 14:19 |
rogass
Messages: 200
Registered: April 2008
|
Senior Member |
|
|
On 25 Jan., 21:26, Reimar Bauer <R.Ba...@fz-juelich.de> wrote:
> Just recognized some fun with NaN or more arguments against NaN.
>
> n_elements haven't a NaN keyword
>
> Reimar
Yes,
a nan check for all routines would be wonderful...
Schade an sich
CR
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
