On Thu, 1 Apr 2021 at 23:54, Aaron Meurer <[email protected]> wrote: > > On Thu, Apr 1, 2021 at 4:31 PM Oscar Benjamin > <[email protected]> wrote: > > > > On Thu, 1 Apr 2021 at 20:02, Aaron Meurer <[email protected]> wrote: > > > > 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.
Collecting "all known facts" can be very expensive. The advantage of recursive calling is that we only collect "all needed facts". > > > 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. Currently assumptions are one of many things that can be slow in constructors. There are others e.g. sorting args, computing simplification etc. In the longer term I do wonder if BasicV2 is the way to go. In the meantime it would be good to make the new assumptions used and usable and being able to patch their capabilities into evaluation would make a huge difference if it boosts the capabilities of refine. > > While the new assumptions system is in some ways better defined it's > > problem is: > > 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. I mean that the new assumptions aren't used anywhere in the sympy codebase. There would be more of an incentive to do so if they had more generically useful capabilities. Your example makes sense for interactive use but not as part of a programmatica API. > > 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). What I mean is that just being able to do something like expr = Piecewise((x, abs(x) < 1), (y, True)) expr = refine(expr, (0 < x) & (x < 1)) would be really useful and would make it useful to have an assumptions argument to integrate or other functions. That is orthogonal to the discussion here but it would make the system usable in practice. 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/CAHVvXxQ8aY3dVZLdvf0r1o8O4%3DoP46_s_gSv2mVwq7vqfkS9Qw%40mail.gmail.com.
