So if you’re writing say a game with projectiles traveling a certain trajectory it’s good enough

Could you explain it please

Thanks
Michel Hummel

You don’t need to do the addition as floating point, I have move the braces around…

public static double exp(double val) {
    final long tmp = (long) (1512775 * val) + (1072693248 - 60801);
    return Double.longBitsToDouble(tmp << 32);
}

Additionally if you analyse the error there is a correlation to the mantissa of the result, which you can then correct for. The error is approximately (mantissa – mantissa^2)/2.9. Doing this all as integer math in fixed point format you get.

public static double exp(double val) {
    final long tmp = (long) (1512775 * val) + 1072693248;
    final long mantissa = tmp & 0x000FFFFF;
    int error = mantissa >> 7;   // remove chance of overflow
    error = (error - a * a) / 186; // subtract mantissa^2 * 64
                                   // 64 / 186 = 1/2.90625
    return Double.longBitsToDouble((tmp - error) << 32);
}

PS hope this is valid Java, I converted from C.

The explain the shifting. The mantissa has 20 bits to the right of the decimal place. a is formed by shift right 7, leaving 13 bits to the right. When a is squared you double the number of decimal bits arriving at 26. Which is 20 bits times the scaling factor or 64 (6 bits). Now a squared matches error so the subtraction is valid.

Dr.E
http://www.turingshop.com/reports/01Java/

6.233 sec, Math.log(val)
0.531 sec, 6*(x-1)/ (x + 1 + 4*(Math.sqrt(x)))

5.920 sec, Math.exp()
1.108 sec, exp optimized with IEEE 754 trick

15.967 sec, Math.pow(a, b)
11.014 sec, e^(b * log(a))
7.607 sec, e^(b * log(a)) + IEEE 754 trick
2.109 sec, e^(b * log(a)) + IEEE 754 trick + LOG approximation
1.827 sec, simplified everything