Hi Bill,

--- In guide-user@yahoogroups.com, Bill J Gray <pluto@...> wrote:

> It also looks as if the JPL folks have been thinking about these
> matters recently; http://ssd.jpl.nasa.gov/?horizons_news has an
> update on 15 February mentioning that "...constellation boundaries
> have been updated to use two more digits of precision for sub
> 0.1-arcsecond specification." (Which also means that if they were
> using apparent B1875.0 coordinates instead of mean B1875.0 ones,
> the error could have been overlooked, masked by the greater error
> due to using imprecise boundaries.)
>
I mentioned this problem last week to Jon Giorgini from the JPL here is what I told him :

"I realized just now the most important cause of the differences I found between Horizon and my calculations of the Sun entry in the constellations. I had noticed that the entry in some constellations was correct and in the others no. The reason is quite simple :
If you look at the algorithm of NG Roman, you will notice that the
boundaries converted in decimals are rounded to 4 decimals.
While this is sufficient for some constellation limits, it is not for
others.
For example, the limit Cap/Aqr from Delporte (21h52m) is converted in 21.8667. But 21.8667 are actually 21h52m00,120s.
This 0,120s in RA converts in about 1,8 arcsec and the Sun needs about 43 seconds of time to cover that distance.
Of course for stars, slower planets or planet nearly stationary this may lead to much bigger differences. "

And he kindly corrected the database immediately. But I think that it remains other problem with the algorithm of N.G Roman :
1) The precession formulas are old formulas from Newcomb, I am not sure that they may still be used with J2000 positions.
2) It looks like the time is badly rounded for T and t in the precession formulas like just entering 2000 and 1875 for the calculation rather than the accurate Julian day time 2451545 for J2000 and 2405889.25855 for B1875.
And after all that there is the aberration question.

Luc