On Wed, Mar 23, 2022 at 5:52 PM Chris Smith <smi...@gmail.com> wrote:
>
> 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".
Another problem is how to return solutions that have a parameter,
where the parameter is a new variable. For example, the exp(I*theta)
solution of the abs(z) = 1 example I gave above. This also occurs with
most diophantine equations. At best it could just return the
parameterized solution, and hope the user knows how to extract it. But
even that only really works if the range of the parameter is something
you can represent using the old assumptions (e.g., you could add
Dummy('theta', real=True) but "theta in [0, 2pi)" wouldn't be
representable). Ideally the parameters would be returned separately
somehow, including their range of values as a set.
This was actually one of the original motivations for solveset
(consider solve(sin(x))), but ironically, even though such things are
representable from solveset, extracting the parameter from a set ends
up being harder than it would be if solve() just returned Dummy('n',
integer=True)*pi.
Aaron Meurer
>
> /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 <asme...@gmail.com> 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 sympy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/8e0c6289-8e46-41e7-b755-5216eb9a2dc9n%40googlegroups.com.
--
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%3D6KDgEu%2BsdA5-wpeCBq4CwkhO4%2BJi7qzq85u3Ughbzg_0Q%40mail.gmail.com.
