Am Dienstag, 3. Juli 2012 11:09:27 UTC+2 schrieb Stefan Krastanov:
The one exception is code inside sympy which was agreed at some point,
should not require more than a python interpreter. However, if you are
using nsolve with lambdify you are again doing it wrong, because the
only
Am Dienstag, 3. Juli 2012 22:00:41 UTC+2 schrieb Ondřej Čertík:
There is a difference between calling matplotlib, numpy or scipy,
and having a working fortran or C compiler working at your machine.
In particular, in scipy ODE, you can provide a simple Python function
to get the ODE
Am 03.07.2012 01:44, schrieb Ondřej Čertík:
However, while we can generate Fortran code, compile it and use
that for plotting, in many cases it is an overkill and a simple approach
1) or 2) provides enough speed to get the job done.
I'm not sure that this is the right kind of overkill we're
On Tue, Jul 3, 2012 at 2:09 AM, krastanov.ste...@gmail.com
krastanov.ste...@gmail.com wrote:
However, while we can generate Fortran code, compile it and use
that for plotting, in many cases it is an overkill and a simple approach
1) or 2) provides enough speed to get the job done.
I'm not
6x speedup makes a big difference if you are going to make an
evaluation thousands or even millions of times.
In fact, if you do the evaluation thousands or millions of times, the
difference will not be noticeable, because what will take long time is
the evaluation of the array inside
+1 to this. Each function should know how to numerically evaluate
itself using numpy or stdlib math (or whatever), and you should be
able to just do it directly, like expr.evalf(library=numpy) or
something like that. I don't see any reason why that wouldn't work.
eval'ing strings feels like
Am 01.07.2012 10:58, schrieb krastanov.ste...@gmail.com:
It basically rebuilds the object tree using string manipulations over
the str(expression) output. It is a hack, like the old lambdify in
this regard (the code is documented in details however).
It could be prone to breakage.
It could be prone to breakage.
str(expression) might be changed by people who're not aware that lambdify
depends on things like parseability and adherence to naming conventions in
str().
A lambdify of whatever variant that traced the object tree directly would be
much preferrable over
If I understand correctly the commit logs and the blog posts of the
gsoc student that did this some years ago, sympy's evaluation to
floats is too slow in order to use for plotting. The solution was to
compile expressions to standard precision non-symbolic numpy or just
python.math. The horrifying
Am 01.07.2012 13:05, schrieb krastanov.ste...@gmail.com:
I suppose that this makes you, as a professional programmer, get a
headache over the fragile design :)
Hehe, sort of.
Not that I should be too critical of that, I have certainly written my
share of ugly code - mostly due to performance
Am 01.07.2012 15:19, schrieb krastanov.ste...@gmail.com:
Deprecating lambdify and refactoring everything to use a new library
keyword argument (or something similar) will be great though.
Sounds reasonable.
--
You received this message because you are subscribed to the Google Groups
sympy
On Jul 1, 2012, at 1:20 AM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
On Sat, Jun 30, 2012 at 7:48 PM, Aaron Meurer asmeu...@gmail.com wrote:
On Jun 30, 2012, at 8:38 PM, krastanov.ste...@gmail.com
krastanov.ste...@gmail.com wrote:
Two reasons basically:
- the original lambdify has a
On Sun, Jul 1, 2012 at 7:54 AM, Aaron Meurer asmeu...@gmail.com wrote:
On Jul 1, 2012, at 1:20 AM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
On Sat, Jun 30, 2012 at 7:48 PM, Aaron Meurer asmeu...@gmail.com wrote:
On Jun 30, 2012, at 8:38 PM, krastanov.ste...@gmail.com
The AST stuff may be interesting and amusing, however before any
actual benchmarking it seems like overly complicated solution.
.evalf() is slow not because it traverses the expression tree (any
evaluation method would do this, closures would not make less function
calls which is the expensive
On Jul 1, 2012, at 12:23 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
On Sun, Jul 1, 2012 at 7:54 AM, Aaron Meurer asmeu...@gmail.com wrote:
On Jul 1, 2012, at 1:20 AM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
On Sat, Jun 30, 2012 at 7:48 PM, Aaron Meurer asmeu...@gmail.com wrote:
On
I did the following test. I applied the following patch:
diff --git a/sympy/core/add.py b/sympy/core/add.py
index d2cac9a..d5c3855 100644
--- a/sympy/core/add.py
+++ b/sympy/core/add.py
@@ -271,6 +271,9 @@ def as_coefficients_dict(a):
di.update(d)
return di
+def
Hi,
I have read the initial commit introducing the experimental_lambdify
(https://github.com/sympy/sympy/commit/6ee1bd36924b068c1ac74b634e40628cb815137d),
but it is not clear to me what the problems are with the old lambdify
in sympy.utilities.
Can these two lambdify functions be merged? It
Two reasons basically:
- the original lambdify has a very convoluted logic and seems hard to
maintain (the new one is not that great either, however it does not
break as easily) (in the commit history one can see how stuff
completely unrelated to the functionality of lambdify was bolted on
it)
-
18 matches
Mail list logo
