On Thu, Apr 17, 2008 at 12:07:57AM +0200, Ondrej Certik wrote:
> > > Which variant, A or B, would you prefere? I like B because the object you
> > > want to eval is the term. And the only information sympy have to know
> > > is the order of the symbols. And further you dont need to create a
> > > new variable name ("term" -> "f(x)").
> >
> > I'm inclined to agree with Gael that variant A is better (especially
> > if its already in, anyway) - I don't like the idea of modifying the
> > object in-place as that can cause a lot of confusion if its being
> > passed around to other scopes.
>
> Yes, modifying in place is bad.
The implementations are the same. And when I think I need variant B then
I could do this anymore :-)
Then we should work for the numeric version of the Lambda methode A.
> the solution A is already implemented in full, isn't it? At least it
not completely
> seems to work for me. Except the input [45], where you need to call
> the function vectorize, e.g.:
>
> In [1]: term = x + x**2
>
> In [2]: f = Lambda(x, term)
>
> In [3]: f(x)
> Out[3]:
> 2
> x + x
>
> In [4]: f(2)
> Out[4]: 6
But on the original term I get this:
In [17]: term=exp(x*x)*log(x*x)-x
In [18]: f = Lambda(x, term)
In [20]: f(2)
Out[20]:
4
-2 + ℯ *log(4)
In [21]: f(2).evalf()
Out[21]: 73.68910751852562519599736335
This seems to be corrected easily.
> In [5]: from numpy import vectorize
>
> In [6]: vectorize(f)([0, 1, 2, 3])
> Out[6]: [0 2 6 12]
Oh this seems funny:
In [22]: term = x + x**2
In [23]: f = Lambda(x, term)
In [25]: vectorize(f)([x,0,1,2])
Out[25]: [x + x**2 0 2 6]
But I dont know if I need the "[x]" feature?
> I think we should implement such a function in sympy as well, so that
> you don't have to have numpy for this to work.
> Generally we should behave exactly like numpy, with the exception that
> the arrays are not numeric (floating point), but symbolic (exact).
>
> We are almost there.
I know of your attention to be independend from other packages. But numpy
as very good numerical capabilities. And for my practical work I need
a good interface between symbolic and numeric calculations. If my term
become too big, I want to test it numericaly. Or I want to plot a term with
In [26]: f=vectorize(f)
In [27]: f(x)
Out[27]:
2
x + x
In [28]: from numpy import linspace
In [29]: t=linspace(-2,2,100)
In [30]: time y=f(t)
CPU times: user 4.19 s, sys: 0.23 s, total: 4.42 s
Wall time: 4.53
In [31]: from pylab import plot, show
In [32]: plot(t, y); show()
Out[32]: [Line2D(_line0)]
And compare the time with:
In [1]: term = x + x**2
In [2]: f = Lambda(x, term)
In [3]: from sympy.utilities.lambdify import lambdastr
In [4]: fstr = lambdastr(f(x), [x])
In [5]: import numpy as n
In [6]: f=eval(fstr, vars(n))
In [7]: from numpy import linspace
In [8]: t=linspace(-2,2,100)
In [9]: time y = f(t)
CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s
Wall time: 0.00
I think this is a big difference inparticular when I need 10**3 evals
of the term.
I think the difference in time is mainly due to the "Lambda" methode
does each eval with the subs-methode. I think for the numeric eval the
subs methode is the wrong way.
> The only remaining question is whether the "f" above should accept
> arrays directly, without the vectorize? Let's discuss it.
For the user its more comfortably. The verctorize process could be done
internaly.
> The vectorize is a good solution to me imho. BTW, if you implement
> your own function, like
>
> def f(x):
> if x > 5:
> return 1
> else:
> return 0
>
> you need to call vectorize too, otherwise it won't work for arrays.
> But I think the standard functions should be working like numpy
> functions -- ufuncs.
That is right. But here we talk about sympy expressions :-) I want to
eval a sympy expr fastly.
> BTW, I think we should also implement the rest of the useful functions
> from numpy in sympy as well -- it'd be useful to have it in pure
> python and those who want speed too will just install numpy and it'd
> have the same interface.
Im no expert in this. But are the technical details for a symbolic
implementation completely different from a numeric implementation?
That is why I think one package for symbolic and one for numeric
calculations. And these packages should have a very similar user
interface to communicate with ech other.
> And as to speed and sympy -- I believe you can have the same interface
> that sympy has and have basically any speed you want as well. There
Oh, thats a good statement :-)
> are currently at least three projects, that can be potentially used --
> sympycore, swiginac and Sage.calculus. Each requiring some work.
> Sage.calculus currently cannot be used without Sage (200MB of sources,
> almost 3hours of compiling on my machine, 1GB disk space), swiginac is
> difficult to extend, because the core is in C++ (ginac), sympycore is
> currently the closest -- I hope we will manage to find common
> interests with Pearu and have one interface, so that sympycore can be
> used with sympy and vice versa. Ideally merged with sympy if we agree
> on one way of doing things, if not, then at least the same interface.
I am for the sympycore because thats not so big. And I thought that
sympycore would be a real algebra module. I am no mathematician I am a
electrical engineer. But I have heard one lecture of algebra. I think
from the theoretical point its no matter for what objects you eval a term.
I remember that an algebra (A; F) has a set A with all the elements and
a set F with all the operations for the elements in A.
A symbolic term has only variable-SYMBOLS and operation-SYMBOLS. In what
algebra you eval a term dont care. The trivial case is you eval the term
in the term-algebra. Then you get the term itself. But you can eval the
term in the algebra for real numbers as well as for complex numers. The
main thing is that the operations are defined for the selected algebra.
But I dont know if one could implement such abstract view :-)
By,
Friedrich
By,
Friedrich
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sympy?hl=en
-~----------~----~----~----~------~----~------~--~---
