Author Jean_Abou_Samra
Recipients Jean Abou Samra, Jean_Abou_Samra, facundobatista, mark.dickinson, rhettinger, skrah
Date 2020-07-17.15:04:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I would argue that given a function,

from math import *

def naive_calc_pi(n=100):
    u = sqrt(8)
    v = 4
    for _ in range(n):
        v = 2*u*v/(u + v)
        u = sqrt(u*v)
    return u

when you realize that floats have limited precision (happened to me several times while being taught and teaching Python), you could just replace

from math import *


from decimal import *

and use it, instead of the current

from decimal import Decimal as D

def sqrt(x):
    return D(x).sqrt()

Of course, you can define these, but as I repeatedly ended up doing this, I just thought I'd bring the idea upstream.

Another, perhaps more important argument is readability. We all think in terms of functions: log(x), not x.log(). I find it a significant fact that NumPy has both, B) and, B), but the former is generally preferred (the method's documentation points to the function and the first dozen Google search results for "numpy dot product" yield the function). It makes expressions resemble what we are used to: compare

(a + b).tan().log() = (a.tan() + b.tan()).sqrt()/(1 - a.tan()*b.tan()).sqrt()
sqrt(tan(a + b)) = sqrt(tan(a) + tan(b))/sqrt(1 - tan(a)*tan(b))

> Also, the APIs aren't completely harmonious because the Decimal methods accept an optional context object.

I don't see a problem with the functions also accepting this parameter. (np.sin() has many parameters after all.)

Overall, I think this modest addition would bring an improvement in the usability of the decimal module. I can make a PR.
Date User Action Args
2020-07-17 15:04:41Jean_Abou_Samrasetrecipients: + Jean_Abou_Samra, rhettinger, facundobatista, mark.dickinson, skrah, Jean Abou Samra
2020-07-17 15:04:41Jean_Abou_Samrasetmessageid: <>
2020-07-17 15:04:41Jean_Abou_Samralinkissue41315 messages
2020-07-17 15:04:40Jean_Abou_Samracreate