refactor `org.xmlcml.euclid.EC.EPS`

[ostueker]

euclid/src/main/java/org/xmlcml/euclid/EuclidConstants.java

Line 310 in b900479

double EPS = 1.0E-14;

The Euclid constant org.xmlcml.euclid.EC.EPS is currently used in various ways, as PMR summarizes in #5:

a/ direct FP equality where we expect the values to be identical but this is to make sure
b/ physical tolerance - e.g. is a line horizontal
c/ (related) precision (ndecimal) for formatting FP for printing - mainly to save space.

Note that complex geometrical operations can give quite large deviations on different systems.

There is generally no consistency over different packages. Probably the main thing is to try to avoid hardcoding and at least have per-package CONSTANTs. An industrial strength implementation would probably have special toolkits for precision.

and here:

It's a harder problem than it looks. In some cases direct equality is often good enough - e.g. when numbers have been copied or formatted to - say - 3 places. But even simple maths operations can build up errors. And things like Angle can have quite large variations
Then there's "experimental" error - extracting coordinates from bitmaps, for example, which certainly seem to be time variable - i.e when there's a new OS they need mending. Shouldn't happen but it could be order of computation , etc.