This is considered expected behavior. You can't get limit values just
by substituting in values. You either need to rewrite the expression
so that you do not have an indeterminant, or else use the limit
algorithm.

Using heuristics is also a bad idea. limit() itself used to use a lot
of heuristics (maybe it even still does), and it had a ton of wrong
results.

You might be able to structure your mechanics algorithms so that they
avoid expressions like that. An idea for this particular case is to
never use tan, only sin/cos. I don't know if that generalizes, though.

Aaron Meurer

On Thu, Jul 3, 2014 at 8:05 AM, Jason Moore <moorepa...@gmail.com> wrote:
> 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 
> "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/CAKgW%3D6JOOuOZA_e6gAhoy2Sj%2BJaSi7%3DVMmJSZ0xmaOJ4fjNPWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to