ContentMine / svg

ContentMine Fork of the WWMM svg Package
0 stars 3 forks source link

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

Open ghost opened 7 years ago

ghost commented 7 years ago

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:

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

Pros:

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

Pros:

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:

ghost commented 7 years ago

@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 commented 7 years ago

In principle I prefer 3. For the same reason.

mjw99 commented 7 years ago

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?

ghost commented 7 years ago

@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: https://github.com/ContentMine/meta/issues/1

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

Agreed. Bug filed: https://github.com/ContentMine/meta/issues/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: https://github.com/ContentMine/meta/issues/5