Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backtracking and revealing default assumptions #18882

Open
sylee957 opened this issue Mar 16, 2020 · 7 comments
Open

Backtracking and revealing default assumptions #18882

sylee957 opened this issue Mar 16, 2020 · 7 comments

Comments

@sylee957
Copy link
Member

I see there are some problems of the new assumption system that it is not able to resolve some facts inferred from the default assumption associated with the symbol.
I think that the the old assumptions system could solve because it has some backtracking.

For example, if the new assumptions system backtracks the conditions of Q.invertible and reveals some assumptions then the problem like below should be solved.

>>> from sympy import *
>>> from sympy.matrices.expressions.fourier import DFT, IDFT

>>> ask(Q.unitary(DFT(n)))
True
>>> ask(Q.invertible(DFT(n)))

>>> ask(Q.invertible(DFT(n)), Q.unitary(DFT(n)))
True
@asmeurer
Copy link
Member

This sort of problem is solved by satask.

The challenge with doing this with the old handler system is avoiding expensive evaluation. In the worst case you could end up evaluating every possible handler for an object.

@sylee957
Copy link
Member Author

I see things like Identity = staticmethod(CommonHandler.AlwaysTrue) are duplicated all over the different handlers to achieve same thing.
In my opinion, I think that the handler classes should be able to distribute them automatically in creation.

@oscarbenjamin
Copy link
Contributor

The challenge with doing this with the old handler system is avoiding expensive evaluation. In the worst case you could end up evaluating every possible handler for an object.

Where it goes wrong is that in some cases the handlers try to do too much. It's okay for them to just return None some of the time and more important for them to be fast.

@sylee957
Copy link
Member Author

What I mean is that would it be worth bounding the facts derived from CommonHandler.AlwaysTrue to the classes? This would still be cheaper

@Arpan612
Copy link
Contributor

@sylee957 Sir, I have tested the code snippet you shared and I agree with the problem you have raised. Could you tell me how can we proceed with solving this problem? And do you expect a PR for this issue? If yes, I would like to work on it.

@asmeurer
Copy link
Member

@Arpan612 you can try fixing it. You should be careful about potential performance issues, as I mentioned. If you do fix it, a PR is useful, even if it's just a work in progress.

@Arpan612
Copy link
Contributor

@asmeurer Understood sir. Could you please give me some insights on how to proceed with the problem?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants