| Re: Julian Day NE Julian Day [message #93897 is a reply to message #93896] |
Fri, 18 November 2016 06:43  |
wlandsman
Messages: 743
Registered: June 2000
|
Senior Member |
|
|
Yes, this is a precision issue. As noted in
http://aa.usno.navy.mil/data/docs/JulianDate.php
"Typically, a 64-bit floating point (double precision) variable can represent an epoch expressed as a Julian date to about 1 millisecond precision."
and the IDL results are "equal" to within 1 millisecond.
One way to improve the precision is to use modified Julian date
MJD = JD - 2400000.5 The highest precision Astronomy routines ( http://www.iausofa.org/index.html ) break up Julian date into two double precision numbers in order to maintain precision.
-Wayne
On Friday, November 18, 2016 at 7:30:34 AM UTC-5, andrew...@gmail.com wrote:
> Hi All,
>
> So in converting the time stamp from an astro image to Julian Day with JULDAY, I start off with seconds of 6.31, and after doing the back conversion with CALDAT, I end up with seconds of 6.3100353!
>
> Is this to be expected? Is it "wrong?" Is it one of those weird digital precision
> things that David F. used to bang on about? (Hi David)
>
>
> IDL> print,!version
> { x86_64 Win32 Windows Microsoft Windows 8.5.1 Nov 14 2015 64 64}
> IDL>
> IDL> Jd = julday(10,1,2016,10,10,6.31)
> IDL> print,jd,format='(F20.10)'
> 2457662.9236841439
> IDL> caldat,jd,mon,d,y,h,m,s
> % Compiled module: CALDAT.
> IDL> print,y,mon,d,h,m,s
> 2016 10 1 10 10 6.3100353
>
> And just to show that I'm calling the inbuilt IDL routines, and not altered copies:-
> IDL> help,/source
> Compiled Procedures:
> $MAIN$
> CALDAT C:\Program Files\Exelis\IDL85\lib\caldat.pro
>
> Compiled Functions:
> JULDAY C:\Program Files\Exelis\IDL85\lib\julday.pro
>
>
> I'm puzzled. And a bit concerned.
>
> TIA,
>
> Andrew Cool
>
> www.skippysky.com.au (for all your astro weather forecast needs...)
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
