Is there an example of when a parameter other than an integer would be
necessary?
/c
On Thursday, March 24, 2022 at 2:21:07 PM UTC-5 Aaron Meurer wrote:
> 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+un...@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/7bd9a9e2-d101-4a91-ae46-8f1a994b1621n%40googlegroups.com.
