> The new Q.eq class you propose here is still a Boolean but just one that does not evaluate automatically.
Q.eq is not just something that does not evaluate automatically. Again, the reason why I propose Q.eq(...) is because it can do what Eq(..., evaluate=False) cannot - that is, the function itself being the argument of another object. Known facts such as "x being real number implies x being complex number" is registered in assumptions/ask module as *Implies(Q.real, Q.complex)*. To express "x > y implies both x and y being real number" with this system, we need something like* Implies(Q.gt, AllArgs(Q.real))* which is applied to Tuple(x, y). These boldface objects play the role of composite function, which requires boolean functions as objects. We cannot do Implies(Gt, AllArgs(Q.real)) because Gt is a type and thus cannot be the argument of Implies(). > 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. Okay, I agree. Then I suggest making Q.eq completely internal to assumptions module and letting Eq be converted to Q.eq whenever it is applied to ask() or refine(). No replacement of Eq with Q.eq, and Q.eq will not be exposed to the users. Jisoo Song 2021년 3월 6일 토요일 오전 9시 56분 9초 UTC+9에 Oscar님이 작성: > 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/8dfc580d-60ef-49f7-82e1-c1bd0e60dd2cn%40googlegroups.com.
