Re: Reading 32-bit complex numbers in IDL (16-bit real / 16-bit imaginary) [message #77254 is a reply to message #77175] |
Sat, 13 August 2011 05:26  |
Wout De Nolf
Messages: 194 Registered: October 2008
|
Senior Member |
|
|
On Fri, 12 Aug 2011 06:15:35 -0700 (PDT), "Waqas A. Qazi"
<waqastro@yahoo.com> wrote:
> Hi chl and wox,
>
> Thanks, I took up from the info both of you noted here, and did some
> reading on my own.
>
> It seems the numbers are indeed half-precision floating point (never
> knew this was a data-type!), but in the data storage here, they are
> specified as integers and should be read as such. The data
> specification document states clearly that "samples are stored as 16
> bit / 16 bit complex integer (4 bytes).
>
> Wox, I understand the logic you have presented, and I will follow
> that, but have one question. After defining an intarr (16 bit) and
> reading 2-byte integers and later pairing them up for intput into the
> complex function, why do I have to convert from integer to float
> first? I think that the complex function should automatically convert
> them to single-precision float complex??
>
>
> Thanks,
> Waqas.
When I say "convert integer to float" I don't mean that you would
convert 10 to 10.0 for example. The value of the integer is not
concidered at all, it's the "bit-content" that is used. The integer is
just a bag of bits that represent a foating point number according to
the IEEE754 standard. That's why the function is call BINARYTOFLOAT
and not INTEGERTOFLOAT or something. In the example I gave:
IDL> integer='3555'x
IDL> f=binarytofloat(integer,precision=0)
IDL> print,integer
13653
IDL> print,f
0.333252
You can see that the integer value 13653 has nothing to do with
0.33325... However both numbers have the same binary representation,
namely
IDL> print,integer,format='(b016)'
0011010101010101
Note: Since IDL can't handle 16bit floats, the binary representation
of f (32bit float) isn't the same anymore as that of 13653. The value
of f is correct however: the value represented by 13653 under the
half-precision IEEE 754 convention.
|
|
|