On Fri, 1 Jul 2022 at 13:01, gu...@uwosh.edu <gu...@uwosh.edu> 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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAHVvXxTXL%2Bo3cxcUUFL2TtGdzRpE6xbqmhCZQ3uQuik6vuXRwQ%40mail.gmail.com.
