Status: Accepted
Owner: [email protected]
CC: [email protected]
Labels: Type-Defect Priority-Medium
New issue 2584 by [email protected]: Implementing _eval_evalf()
http://code.google.com/p/sympy/issues/detail?id=2584
Suppose I want to add a new function which is not supported out of the box
by mpmath. To still have numerical evaluation, I would define
_eval_evalf(self, prec). Here I would like to evaluate the argument, to
some precision, and then do my own numericas with it (say). Thus my naive
implementation would look like this:
def _eval_evalf(self, prec):
xn = self.args[0]._eval_evalf(prec)
return mystuff(xn)
However this does not work, because for example
In [1]: sqrt(I+1)._eval_evalf(15)
Out[1]:
0.5
(1 + ⅈ)
Indeed the default implementation (in sympy/core/evalf.py) just returns
None. The problem is that the function .n() actually does other magic which
is not in _eval_evalf(). However, calling .n() from _eval_evalf() is
cumbersome too, because the prec argument to _eval_evalf is in binary,
whereas the precision to n() is in decimal.
So:
Is sqrt(I+1)._eval_evalf(15) a bug? Note there are very many similar cases
like this, many core _eval_evalf implementations don't expect to handle
many cases.
Should correct _eval_evalf() call .n() instead? Should the
function ._evalf(), which apparently is supposed to do the same as .n()
just with binary precision be changed (because this is not what it does, it
calls _eval_evalf)?
--
You received this message because you are subscribed to the Google Groups
"sympy-issues" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy-issues?hl=en.
