Some of you may have seen Sergey started a pull request to remove uses of the new assumptions in the code, because it's confusing to users who set the old assumptions and it doesn't work.
He asked me there How the random mix of old and new assumptions can look for you as this > transition (or a step in this direction, whatever)? I think - this only can > surprise our users. And that's a bad idea to do so, esp. in the core > modules (e.g., the sets module). I wrote up a response there, but then I realized that it would be better to discuss this on the mailing list, so I am posting it here instead. You make a good point. However, if you are going to spend time on this, it would be better spent improving the new assumptions (and let's finally merge my branch as a start to this), or merging the two. I still maintain that this pull request is a step backwards. With these changes, the new assumptions aren't used at all, meaning they are tested much less, and more importantly, there is no more motivation to improve them. The old assumptions syntax isn't going away, so why don't we focus on making it so that the new assumptions can read the old assumptions. This is what @mrocklin and I attempted to do last summer ( https://github.com/sympy/sympy/pull/2210). It didn't work, because we tried to do a two-way merge of the assumptions, i.e., so that both `x.is_integer` and `ask(Q.Integer(x))` were always identical (the logic I used was https://github.com/sympy/sympy/pull/2210/files#r5463892, which required both assumptions to be the same). Maybe an easier approach would be along the lines of what I have done at #2508. Have ask call a bunch of things, in order, until it gets an answer. In my branch, `ask` calls the current new assumptions, and then my satask. We could make it so that ask first calls the old assumptions, then the new assumptions. Furthermore, the new assumptions should gain trivial handlers for Symbols to so that `ask(Q.real(Symbol('x', real=True)))` is True. The first step though will be to go through all the assumptions and make sure they are identical in all systems. This is a good opportunity to clean up some of the contradictory or unexpected assumptions, so it should involve some community input. So I would do it on the mailing list. So I what I would recommend doing: - [ ] Merge my branch #2508. We can maybe wait until after the release to do this so it is minimally disruptive, but this is important, as it will be much easier to add new facts to the new assumptions with satask (and I also want people to start thinking about how to improve the speed of it). - [ ] Go through all the assumptions facts and make a note of what is different, and also what is confusing. A lot of this is already written down in various places (https://github.com/sympy/sympy/issues/5976, https://github.com/sympy/sympy/pull/2538, probably some of the issues mentioned in https://github.com/sympy/sympy/issues/6730, https://github.com/sympy/sympy/pull/2508/files#diff-e0f95401c86d07d90903363122990de0R172, https://github.com/sympy/sympy/wiki/assumptions_handlers), but we should gather them all down in one place. I think the main thing will be how we handle infinity. - [ ] Discuss with the community on the mailing list how we should handle the differences, until we come to a consensus. - [ ] Make the new assumptions call the old assumptions first. Also make the handlers access the old assumptions, so that everything sees `Symbol('x', real=True)` as real. This will be the hard part, and lead to lots of test failures. It might be worth trying this first, to really see what facts are different in the two systems. Note that absent from my plan is making `x.is_real` call the new assumptions. This is what I tried at #2210, and it failed, because it requires everything to work perfectly, and there are so many places that the assumptions are used that it's too much work to get it all in one go. We should get the above working first before we consider this. I don't think there's a big issue with this, because already `ask(Q.real(x))` and `x.is_real` are different. My proposal is to have the first call the second but not the other way around. Aaron Meurer -- 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%3D6JGa_hpe8FFNqht2dAG9-YpfO%2BS3Dx6wfoz_-tfF6i9jg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
