On Wed, 23 Mar 2022 at 19:42, Aaron Meurer <[email protected]> wrote: > > So I'm starting to wonder if the real fix here isn't so much to "fix > solve" (although solve() should definitely be improved and cleaned > up), but rather to treat solve() as the "interactive only" function > for equation solving, just as simplify() is the "interactive only" > function for simplification.
I don't think we can save solve this way. Even if I wanted to make an "interactive" solve function I wouldn't want it to be so inconsistent. Most of the return types are awkward even for interactive use. Remember the number one thing someone wants to do with the output: substitute it into something. There are so many other problems with solve internally and externally that whichever way you look at it the whole thing needs to be rewritten from scratch. It's impossible to do that while preserving the existing behaviour which is itself impossible to even define (the docstring doesn't even try!). The only actionable takeaway I see from the idea that solve could be considered "interactive only" is that maybe backwards compatibility could be ignored and it could be okay to change the output to be a list of dicts always. I agree with the idea that solve should be implemented as a wrapper around more carefully defined routines but ultimately there still always needs to be a "find explicit solutions to these arbitrary equations if possible" routine and it should be possible to use that in a programmatic way. -- 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/CAHVvXxSM2JOLxthB7qr1sAUHTbVMj5TY18iwn0eAcRJJGPmW-g%40mail.gmail.com.
