Floating point division resulting in a value exceeding 1 but should be equal to 1...maybe! I am computing the apparent magnitude of comets and minor planets using data from the Minor Planet Center.  The formula I use has a division and that result is passed to the arccosine function (in Python).
Occasionally the result of the division is slightly greater than 1, for example
6.272370848320445 / 6.2723697617591405 = 1.0000001732297912
I assume the result is not actually greater than 1; rather the result is an artefact of floating point arithmetic, particularly given the number of zeros after the decimal point.
If my assumption is correct, I want to catch this sort of situation and treat the result as if the division yielded exactly 1 (and so can safely be passed to arccosine).
If I make an arbitrary choice of say five decimal points and truncate the division result, then if the result is 1 I'm good, otherwise, drop the result.
I'm not sure if what I'm proposing is correct mathematically, so looking for guidance please.  I have assumed this issue arises due to floating point arithmetic, but if that assumption is wrong, then I'm not sure what else I can do.  It is possible the source data from the Minor Planet Center contains spurious data which is causing the actual error (and thus I shouldn't be trying to work around it but just let it fail).
The formula can be found here (using the H,G model).

I have experienced exactly the same situation with round-off (in calculation of finite rotations in C#). You theoretically know that the division equals maximally to 1 ergo you can implement it as follows:
$\max(-1.0, \min(1.0, x/y))~$ instead of $~x/y$
and your code will be safe.
