Choose floating point arithmetic, decimal arithmetic, or arbitrary precision arithmetic

Currently, svg seems to be buggy due to not adequately handling floating point arithmetic. I see three possible solutions:

1. Accommodate the precision limits of floating point arithmetic

E.g. instead of "if a = 1.5 you do if abs(a - 1.5) < limit". (Source.) This avoid bugs even if floating-point arithmetic has caused a to be, say, 1.49999999999999999999999999 instead of 1.5.

Pros:

• Calculations would remain fast.
• If CompSci students/graduates start working on the codebase, this approach would be familiar to them.

Cons:

• For non-CompScis (e.g. several current ContentMine contributors), floating point arithmetic violates the principle of least surprise, risking logic errors.

2. Use decimal arithmetic (e.g. BigDecimal) instead of floating point arithmetic (e.g. double)

Pros:

• Calculations would be more intuitive than floating point, for non-CompScis.

Cons:

• Slower than floating point arithmetic.
• Can't use normal arithmetic operators.
• Risks rounding errors.

3. Use arbitrary-precision arithmetic instead of floating point arithmetic

Pros:

• Obeys principle of least surprise, minimising risk of logic errors.
• According to (1, 2, 3) helpful sources, several suitable libraries exist:

Library	Language	License
Apfloat	Java, C++	LGPL
GMP	C and C++ w/Java bindings	LGPL
JAS	Java	LGPL
JLinAlg	Java	LGPL
JScience	Java	BSD-type

Cons:

• Slower than floating point arithmetic.
• Requires a library dependency.

@petermr, @mjw99, @AndyHowlettGitHub, @tarrow , et al, which of the options above would you prefer in principle?

My own inclination is towards correctness even at the cost of speed, so of these three options, I prefer option 3.

[tarrow]

In principle I prefer 3. For the same reason.

[mjw99]

I have not looked at this in quite a while and I am not sure of the best answer at this moment in time; one would need to know the precision of the data coming in. However, all of the unit tests (JUnit) in these projects make use of 1 when comparing floats.

The next two points are off-topic to this bug, but are, IHMO, more important than the bug itself.

Firstly, I cannot actually compile the current HEAD of this tree; Maven cannot resolve org.contentmine:euclid:jar:2.1.0; it should be able, this is not a SNAPSHOT dependency. In the spirit of Donald Knuth's philosophy on premature optimisation, I would focus on getting the code to actually compile first before investigating this specific bug. If the code does not compile and pass its appropriate unit tests, it will be very difficult to ascertain its handling of floating point arithmetic. Right after that, I would make use of github's Travis CI system to prevent regression and then finally I would look at tackling this.

Secondly, I'm not sure if this tree is the official repository or if https://bitbucket.org/wwmm/svg/ is? This is confusing to someone new to the project. There is also a duplicate issue tracker: https://bitbucket.org/wwmm/svg/issues?status=new&status=open . Are the issues in the bitbucket tracker also present in the github tree or were they solved when the project was, and I assume, migrated to github?

@mjw99 wrote:

I cannot actually compile the current HEAD of this tree; Maven cannot resolve org.contentmine:euclid:jar:2.1.0; it should be able, this is not a SNAPSHOT dependency. In the spirit of Donald Knuth's philosophy on premature optimisation, I would focus on getting the code to actually compile first before investigating this specific bug. If the code does not compile and pass its appropriate unit tests, it will be very difficult to ascertain its handling of floating point arithmetic.

Agreed. Bug filed: ContentMine/meta#1

Right after that, I would make use of github's Travis CI system to prevent regression

Agreed. Bug filed: ContentMine/meta#4

Secondly, I'm not sure if this tree is the official repository or if https://bitbucket.org/wwmm/svg/ is? This is confusing to someone new to the project. There is also a duplicate issue tracker: https://bitbucket.org/wwmm/svg/issues?status=new&status=open . Are the issues in the bitbucket tracker also present in the github tree or were they solved when the project was, and I assume, migrated to github?

Agreed. Bug filed: ContentMine/meta#5