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. > 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. > 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. 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. 2) It isn't really used anywhere (the cause of this is largely point 1), 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 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. 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.
