Thanks for pointing these out. I'm a bit slow here because of exams.
> > You should also mention my approach from > https://github.com/sympy/sympy/pull/7925 > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fsympy%2Fsympy%2Fpull%2F7925&sa=D&sntz=1&usg=AFQjCNFpZ0233saatT70oPwkvd7Mjp_I3Q> > to > make the new assumptions > read the old assumptions (add handlers). Also, technically, > > https://github.com/sympy/sympy/pull/2508/files#diff-e0f95401c86d07d90903363122990de0R227 > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fsympy%2Fsympy%2Fpull%2F2508%2Ffiles%23diff-e0f95401c86d07d90903363122990de0R227&sa=D&sntz=1&usg=AFQjCNG6uAAtlAiPZ9UQEWHxXJa868X4Zg> > > is a way of doing this as well. I'm undecided on which of these > (including adding to global assumptions) is the best. If you have a > preference, you should argue in the application why you think it's the > best one. Seems like a good plan. I've to say that, I also like this( https://github.com/sympy/sympy/pull/7926 <https://github.com/sympy/sympy/pull/7926>) approach. But it has a blocking issue <https://github.com/sympy/sympy/issues/8825> of weakref issue in the cache. I'm adding my views on these in my proposal. In the execution > > section, can you give your impression of how > long/hard each item would be (or maybe the timeline is the appropriate > place to do this). I though of discussing this with you before writing it. Anyway, I'll write it according to me. We can always alter it later. > What is the difference between "Making API of old assumptions call new > assumptions internally. The target would be to achieve minimum ripple > effect throughout the codebase as the changes are made." and "Once the > new assumption is ready to handle things, start modifying the codebase > so that expr.is_* syntax calls the new assumptions."? As I've been maintaining two copies of my proposal, this one got duplicated while syncing. Sorry about that. I'll remove one of them. > Regarding the last bullet point, what exactly would the find and replace > be? Replacing the use of old assumptions with the new one. Sudhanshu Mishra On Tue, Mar 24, 2015 at 9:43 PM, Aaron Meurer <[email protected]> wrote: > You should also mention my approach from > https://github.com/sympy/sympy/pull/7925 to make the new assumptions > read the old assumptions (add handlers). Also, technically, > > https://github.com/sympy/sympy/pull/2508/files#diff-e0f95401c86d07d90903363122990de0R227 > is a way of doing this as well. I'm undecided on which of these > (including adding to global assumptions) is the best. If you have a > preference, you should argue in the application why you think it's the > best one. > > In the execution section, can you give your impression of how > long/hard each item would be (or maybe the timeline is the appropriate > place to do this). > > What is the difference between "Making API of old assumptions call new > assumptions internally. The target would be to achieve minimum ripple > effect throughout the codebase as the changes are made." and "Once the > new assumption is ready to handle things, start modifying the codebase > so that expr.is_* syntax calls the new assumptions."? > > Regarding the last bullet point, what exactly would the find and replace > be? > > Aaron Meurer > > > On Mon, Mar 23, 2015 at 7:52 PM, Sudhanshu Mishra <[email protected]> > wrote: > > I've updated the wiki. (Still far from complete) > > > > Please provide feedback on the matter so far. > > > > Places to look at: > > > > * The Project > > * Execution > > > > > > Sudhanshu Mishra > > > > On Sun, Mar 22, 2015 at 3:10 PM, Joachim Durchholz <[email protected]> > wrote: > >> > >> Am 22.03.2015 um 01:04 schrieb Aaron Meurer: > >>> > >>> On Sat, Mar 21, 2015 at 2:57 PM, Joachim Durchholz <[email protected]> > >>> wrote: > >>>> > >>>> Am 21.03.2015 um 19:54 schrieb Aaron Meurer: > >>>>>> > >>>>>> > >>>>>> I do not think the new assumptions should call the old assumptions. > >>>>>> The > >>>>>> new > >>>>>> assumptions work by manipulating data structures, not by executing > >>>>>> code. > >>>>> > >>>>> > >>>>> They do execute code. See sympy.assumptions.handlers. > >>>> > >>>> > >>>> > >>>> Oh. I've been thinking that that was part of the old assumptions > system. > >>>> But what data is the SAT solver working with, then? > >>> > >>> > >>> Currently, the known_facts > >>> > >>> ( > https://github.com/sympy/sympy/blob/5507c86e70f816f95f87b868615502a44cac5853/sympy/assumptions/ask.py#L329-L377 > ). > >>> In my branch, everything in that file. The known_facts are what I > >>> like to call the "free" facts, in that they can be written down > >>> completely free of the expression they apply to. For instance, > >>> Implies(Q.positive, Q.real). Facts that depend on the kind of > >>> expression they apply to (like, if all terms in an Add are positive, > >>> then the whole expression is positive), aren't expressible > >>> symbolically in the current new assumptions (but they are in 2508). > >> > >> > >> Oh, I see. > >> > >> I'd want go full length towards making all rules into data structures, > no > >> code execution at all (except for generic code to apply rules, > obviously). > >> I can't even give a hard reason for that, except that I know from > >> experience that data is far easier to analyze and do something new and > >> initially unexpected than code where this is essentially impossible. > Also, > >> all solvers that I know work that way. > >> > >> I don't know whether that would be a wise approach for SymPy, or the > right > >> thing to do right now. > >> I'm slightly worried that we might want to go full length to data-based > >> solving after we get the SAT solver, and then have *three* solvers to > deal > >> with (because the old assumptions system won't die that quickly), so I > still > >> see a small advantage to going that direction right now. > >> Downside of "right now" would be "who's going to do it" and "that's > going > >> to be even more work"... so I don't know enough to have a real position > >> about what's the best way forward. > >> > >> -- > >> 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 post to this group, send email to [email protected]. > >> Visit this group at http://groups.google.com/group/sympy. > >> To view this discussion on the web visit > >> > https://groups.google.com/d/msgid/sympy/550E8E1E.3060701%40durchholz.org. > >> > >> For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > 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 post to this group, send email to [email protected]. > > Visit this group at http://groups.google.com/group/sympy. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/sympy/CAFW_KCS-B%3D2_bs%2BKJakG3fBucmPVB%2BsFfyYffF8G-RfWvndy%2Bg%40mail.gmail.com > . > > > > For more options, visit https://groups.google.com/d/optout. > > -- > 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 post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/sympy. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAKgW%3D6LRH3j2ofpbg_PvH0Qf0qoRKJdebk2mL0%2BXEjj5x5vMfg%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -- 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 post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAFW_KCRYCx379a3YW82QyJF8gEMnKgfABSVEuiGi3izj%3Dx9ELQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
