Re: BINARY FILES

[mole6e23(at)hotmail.com (Todd Clements)]

>At last count (at least on my newsreader) we have two replies (Todd
>Clements' second post doesn't count :o) and five.... well I don't know
>what to call them. That a SNR of 0.4. Oof.

Hmm...not sure if this message will increase that or decrease that. ;>

>I have used both Todd Clements' suggestion, then graduated to Liam's
>tools. I now work (almost) exclusively in netCDF so I avoid:

Of course, I didn't know that Liam's tools existed, so I reinvented the
wheel and made my own tools. Then, Of course^2, the advantage to
reinventing the wheel is that you can use the correct material and number
of spokes you want for the wheel instead of what someone else wants. The
routines I've written for our lab are one-liners that do 99% of everything
we need. We don't care much about portability, or generalized reading and
writing. We write out our own data and read in our own data. For
everything else, we use the command line. ;>

And the other advantage (I admit to not being familiar with CDF, so I
can't say whether this is supported) is that by writing my own routines, I
can take advantage of the file compression capabilities recently built
into IDL. Most of the data we write consists of x,y data or x,y and 2-d
image data. The 2-d image data files get rather large even in binary, but
they are highly compressible, so we save 80% of our disk space, which is
nice.

But then again, I'm the type that even sometimes when the wheel exists, I
invent it all over again because I want to know to make my own wheel. (Not
to mention I like to ride on one wheel - it's a fun activity - but perhaps
there is a connection here...)

Todd