Fix inappropriate approximation of Math.exp

[quaelnix]

FastMath.exp was discontinuous for x < -1 and thus completely ruined the output of Tobler's hiking function:

---

It also messed up the decayFactor calculation when the distance between two consecutive nodes was greater than 100m.

[polyscias]

Good catch!

Can you also plot the graph for the new implementation of this commit?

I am wondering how more expensive it is to use Math.exp instead of these approximations.

[quaelnix]

Can you also plot the graph for the new implementation of this commit?

I am wondering how more expensive it is to use Math.exp instead of these approximations.

Car routing (with KinematicModel) is around 2 % slower when Math.exp is used instead of the new FastMath.exp.

[afischerdev]

Good pointer.

I found a variante of this

    e = 1. + e / 256.;
    e *= e; e *= e;
    e *= e; e *= e;
    e *= e; e *= e;
    e *= e; e *= e;

A little bit closer to the Math.exp, brings back a correct 0.0 on exp(Double.NEGATIVE_INFINITY) and should not lose too much time.
What do you think?

[quaelnix]

What do you think?

The goal of FastMath.exp should be to achieve the same routing result as if Math.exp had been used, using as few CPU cycles as possible. On modern devices with hardware support for Math.exp there is little room for improvement anyway.

brings back a correct 0.0 on exp(Double.NEGATIVE_INFINITY)

I highly doubt that any of the new variants of FastMath.exp will return 0 if you input negative infinity.

What do you think?

After giving it some more thought, I would say we should remove FastMath altogether. This is pretty much a classic example of "premature optimization" and will likely cause problems again without any significant benefit to us.

[afischerdev]

I highly doubt that any of the new variants of FastMath.exp will return 0 if you input negative infinity.

Right, my fail. I check also StrictMath.exp and Math.pow(2.71828, e). Too many lines.

After giving it some more thought, I would say we should remove FastMath altogether.

All right, agreed.
I did some tests with a 300km route, about 6000 calls to exp(), ~5800 pts. Only minimal time differences in execution.

[quaelnix]

Right, my fail.

Don't worry, this stuff can be tricky.

Only minimal time differences in execution.

I think FastMath is only called a lot in a hot loop when the car routing models are used. And the old code made less than 2 % difference even in the worst scenario where this function is called millions of times per ~ 300 km.

[quaelnix]

If you want to remove FastMath entirely, feel free to just close this pull request. I sadly won't have time to contribute much to BRouter in the next couple of weeks or months.

[quaelnix]

@afischerdev, @abrensch, I think we should address this issue as part of the next update. My preferred solution would be to just drop FastMath altogether. What do you think?

[afischerdev]

I would agree that and could do the job the next days

[quaelnix]

I would agree that

@afischerdev, I have changed my pull request accordingly.