On Thu, Apr 1, 2021 at 4:31 PM Oscar Benjamin <oscar.j.benja...@gmail.com> wrote: > > On Thu, 1 Apr 2021 at 20:02, Aaron Meurer <asmeu...@gmail.com> wrote: > > > > On Wed, Mar 31, 2021 at 12:24 AM JSS95 <jeesoo9...@snu.ac.kr> wrote: > > > > > > In SymPy, we have two ways to get the mathematical property of an object > > > : the old assumptions system and the new assumptions system. > > > With old assumptions system, the property is accessed by `.is_[...]` > > > attribute. Here, property of the object is intrinsic. > ... > > > - Basic will be cluttered up with more methods > > > > Indeed. It seems you are proposing to fix the problem of there being > > two different ways to do things by adding a third way > > https://xkcd.com/927/. I'm -1 to adding another syntax for checking > > assumptions. > > > > I've always seen the preferred solution to this problem being to merge > > the two assumptions systems, so that x.is_positive and > > ask(Q.positive(x)) do the same thing. The former would just be a > > convenient shorthand for the cases that it can represent. If you need > > to pass in assumptions in a way that isn't supported by the "old > > assumptions", you can use ask() instead. This has already partly been > > done in that ask() checks the assumptions set of Symbol. The reverse > > is harder because ask() is currently too slow. > > If we have the new assumptions call the old and the old call the new > then we're left with something very circular. We could have infinite > recursion everywhere.
Only if deduction is implemented in a naive way, by recursively calling the top-level assumptions APIs (which it currently unfortunately is in the ask handlers). Deduction should be a completely separate thing, which would be done with all the known facts collected from whatever source. > > > I think we can improve > > the performance of it. One thing we need to do is devise an evaluation > > scheme where queries can be faster but less accurate. That is, a fast > > query might return None when a slower query might return True or > > False. These fast queries would be preferred for places where > > performance matters. > > This is more or less the distinction between the two assumption > systems in how they can be used as I see it. I agree that we can make it so that the current "old assumptions" syntax only does a limited deduction (it has to be limited anyway because it is limited in what it can even represent). This makes sense given its prevalence, that we would want to keep it as one of the faster APIs. > > > Probably a more relevant design question is the problem that the old > > assumptions system stores assumptions on objects, whereas ask() stores > > them as separate predicates. So the question of how is_... calls ask() > > isn't so obvious. Previously the idea for this was global assumptions > > contexts (with the assuming() context manager). I think this is a good > > idea, but passing assumptions through to functions as with Oscar's > > idea may also be more convenient, although it does represent a pretty > > significant API shift in SymPy. > > Yes, but it's a shift in the right direction. > > > Another problem, which also relates to performance, is that we need to > > significantly reduce the use of assumptions in constructors. Automatic > > evaluation should only happen when it can be fast, and checking > > assumptions is antithetical to that. To me, your _eval_Abs above > > should actually be Abs.doit() or Abs._eval_refine(). > > I think Jissoo's proposal is that it would literally become the > implementation of _eval_refine. The fact that it would also be the > implementation of __new__ is just a reflection of the status quo. We > shouldn't get too tied up in removing assumptions-based evaluation at > the same time as trying to make the new assumptions usable. Removing > assumptions based evaluation is much harder. If we want to make a > BasicV2 and reinvent everything from scratch then we can do both. If > we want to find a path of incremental improvement then the proposals > here are one way. I'm not sure if we can separate them, given the performance implications of calling assumptions in constructors. The more the assumptions are doing, the more that will affect any constructor that calls them. > > While the new assumptions system is in some ways better defined it's problem > is: > > 1) It doesn't yet have any substantial capability that improves over > the old assumptions for any significant practical use case. I disagree with this. Even though refine is almost completely useless, the fact that you can do refine(sqrt((x - 1)**2), Q.positive(x - 1)) and it works is a huge boon to people in practice. > 2) It isn't really used anywhere (the cause of this is largely point 1), Just the one refine(sqrt((x - 1)**2), Q.positive(x - 1)) example, which is almost the only thing in refine() currently that actually works, is used. I've seen many instances in stackoverflow and elsewhere where users need to eliminate square roots and refine is one way to do this. > 3) The most useful part for end users is refine but making refine good > would require reimplementing all of the logic that already exists for > evaluation as a bunch of _eval_refine handlers Agreed. > > The proposal here is about avoiding duplicating everything from point > 3. If instead we were to ignore that then a good path forwards would > be to implement inequality handling and make a good refine(Piecewise) > function. That alone would be enough to justify adding an assumptions= > keyword argument to a bunch of APIs and would make it possible to use > the new assumptions internally in a few key places. I'm not sure I follow what you are saying here. Making refine and the assumptions work better on inequalities would also be a huge boon, although orthogonal to the benefits of the sorts of things that currently work in constructors (or at least work in cases simple enough to represent in the old assumptions). Aaron Meurer > > > 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 sympy+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAHVvXxRnmwJ9y-9pOEdgnQ-2HeQ4RkdhAvCs62YdmBY%2B07uOrA%40mail.gmail.com. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6LWdA%2BKnPihmtKK0HKDFkbJXBnvwH3zcsM9n7He7%3DrGZQ%40mail.gmail.com.
