On Thu, 4 Mar 2021 at 14:20, JSS95 <[email protected]> wrote: > > I believe that the only disagreement we have here is : given that we > introduced the relation predicate, do we need to have two different classes > or do we need to have one class at the cost of breaking backwards > compatibility?
I think that's right. I wouldn't say that it is a "disagreement" though. I haven't seen compelling arguments for either approach yet. Rather than disagreeing I am asking for a rationale for any change. To me there is a clear rationale for the Equation class because it is not supposed to be a Boolean. That makes it more useful for those situations where you want to pass an equation around to represent something that may or may nor be true but that should still have a clear lhs and rhs. The new Q.eq class you propose here is still a Boolean but just one that does not evaluate automatically. Placing this in the assumptions system is odd though because that's a situation where it really should be fine for the equality to evaluate in the way that Eq already does. > If so, then what about this? > > 1. Eq, Ge, and other variables return relation predicate. No Q.eq. > 2. Eq(x, x) does not return True. But unlike predicates which do not > evaluated by simplification, Eq(x, x).simplify() evaluates to True with > deprecation warning. > 3. After deprecation period is over, Eq(x, x).simplify() no longer evaluates > to True. We need a rationale for changing anything here. I don't think that any deprecation warning should be introduced unless it is for something that will in future become an error. -- Oscar -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxS9koD22eV1uisX%2B3qt%2BJF55rAq%3DFhOZSkbueDuu1305A%40mail.gmail.com.
