[issue41315] Add mathematical functions as wrappers to decimal.Decimal methods

[Jean Abou Samra]

Jean Abou Samra  added the comment:

Okay, understood, thanks for your detailed explanations.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41315] Add mathematical functions as wrappers to decimal.Decimal methods

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Jean, I sympathize a bit with your wish, but decimal was designed for business, 
 not science.  Sqrt, exp, and 3 versions of log are the only math methods, and 
they happen to be the ones with some use in business calculations and 
statistics.  Extended math-science use needs a module that would wrap these 
methos and either include math module functions or decimal implementations 
thereof.  This might be candidate for pypi as well as someone's private 
collection.

--
nosy: +terry.reedy
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41315] Add mathematical functions as wrappers to decimal.Decimal methods

[Raymond Hettinger]

Raymond Hettinger  added the comment:

FWIW, I don't really buy into the use case.  In my experience a nest of 
existing functions that are designed for floats will somewhere being using a 
float constant like 0.5, e, pi, or tau.  So, just feeding in a decimal input 
isn't sufficient to get it to work.  Also, for your idea to work, the function 
couldn't explicitly reference math.exp(x); instead, it must just use exp() so 
that you could substitute, "from decimal import exp" for "from math import 
exp". 

Also, this proposal would be a limited utility because most of the functions in 
the math module don't have an existing equivalent in the decimal methods.  The 
inconvenient fact is that the decimal module wasn't designed to be a drop-in 
substitute for floats — it's principal design objectives were somewhat 
different.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41315] Add mathematical functions as wrappers to decimal.Decimal methods

[Jean Abou Samra]

Jean Abou Samra  added the comment:

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 *

with

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 numpy.dot(A, B) and numpy.ndarray.dot(self, 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()
with
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.

--
nosy: +Jean_Abou_Samra

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41315] Add mathematical functions as wrappers to decimal.Decimal methods

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I concur with Stefan.  This would mostly be a waste.

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41315] Add mathematical functions as wrappers to decimal.Decimal methods

[Stefan Krah]

Stefan Krah  added the comment:

The top level decimal.py that dispatches to either _decimal or
_pydecimal is pure Python.  So perhaps these applications could
add these methods themselves:


>>> import decimal
>>> def exp(x):
... return x.exp()
... 
>>> decimal.exp = exp
>>> 
>>> from decimal import *
>>> exp(Decimal(2))
Decimal('7.389056098930650227230427461')


As you see, it is no big deal, but it feels a bit odd to have
some methods like exp() and sqrt() exposed in the top level.


We already have:

  Decimal.exp()

And:

  >>> c = getcontext()
  >>> c.exp(Decimal(2))
  Decimal('7.389056098930650227230427461')

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41315] Add mathematical functions as wrappers to decimal.Decimal methods

[Jean Abou Samra]

Change by Jean Abou Samra :


--
title: Add mathematical functions as wrapper to decimal.Decimal methods -> Add 
mathematical functions as wrappers to decimal.Decimal methods

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com