Back in the bad old days of MPC80, we indicated approximate uncertainties in RA, dec, magnitude, and time via precision (the only method commonly available to us). A declination, for example, would be given to 0.1 or 0.01 arcsecond precision, or sometimes one-arcsec precision if the data was really bad.
Find_Orb would assume that the value was rounded. So if you gave the dec to 0.1 arcsec precision, the uncertainty could not be less than 0.5 arcseconds. Specify something lower than that (which you could/can do via comment lines in MPC80), and your sigmas were considered unreasonably low and bumped up to half the precision. [*]
In ADES, I've taken a similar approach. The problem is that it appears a fair amount of data is submitted with trailing zeroes omitted. So my code will read in RA = 314.159 degrees, and assume it's only good to (at best) 1/2000 degree = 1.8 arcseconds at best.
The practice of omitting trailing zeroes appears to be common enough that I've reluctantly decided I can't infer that short values were rounded or truncated (unless they were converted from MPC80; in those cases, I can rely on precRA, precDec, and precTime.)
The ADES specification doesn't say anything about what precision "should" be used, though maximum field sizes are specified. I can't see requiring that trailing zeroes be retained, but perhaps a note could be added to the documentation suggesting that the precision ought to be consistent with the rmsWhatever value?
[*] Pedants will point out -- correctly -- that the root-mean-square error introduced by rounding to the nearest x is not x/2, but x/sqrt(12). Still, give me a value to 0.1 arcsec precision, and I've a tough time believing your uncertainty is really about 0.029".
Pedants will also point out -- again correctly -- that whatever value is chosen isn't a "floor"; it should be added, in quadrature, to rmsWhatever.
Back in the bad old days of MPC80, we indicated approximate uncertainties in RA, dec, magnitude, and time via precision (the only method commonly available to us). A declination, for example, would be given to 0.1 or 0.01 arcsecond precision, or sometimes one-arcsec precision if the data was really bad.
Find_Orb would assume that the value was rounded. So if you gave the dec to 0.1 arcsec precision, the uncertainty could not be less than 0.5 arcseconds. Specify something lower than that (which you could/can do via comment lines in MPC80), and your sigmas were considered unreasonably low and bumped up to half the precision. [*]
In ADES, I've taken a similar approach. The problem is that it appears a fair amount of data is submitted with trailing zeroes omitted. So my code will read in RA = 314.159 degrees, and assume it's only good to (at best) 1/2000 degree = 1.8 arcseconds at best.
The practice of omitting trailing zeroes appears to be common enough that I've reluctantly decided I can't infer that short values were rounded or truncated (unless they were converted from MPC80; in those cases, I can rely on
precRA,precDec, andprecTime.)The ADES specification doesn't say anything about what precision "should" be used, though maximum field sizes are specified. I can't see requiring that trailing zeroes be retained, but perhaps a note could be added to the documentation suggesting that the precision ought to be consistent with the
rmsWhatevervalue?[*] Pedants will point out -- correctly -- that the root-mean-square error introduced by rounding to the nearest x is not
x/2, butx/sqrt(12). Still, give me a value to 0.1 arcsec precision, and I've a tough time believing your uncertainty is really about 0.029".Pedants will also point out -- again correctly -- that whatever value is chosen isn't a "floor"; it should be added, in quadrature, to
rmsWhatever.