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

Home » Public Forums » archive » Windows/Linux reading binary data - sign problem
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: Windows/Linux reading binary data - sign problem [message #57986 is a reply to message #57873] Thu, 10 January 2008 08:42 Go to previous messageGo to previous message
Nigel Wade is currently offline  Nigel Wade
Messages: 286
Registered: March 1998
Senior Member
RussellGrew wrote:

> Hi Nigel,
>
> The number is the result of further manipulation. I think the
> manipulation may be the problem here.
>
> I have tried the code on IDL 6.3 64 bit and IDL 6.1 32 bit in linux
> [both little endian machines] - both with the same problem!
>
> Code extract follows. The final values are stored in the 'a' matrix. I
> dont have the documentation for the binary file format handy.
>
>
> openr,u,fnm, /get_lun
> status = FSTAT(u)
> dd = status.size / (4*60)
>
> a=lonarr(dd,60)
> bdat=byte(1)
> dat=bytarr(4)
>
> for j=0,dd-1 do $ ;Loop to count total data rows and
> begin
> for i=0,59 do $
> begin
> fdat=double(0.0)

This line is redundant.

> sgn=1.

This line is redundant (sgn is never assigned other than here).

> for aa=0,3 do $ ;data component rows in file.
> begin
> READU,u,bdat
> dat(aa)=bdat
> end

This loop is redundant, just read the byte array.

> dat(0)=dat(0)-64 ; take off 2^30

What is the purpose of this line? What data format does your binary file
contain? It's not masking a bit in dat(0), it is subtracting a fixed value and
creating a (possibly negative) INT.

> fdat=dat(0)*256.*256.*256.+dat(1)*256.*256.+dat(2)*256.+dat( 3)

This appears to be building a floating point number from a 32bit big-endian
integer (apart from the "take off 2^30" part). Why make a float when a long
would do the job with no inaccuracy?

> fdat=sgn*fdat

This line is redundant, sgn is always 1.0.

> a[j,i]=fdat

Now you convert your floating point number back to an integer...

I don't see how the above code could generate the floating point number
-2147.48. There is no fractional part.

> end
> endfor
> free_lun, u
>
> Any ideas? I assume Linux must handle some part of the above
> differently.

I would handle the entire process differently...

--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@ion.le.ac.uk
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Re: putting data into .kml (google earth) from IDL
Next Topic: Problem Accessing Shared Objects

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

Current Time: Thu Oct 09 22:59:14 PDT 2025

Total time taken to generate the page: 0.80030 seconds