[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: JULDAY 5.4 not same as 5.3?
Thanks for the tip. I launched IDL with the -32 option, but it still
doesn't work right. JULDAY behaves incorrectly in certain cases which
I will describe below. Unfortunately Pertti, you used long argument and not
ulong arguments, which I suspect, is why it worked for you.
SUMMARY:
***
The bug appears only in unsigned long and unsigned 64-bit long when all 6
args are present, and appearantly does not affect Windows versions.
Fix: typecast all 6 args to be long when calling JULDAY.
***
DETAILS:
This bug is independent of whether or not I'm running in 64-bit or 32-bit
memory mode. Since everything before this was in 64-bit mode, I'll show you
everything here in 32-bit mode.
IDL> print,!version
{ sparc sunos unix 5.4 Sep 25 2000 32 64}
IDL> $uname -a
SunOS sun4 5.7 Generic_106541-12 sun4u sparc SUNW,Ultra-30
IDL> mo=long(2) & day=long(16) & year=long(2001) & h=long(0) & m=long(0) &
s=long(0)
IDL> x=julday(mo,day,year,h,m,s)
IDL> help,x
X DOUBLE = 2451956.5
As expected, it works fine with all 6 long arguments, however, with
ulong...
IDL> mo=ulong(2) & day=ulong(16) & year=ulong(2001) & h=ulong(0) &
m=ulong(0) & s=ulong(0)
IDL> x=julday(mo,day,year,h,m,s)
IDL> help,x
X DOUBLE = 1.8140893e+08
This is not correct, however, if we leave off the h,m,s args...
IDL> mo=ulong(2) & day=ulong(16) & year=ulong(2001)
IDL> x=julday(mo,day,year)
IDL> help,x
X LONG = 2451957
It works! (This is the new Julian day starting at noon on Feb 16,2001.)
To demonstrate the ulong64 problem, here's more sample output.
IDL> mo=ulong64(2) & day=ulong64(16) & year=ulong64(2001) & h=ulong64(0) &
m=ulong64(0) & s=ulong64(0)
IDL> x=julday(mo,day,year,h,m,s)
IDL> help,x
X DOUBLE = 7.6861434e+17
IDL> x=julday(mo,day,year)
IDL> help,x
X LONG = 2451957
I think we've made some progress in understanding the bug. Incorrect
results are reported when 6 unsigned-long or unsigned-64-bit-long
parameters are passed to JULDAY. Unsigned integer, integer, long, and
long64 all seem to work properly.
The problem seems to be isolated to ULONG and ULONG64 independent of
whether running in 32-bit or 64-bit memory mode. Passing ulong and ulong64
parameters each give different wrong answers.
I'm getting around this by typecasting all my arguments to be long in the
call to JULDAY.
We still have the IDL lib directory for the old 5.3 versions. The old
procedure works even under the new 64-bit version regardless of input
parameter data type. This leads me to believe that the bug is actually
hidden in the JULDAY.PRO file in the IDL lib directory. Look at the
differences in code between the two versions. It is drastic.
Lesson learned: typecast arguments to JULDAY to be long.
Cheers,
Don
Pertti Rautiainen wrote:
> Don Woodraska (don.woodraska@lasp.colorado.edu) wrote:
> : I should have included this in the original post:
> :
> : IDL> print,!version
> : { sparc sunos unix 5.4 Sep 25 2000 64 64}
> :
> : Thanks for your response Mark. I'll bet it must be a 64-bit-only bug.
> : Can anyone else verify this bug on another 64-bit machine?
>
> Mhhh...
>
> IDL> umm=2l & udd=16l & uyear=2001l
> IDL> uhr=0l & umin=0l & usec=0l
> IDL> in_jday = julday( umm, udd, uyear, uhr, umin, usec )
> IDL> help,in_jday
> IN_JDAY DOUBLE = 2451956.5
> IDL> print,!version
> { sparc sunos unix 5.4 Sep 25 2000 32 64}
> IDL> $uname -a
> SunOS sun4 5.8 Generic_108528-03 sun4u sparc SUNW,Ultra-Enterprise
> IDL> $/bin/isainfo -b
> 64
>
> According to IDL Online Help, there are two versions of IDL 5.4 for
> Solaris, 64-bit and 32-bit memory support. We have 64-bit
> kernel (Solaris 8), but still seem to use 32-bit memory support (if I
> understand correctly the contents of !version system variable). If you
> have both 64-bit and 32-bit versions installed, it should be possible
> to start IDl in 32-bit mode by giving option -32.
>
> Pertti
--
Donald Woodraska, Phone: 303-735-5617, Fax: 303-735-4843
Laboratory for Atmospheric and Space Physics, University of Colorado
Campus Box 590, 1234 Innovation Drive, Boulder, CO 80303