Also, >>> sin(a)/tan(a).subs(a, 0) nan >>> simplify(sin(a)/tan(a)).subs(a, 0) 1
needs to be solved for SymPy in general I believe. That seems like a bug on face value. But I guess could be expected behavior...? Not sure. Would ensuring that numerators get subbed before denominators solve that? Or would the limit as a goes to zero be the only way to get the correct answer? Jason moorepants.info +01 530-601-9791 On Thu, Jul 3, 2014 at 9:00 AM, Jason Moore <moorepa...@gmail.com> wrote: > Yeah, it looks good. I've totally been needing this for some work I'm doing > too. The fact that mechanics expressions are a small subset of sympy > expressions is a good reason to optimize stuff like this. > > In the docstring 3.) trig_funcs aren't the only type of functions. I think > you will need to assume that any function (standard sympy ones or custom > funcs) can be present in expressions. Just something to keep in mind. > > > Jason > moorepants.info > +01 530-601-9791 > > > On Wed, Jul 2, 2014 at 11:55 PM, Aaron Meurer <asmeu...@gmail.com> wrote: >> >> I think it looks good. You can probably can probably do better by >> creating a generator comprehension rather than creating and indexing >> into a list (and it's also more pythonic). crawl() is a pretty common >> pattern. I'm sure you could find an existing version in the SymPy code >> already. >> >> Also, at line 54, you don't need to assign to val. Just return >> sub_dict[expr]. >> >> At line 56, I think what you really want is "if not expr.args". There >> are more types of expressions without args than just Symbol and >> Number. >> >> The important thing is to avoid walking the expression tree multiple >> times. Ideally, you would walk it only once. I think you are here. >> >> Aaron Meurer >> >> On Wed, Jul 2, 2014 at 9:10 PM, James Crist <crist...@umn.edu> wrote: >> > I wrote this up today. In physics.mechanics we often have to sub symbols >> > for >> > values (or a smaller subset of symbols, i.e. the "operating point"). For >> > the >> > huge expressions generated, `subs` is extremely slow. Also, it subs >> > inside >> > derivatives, which is not ideal (we are currently using a hacky >> > work-around). It also seems to be overkill for what's needed. More >> > details >> > are in the docstring of the attached gist. >> > >> > https://gist.github.com/jcrist/8ce1a79dfe0b42723550 >> > >> > I'd like some serious code design review of this. Is what I'm doing >> > (direct >> > naive replacement) bad? Is there a better way, that doesn't sacrifice >> > speed? >> > Note that for expressions of this size, xreplace, replace, and subs all >> > perform equally poorly. >> > >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups >> > "PyDy" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> > an >> > email to pydy+unsubscr...@googlegroups.com. >> > To post to this group, send email to p...@googlegroups.com. >> > Visit this group at http://groups.google.com/group/pydy. >> > For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "PyDy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to pydy+unsubscr...@googlegroups.com. >> To post to this group, send email to p...@googlegroups.com. >> Visit this group at http://groups.google.com/group/pydy. >> For more options, visit https://groups.google.com/d/optout. > > -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAP7f1AgWkrsU4S2YfwjTzqCkxjoypv40sn6rR9QT_-_oby2-ug%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
