A deprecation is possible. Here is a potential docstring addition:
** Automatic detection of undetermined coefficients**
When solving a single equation that is not passed in a list and
is passed with more than 1 variable for which to solve a check is made
to see whether the equation and variables represent a *linear*
system of equations that can determine coefficients on independent
symbols not passed, This behavior will likely be disabled in the
future; to disable it now, use the keyword `coeffs=False`.
>>> solve(Eq(a*x - b, 2*x + 3), (a, b))
{a: 2, b: -3}
>>> solve(Eq(a*x - b, 2*x + 3), (a, b), coeffs=False)
[{b: a*x - 2*x - 3}]
At the end of the deprecation period, the first solution would no longer be
returned and the `coeffs` keyword would enter a deprecation cycle so that
those using it would have time to remove it. Finally, the keyword would be
removed.
The user will be directed to use `solve_undetermined_coeffs` and that
function will be upgraded to handle linear coefficients on potentially
non-polynomial generators on more than one symbol, e.g.
solve_undetermined_coeffs(Eq(a*sin(x) + b*x*y, 3*sin(x) + 4*x*y), (a,b))
solve_undetermined_coeffs(Eq(a*x**2 + b*x*y + c*y**2 + d, 3*x**2+4),
(a,b,c,d))
/c
On Friday, July 1, 2022 at 7:30:45 AM UTC-5 Oscar wrote:
> On Fri, 1 Jul 2022 at 13:01, [email protected] <[email protected]> wrote:
> >
> > +1 for separating out undetermined coefficients.
> > I am sure this will break somebody's code. However, I agree that the
> behavior of solve is so inconsistent that I do not think there is a
> reasonable way of deprecating this. I generally only use solve in an
> interactive environment and as little as possible because of how mysterious
> it is about what choices it is making. I advise my students to avoid using
> it.
>
> To be clear it is possible to make solve much more consistent both in
> terms of type of return values and the solutions it computes if you
> always pass a list of solutions (even for a single equation) and also
> pass the dict=True flag. Then the output is guaranteed to a be a list
> of dicts which is the most useful form because you can use it for
> substitution:
>
> In [21]: eq = x**2 - 1
>
> In [22]: solve([eq], [x], dict=True)
> Out[22]: [{x: -1}, {x: 1}]
>
> In [23]: [s1, s2] = solve([eq], [x], dict=True)
>
> In [24]: eq.subs(s1)
> Out[24]: 0
>
> Internally in solve there are two different codepaths:
>
>
> https://github.com/sympy/sympy/blob/8a5296712e30cc5fc29b6a519797be737da51b38/sympy/solvers/solvers.py#L1118-L1121
>
> The weirdness as referred to in this thread generally lies down the
> bare_f path. Passing a list of equations i.e. [eq] takes the other
> path.
>
> For downstream library usage I would recommend to always give a list
> of equations and always use dict=True.
>
> --
> 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/e0ca8889-4a40-4173-9ce2-d857e8fc9193n%40googlegroups.com.
