comp.lang.idl-pvwave archive - RDF feed
type: channel
description: Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
items: Re: Unix to Vax floating point conversion

Re: Unix to Vax floating point conversion
type: item
description: 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
creator: landsman
date: 1995-08-15T07:00:00-00:00

Re: Unix to Vax floating point conversion
type: item
description: "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…
creator: thompson
date: 1995-08-16T07:00:00-00:00