| Re: Unix to Vax floating point conversion [message #4873] |
Wed, 16 August 1995 00:00 |
thompson
Messages: 584
Registered: August 1991
|
Senior Member |
|
|
"R. David Baker" <rbaker> writes:
> We are using PVWave Version 5.0 on a VMS Vax, and need to read in IEEE
> binary from a Sun Sparc2. We tried to use the CONV_UNIX_VAX procedure
> from the IDL Astronomy User's Library
> (http://idlastro.gsfc.nasa.gov/contents.html), but didn't get it to
> work correctly. Here's what we did:
> get_lun,unit
> openr,unit,filename
> readu,unit,i,t ; i is an integer to read the Sun Fortran
> ; header and t is a floating point array
> free_lun,unit
> print,t ---> show unconverted numbers <-- THIS IS THE PROBLEM
> CONV_UNIX_VAX,t,source_arch='sparc'
> print,t ---> show converted numbers
The problem was probably generated when you tried to print out the numbers
before converting them. As Wayne Landsman (landsman@sorbet.gsfc.nasa.gov)
points out from the IDL documentation
> "VAX Warning: Do not attempt to interpret an XDR (=Sparc) format
> floating-point number as a native floating number on a VAX. VAXen generate
> an illegal instruction trap when the CPU encounters illegal floating point
> values. Under VAX/VMS the illegal value is automatically replaced with
> zero and execution continues."
When you tried to print it out, you caused the computer to try to interpret it,
thus generating the problem. Since it's a VAX/VMS problem, and not an IDL one,
the same behavior should be seen in PVWave. The proper sequence should be
get_lun,unit
openr,unit,filename
readu,unit,i,t
free_lun,unit
CONV_UNIX_VAX,t,source_arch='sparc'
print,t
Wayne goes on to say,
> So the trick to doing the number conversions is to alway deal with bytes and
> never interpret an XDR number on a VAX.
I'm not sure what is meant here about always dealing with bytes. As long as
one converts the numbers into the host representation immediately after reading
them, you should be okay.
He also says,
> ... In IDL Vax V4.0 there was a bug in
> the /FTOXDR keyword, and another bug prevented one from even subscripting an
> XDR number on a Vax. (Note: these bugs will be fixed in the next release of
> IDL Vax VMS V4.0.1.).
This makes me mad. This is not the first time that bugs have been introduced
into IDL's BYTEORDER routine on DEC computers. It is absolutely vital for us
that data is written out to files in a host independent format. We use NFS to
distribute this data to a variety of computer platforms. THE BYTEORDER ROUTINE
IN IDL MUST WORK!
Wayne ends with,
> Note that none of the above problems apply to Alpha VMS machines, which
> are considerably less finicky.
Well, thank god for that. That explains why we haven't run into this bug. (We
haven't been so lucky in the past.)
Bill Thompson
|
|
|
|
| Re: Unix to Vax floating point conversion [message #4877 is a reply to message #4873] |
Tue, 15 August 1995 00:00  |
landsman
Messages: 93
Registered: August 1991
|
Member |
|
|
In article <40r3ah$rb0@saba.info.ucla.edu>, "R. David Baker" <rbaker> writes...
> We are using PVWave Version 5.0 on a VMS Vax, and need to read in IEEE
> binary from a Sun Sparc2. We tried to use the CONV_UNIX_VAX procedure
> from the IDL Astronomy User's Library
> (http://idlastro.gsfc.nasa.gov/contents.html), but didn't get it to
> work correctly. Here's what we did:
>
> CONV_UNIX_VAX,t,source_arch='sparc'
>
>
> The array t should be a 100 element array with floating values
> from 1.0 to 100.0. When we 'print,t', things look good except for
> numbers of even powers of two, i.e. 0,4,16,64. These values are set
> to 0.0 instead of the appropriate power of two. Any suggestions?
This works in IDL and so I suspect that there is a bug in the version of
PV-WAVE that you are using. Let me briefly quote from the IDL help for
the /FTOXDR (float to XDR) keyword to BYTEORDER:
"VAX Warning: Do not attempt to interpret an XDR (=Sparc) format
floating-point number as a native floating number on a VAX. VAXen generate
an illegal instruction trap when the CPU encounters illegal floating point
values. Under VAX/VMS the illegal value is automatically replaced with
zero and execution continues."
So the trick to doing the number conversions is to alway deal with bytes and
never interpret an XDR number on a VAX. In IDL Vax V4.0 there was a bug in
the /FTOXDR keyword, and another bug prevented one from even subscripting an
XDR number on a Vax. (Note: these bugs will be fixed in the next release of
IDL Vax VMS V4.0.1.) So I suspect that PV-WAVE 5.0 has a similar bug,
maybe when the converting the floating point number to bytes with the BYTE
extraction.
One solution would be to use CONV_UNIX_VAX on the SUN to convert
your numbers to VAX datatype, *before* transferring them to the VAX.
Note that none of the above problems apply to Alpha VMS machines, which
are considerably less finicky.
--Wayne Landsman landsman@sorbet.gsfc.nasa.gov
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
