Comment #8 on issue 3059 by asmeu...@gmail.com: (x - oo).has(oo) is False; (x - oo).subs(oo, 1) fails
http://code.google.com/p/sympy/issues/detail?id=3059
Special handling in Mul.flatten might not be such a bad thing. After all, we already special case the infinities in that function anyway, so one more line to return the singletonized object for -1*oo shouldn't be too bad. Unless I'm missing something. I guess it would change -I*oo from Mul(NegativeInfinity, I) to Mul(-1, Infinity, I), but I don't really see that as breaking anything.
Regardless, I tried just commenting out the definition of NegativeInfinity and Infinity.__neg__, and adding "S.NegativeInfinity = -S.Infinity" in it's place, but it didn't work, because apparently Mul is not defined at that point. I can't figure out where to put that line so that both Mul and Infinity are defined when it hits it, other than placing somewhere where it clearly doesn't belong (such as after the core import in sympy/__init__.py).
Also, I played with this, and found another problem. S.Infinity is a Number, which means that code (specifically code in Mul.flatten) assumes that the product with any other Number will produce another number. But if -1*oo is a Mul, this is violated, breaking Mul.flatten's logic.
So logically, Infinity should be an AtomicExpr, not Number, if we do this. Does this sound OK to everyone? I think it should be fine, though we may need to recode logic that depends on this (in particular, as_coeff_* will no longer return oo as the coeff). But zoo is not a Number, for example, but an AtomicExpr.
-- You received this message because you are subscribed to the Google Groups "sympy-patches" group. To post to this group, send email to sympy-patches@googlegroups.com. To unsubscribe from this group, send email to sympy-patches+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en.
