mpmath and math make different result

[retsyo]

math.cos gives wrong answer.

import math
import mpmath

print(mpmath.__version__)

f = lambda x: x*mpmath.cos(x)
fact = mpmath.taylor(f, 0, 9)

print(fact)
print([mpmath.identify(i) for i in fact])
print('\n')


g = lambda x: x*math.cos(x)
fact = mpmath.taylor(g, 0, 9)

print(fact)
print([mpmath.identify(i) for i in fact])

says

[mpf('0.0'), mpf('1.0'), mpf('0.0'), mpf('-0.5'), mpf('0.0'), mpf('0.041666666666666664'), mpf('0.0'), mpf('-0.0013888888888888889'), mpf('0.0'), mpf('2.4801587301587302e-5')]
['0', '1', '0', '-((1/2))', '0', '(1/24)', '0', '-((1/720))', '0', '1/(2**7*3**2*5*7)']


[mpf('0.0'), mpf('1.0'), mpf('0.0'), mpf('0.0'), mpf('0.0'), mpf('0.0'), mpf('0.0'), mpf('0.0'), mpf('0.0'), mpf('0.0')]
['0', '1', '0', '0', '0', '0', '0', '0', '0', '0']

[warnerjon12]

The issue is that in the hsteps method, the values are all similar sizes. Floating point additions of similarly sized numbers with opposite signs can lose you a lot of precision, which happens in difference. Since mpmath.cos computes values with more precision, this precision loss is not as important. To give an idea, the values for the first iteration were on the order of 1e-19 with a sum on the order of 1e-260. This means that significant precision loss is to be expected from difference.

[warnerjon12]

I will make a pull request later that helps with this issue (basically I added a check so that all positive and negative values get added separately until the end). It still fails for math.cos, but there is not much else to do. Even sorting the values and adding them in the best order still doesn't work, because the final results are just too close. The only answer is to find a way to do it without the subtraction of similarly sized numbers.

[warnerjon12]

The only solution to this problem is to find another way to estimate the nth derivative of a function other than the current method (which is based around interpolating a degree-n polynomial around function points near the point of interest and getting the derivative of that from the leading coefficient). Generally, it is expected that machine precision will not yield enough accuracy for good results, and I would recommend closing this issue.

[fredrik-johansson]

Not a bug, as explained above.