Multiple subs in Succession or Iterable inside subs in different orders would fail in critical cases involving 0/oo

[anutosh491]

I discovered this while dealing with issue #17528, which I guess could be easily solved once we can correct this .
Multiple subs in Succession or Iterable inside subs in different orders would fail in critical cases like Division/Multiplication by 0/oo
See following examples

from sympy import *
n, m=symbols('n m')
a, b=symbols('a b')
>>> binomial( n, m).subs([( m, 0), ( n, -1 )]) # Correct answer
1
>>> binomial(n, m).subs([(n, -1), (m, 0)])
zoo
>>> cos(m/n).subs(m, 0).subs(n, 0)
1
>>> cos(m/n).subs(n, 0).subs(m, 0)
nan
>>> (sin(m)*csc(n)).subs(m,0).subs(n, 0)
0
>>> (sin(m)*csc(n)).subs(n,0).subs(m, 0)
nan
>>> (log(b/a)).subs(a, 0).subs(b, 0)
nan
>>> (log(b/a)).subs(b, 0).subs(a, 0) 
zoo

I could imagine how sympy conveniently substitutes the values for the first argument , simplifies it and then substitutes the second value in the new expression . I did a shallow read through the code and currently didn't find any code patch to catch these cases leading to wrong answers mathematically .

[anutosh491]

I'll try to approach this sometime soon . Any suggestions/ Thoughts are welcome !!!

[ThePauliPrinciple]

I think the issue here is that 0/n simply returns S.Zero even when 0/n could be S.NaN for some values of n.
Even evaluate=False in the subs method seems to not supress this

[oscarbenjamin]

There are definitely old issues about this. See e.g. #17224 (comment) and all of the other issues linked from there.