On Mon, Sep 30, 2013 at 11:03 AM, F. B. <[email protected]> wrote: > Python is normally easier to write code than C++, but I think there is a > main exception, i.e. cases of complex class-structure. In C++ there is the > possibility of using IDEs with autocompletion enabled, which can any time > tell you which type a variable is, a great advantage of statically typed > languages. I tried for some time PyDev plugin in Eclipse, but it is not > comparable to C++ development, static methods are correctly guessed, but in > the case of class instances it is very poor.
The Jedi completion library for Python is pretty good. In the end, it's all heuristics because Python is dynamic, but it is pretty good in my experience. There are plugins for it for the most common editors, including emacs, vim, and sublime. > > By the way, I feel that complex class-objects should be in any case > rewritten to C++, for this very reason. > > Regarding the Rubi ruleset, I think that a pattern matching improvement and > rewriting in C++ would be needed, but one has also to improve the > assumptions module in order to be able to perform the same checks as in > Mathematica, besides the checks are to be inserted inside the pattern > matching algorithm. > > It would be very nice to find an equivalent ruleset as Rubi for differential > equations, if there are any. The ODE module basically does work on pattern matching. In fact, classify_ode is probably the biggest user of pattern matching in SymPy library code, and it covers quite a few cases that simply cannot be handled by the current matcher. One problem I've noticed (I'm the main author of classify_ode and most of the ODE module, except for the new stuff from this summer) is that pattern matching basically has to go in two steps: first, you have to canonicalize the expression, and second you have to match it. That's because something like a*x**2 + b*x + c will technically match (x - 2)*(x - 1) or x*(x - 1) + y*x, but the pattern matcher won't notice that unless the expression is first expanded and then collected in x. For this case, it's easy, but for more complicated expressions, you have to basically write custom simplification routines. For instance, say you wanted to match A*exp(B*x**2 + C*x + D) + E, where A, B, C, D, and E are wild expressions not depending on x. y*exp(x)*E + exp(x*(x + 1)) + 7 matches this. To match this, you have to factor out all exponentials, combine them, then expand the argument of the exponential. It would be great if there were a layer on top of the basic structural pattern matcher that currently exists that is aware of what sorts of simplifications need to be done on certain types of expressions in order to maximize mathematically matches. It would also be nice if it were easier to generate patterns like Sum(a_i*diff(f(x), x, i), (i, 0, n)) where n is a fixed number (not a symbol), but not known ahead of time. Aaron Meurer > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/sympy. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
