Except for booleans, consider single and system output: If it is a single equation the output depends on whether symbols are given or not:
* list of expressions if a single variable is given (or the expression is univariate and no symbol is given) * if multiple variables are given and the system is solved by linear undetermined coefficients or is split into real and imaginary parts you get a dictionary, otherwise you get a list of tuples of values * a list of dictionaries if no variables are given (since otherwise you wouldn't know for which symbol the solution corresponds) If it is a system of equations (defined as 1 or more equations in an iterable) then the solution is: * a single dictionary if the simplified system was solved as a linear system * if multiple variables are given and the system is solved as a linear system you get a dictionary (and extraneous symbols are ignored), otherwise a list of tuples of values * a list of dictionaries if no variables were specified (or else you wouldn't know for which symbol the solution corresponds) Although the docstring does not lay out the return cases as I have just done, it does try to show the situation under which the different types are returned. (I wrote them and I was mainly the messenger.) Any user that is concerned about the return value has had the option to select `set` or `dict`ionary output for several releases now. There should be no reason that it can't be used reliably in a programmatical way. As has been pointed out, some of the issues arise from `solve` trying to guess what the user might have wanted. This is against the admonition to "refuse the temptation to guess". Others have pointed out the mixing of idioms of "eliminating" vs "solving". /c On Wednesday, March 23, 2022 at 5:39:12 PM UTC-5 Oscar wrote: > 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/8e0c6289-8e46-41e7-b755-5216eb9a2dc9n%40googlegroups.com.
