Thanks for the writeup here. So it sounds like the problem is that a lot of assumptions handlers are calling out to other functions, which are usually fast but can be slow, such as
- numerical evaluation - root finding - other polynomial functions - you didn't mention it but isprime() would likely be another example This is the sort of thing I mean by saying we need a hierarchy of evaluation from faster but less powerful to slower but more powerful. Currently we have two systems, old and new, which are separated by their syntax and expressibility. But I don't think that same separation needs to be what is done for the power hierarchy. One should be able to do both "fast" or "slow" assumptions evaluations with ask. The old assumptions syntax doesn't allow keywords, so we would have to just pick a good default. I think what we need is an assumptions solver that has this notion built-in to it. The old assumptions solver clearly doesn't. It is able to test the user-defined assumptions before calling _eval handlers, but that's it. It doesn't know how to not call the _eval handlers if the user only wants a fast evaluation, and it also doesn't know how to not go too deep in the evaluation tree in an attempt to get what it wants. ask() does have more "levels" of what it tries, but it also doesn't have any way to control how deep into these levels it goes. satask() has an iterations flag that controls this to some degree, although not completely (iterations tells it how "deep" to go in the expressions, but doesn't control things like calling out to numeric evaluation of isprime()). Generally speaking, we need a more unified notion. Once we do, then we can have rules for the codebase like "automatic evaluation should only use the fastest evaluation", "user calls to ask() would use the most powerful evaluation by default", or "library calls to ask() should use some middle evaluation that balances power and speed". I wonder if SMT solver systems like Z3 expose any notions like this. It would be good to copy something else that is out there if it exists. 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 sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6KfaDgygbqxX6etUUBoHUbZBwdhU1pupzx20PsOGCqRVw%40mail.gmail.com.
