np.exp比np.e慢得多？

In [49]: timeit.timeit("np.exp(100)", setup="import numpy as np") 
Out[49]: 1.700455904006958 

In [50]: timeit.timeit("np.e**100", setup="import numpy as np") 
Out[50]: 0.16629505157470703

是否有任何理由使用np.e ** 100的CPython實現比使用numpy版本要慢得多？不應該將numpy版本更快地推向C代碼？np.exp比np.e慢得多？

來源

2015-05-04 James

我相信前者是使用技術來逼近分析指數函數（可能考慮複平面）。後者可能使用浮點近似，這可以理解得更快。 –

一個明顯的原因是np.exp被設置爲處理數組，並且在確定輸入的類型/尺寸方面可能存在一些開銷。您可以試試這種情況下，你可能會看到其中的差別減少或消失：

timeit.timeit("np.exp(x)", 
       setup="import numpy as np; x = np.array([99, 100, 101])") 
# This actually seems to be faster than just calculating 
# it for a single value 
Out[7]: 1.0747020244598389 

timeit.timeit("[np.e**n for n in x]", 
       setup="import numpy as np; x = [99, 100, 101]") 
Out[8]: 0.7991611957550049

來源

2015-05-04 01:50:07 Marius

得是函數調用的開銷等。甚至np.exp(0)同樣是緩慢的，而不是實際上應該計算什麼。

>>> timeit.timeit("np.exp(100)", setup="import numpy as np") 
2.8452274883430846 
>>> timeit.timeit("np.exp(0)", setup="import numpy as np") 
2.836107299807054

來源

2015-05-04 02:03:56

爲什麼你認爲'exp（0）'自然會比'exp（100）'計算得更快？除非有代碼來專門檢查輸入'0'，這會減慢每一個呼叫。 –

@MarkRansom嗯，無可否認，我不知道它是如何實現的，我現在無法在numpy或Python中找到它，我只找到[this in C]（https://sourceware.org/git/?p=glibc .git; a = blob; f = sysdeps/ieee754/dbl-64/e_exp.c; h = 4eb1bdc657ed53f14abf4f6333732babe7d38e9b; hb = HEAD＃l109），看起來像這樣的特殊處理。 –

@MarkRansom雖然我在想的不是這種特殊的處理方式，而是一種自然的早期停止，就像冪級數的加數在最初的1之後爲0，因此計算循環立即停止在那裏。我再次承認，我不知道它是如何計算的，如果我錯了，指數的值對計算速度無關緊要，請教育我:-)。特別是，如果你能指出我的實際執行情況或告訴我它是如何計算的，我會很感激。 –

np.exp比np.e慢得多？

回答

相關問題