> > 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.
Ok, that's what you mean. I think the default version of f(2) shouldn't call evalf() in the background, as imho you want to work with exact expressions by default. However, how about this syntax: In [18]: f = Lambda(x, term, evalf=True) In [20]: f(2) Out[20]: 73.68910751852562519599736335 ? (I am talking about the syntax, not speed for now) > 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? Not sure what you mean here -- seems ok to me, doesn't it? > > 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 I think my attitude is the opposite -- if there is a good package that does the job (be it numpy, scipy, Sage or anything else), I want sympy to be easily usable with that package. Only if the user doesn't have the package, I think instead of forcing him to install it (by making sympy depending on it) I think it's better if sympy can do the job too, even if slower. > as very good numerical capabilities. And for my practical work I need > a good interface between symbolic and numeric calculations. If my term Yes, the same here. > 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. Indeed, very good example. > 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. I think the lambdify is the way to go. Would numpify be the solution? Well, we definitely need numpify anyway. Then you could use it something like: 1) Lambda(x, term) ... sympy way without evalf 2) Lambda(x, term, evalf=True) ... faster way with evalf 3) Lambda(x, term, lambdify=True) ... much faster using lambdify 4) Lambda(x, term, numpify=True) ... even faster for large arrays using numpify Now we can discuss which should be the default. Note also the robustness issue --- the 1) case will work anytime, 2) only if the result is a number, 3) only if lambdify supports it and 4) only if numpify supports it and if numpy is installed > > 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. Agree. Like numpy ufuncs. > > > > 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. Well, numpify is imho the solution here. > > > > 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? Yes, definitely the algorithms for example for matrix solvers are different. > > 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. Exactly. > > 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 Yep. > 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 :-) Definitely, if it can be implemented so that it's maintainable, I am all for it. But I don't want to go into another debate sympy vs sympycore now. :) I am open to all improvements. On Thu, Apr 17, 2008 at 10:23 AM, Friedrich Hagedorn <[EMAIL PROTECTED]> wrote: > > On Thu, Apr 17, 2008 at 12:07:57AM +0200, Ondrej Certik wrote: > > > 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 > > Then I think it would be good to adjust the names: > > sympy.acos <--> numpy.arccos > > From the user point of view it would be good that all functions have the > same name in all python math modules (numpy, sympy, mpmath, math). > > May bo to work with alias? > On Thu, Apr 17, 2008 at 10:25 AM, Robert Kern <[EMAIL PROTECTED]> wrote: > > > From the user point of view it would be good that all functions have the > > same name in all python math modules (numpy, sympy, mpmath, math). > > numpy's the odd one out, but it's not going to change this late in the game. Right. I guess the numpify() should take care of it. Here is a preliminary code: http://code.google.com/p/sympy/issues/detail?id=756 All that is needed is to polish it, write tests and that's it. Volunteers? :) Ondrej --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
