comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Bad data in structure (NaN HowTo?)
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Bad data in structure (NaN HowTo?) [message #22593] Wed, 22 November 2000 00:00 Go to previous message
Randall Skelton is currently offline  Randall Skelton
Messages: 169
Registered: October 2000
Senior Member
I have an array of large structures which occasionally is filled (via an
external C program) and passed into IDL with -12345 signifying the data
for that element is lost. I would like to convert the occurances of
-12345 to NaN's in IDL but I am a little perplexed on how to do this.

I had hoped that since this is technically an 'array' (albeit an array of
structures) I would just be able to use the 'where' command; alas, it
appears that structures are not allowed in the where command:

B = where(atrl eq -12345, count)
% Struct expression not allowed in this context: ATRL.

Each structure has about 450 elements in it and is comprised itself of
strings, ints, floats and doubles and arrays of each of the above. My
initial thought is to make an array of strings which represent the
elements of the structure and loop over that array, searching for '-12345'
in each element or array as I go. This seems rather inefficient. It
would be much nicer if I could directly assign the structure element to
NaN in C and pass it into IDL (and have IDL interpret the missing data as
as NaN)? Oh yes, it would be nice if I could use the same C code on
intel, PowerPC, and sparc architechures... Does anyone know how this
might be done?

Thanks for the help.

Randall
[Message index]
 
Read Message
Read Message
Previous Topic: Re: LONG AND NARROW IMAGE
Next Topic: Re: IDLDE crash on printing!

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Sat Oct 11 18:53:54 PDT 2025

Total time taken to generate the page: 0.40201 seconds