Use BCMath (where available) for all float arithmetic

[mstenta]

See the original issue that spawned this branch: #114

[BathoryPeter]

I measured length() function with BCMath enabled and disabled and the difference is more than significant.

$geom = GeoPHP::load(file_get_contents('20120702.gpx'));
$start = microtime(true);
for($i=0; $i < 50; $i++) {
    $geom->length();
}
var_dump(microtime(true) - $start);

BCMath enabled: 21.463 sec
BCMath disabled: 0.579 sec

[mstenta]

Whoa, 21 seconds is a long time! What's in that file?

BCMath is going to be more intensive, yes. But it is also going to be more precise. For some that might matter more than speed. Perhaps we should include some ability to globally enable/disable bcmath usage within GeoPHP?

Also, there are some issues with LineString::greatCircleLength() and LineString::haversineLength() methods: #114 (comment)

I posted that to the other issue, but forgot to update this pull request. This should be put on hold until that's fixed.

[BathoryPeter]

Just a small tracklog from the tests/input folder :)

[mstenta]

Rebased onto latest master, fixed a bug, and removed the bcscale(24) code. See #114 (comment) for more details.

This PR is still not ready to be merged, however.

Also, there are some issues with LineString::greatCircleLength() and LineString::haversineLength() methods: #114 (comment)

[mstenta]

I measured length() function with BCMath enabled and disabled and the difference is more than significant.

@BathoryPeter I wonder if this will be more reasonable without the bcscale(24) code. I assume BCMath operations will still be more intensive than regular PHP arithmetic, so it will still be slower, but maybe better with default bcscale() precision.

[mstenta]

FYI: I kept my commits separate to show the reasoning behind these recent changes, but we can plan to squash them into a single commit when it's time to merge.

[mstenta]

Currently 2 tests are failing:

There were 2 failures:

1) Tests_20120702::testMethods
Failed on length
Failed asserting that 0.11624637315233 matches expected 0.

/home/travis/build/phayes/geoPHP/tests/tests/20120702Test.php:217
/home/travis/build/phayes/geoPHP/tests/tests/20120702Test.php:47

2) MethodsTests::testMethods
Failed on length (test file: 20120702.gpx)
Failed asserting that 0 is not equal to 0.

/home/travis/build/phayes/geoPHP/tests/tests/methodsTest.php:218
/home/travis/build/phayes/geoPHP/tests/tests/methodsTest.php:52

Both have to do with calculated lengths of MultiLineString geometries. It makes sense that this would be affected by these changes, because using BCMath will result in more precise calculations. Maybe we just want to update the tests to look for these more precise values instead? We may also need to set bcscale() in the tests to specify the precision to use.

[paul121]

@mstenta I wonder if we should open this PR against the new fork of this repo: https://github.com/itamair/geoPHP

[mstenta]

@paul121 Yea probably. Although maybe we should fix the failing tests first, and review it all again. It's been a long time since I've looked at this, although we've been using it in farmOS for almost 10 years now!