Perhaps we could use an interim keyword `coefficients` which defaults to
True. If an undetermined coefficients case is detected, a warning can be
raised and a message given before returning that solution which says that
if a non-coefficients solution is desired (during deprecation period) the
keyword `coefficients=False` can be used. Once the deprecation period is
over, the `coefficients` keyword and the recognition of undetermined
coefficients can be removed.
/c
On Thursday, June 30, 2022 at 8:44:52 PM UTC-5 Aaron Meurer wrote:
> Ah I missed your "nearly from the beginning" bit. I would say it
> should be deprecated, although if there are other kinds of cleanups
> that can be done with solve, it might make sense to do them all
> together (but this could be a big project).
>
> Aaron Meurer
>
> On Thu, Jun 30, 2022 at 6:39 PM Chris Smith <smi...@gmail.com> wrote:
> >
> > since 2011 (2ff42e6).
> >
> > On Thursday, June 30, 2022 at 7:17:02 PM UTC-5 Aaron Meurer wrote:
> >>
> >> How long has the feature been there?
> >>
> >> Aaron Meurer
> >>
> >> On Thu, Jun 30, 2022 at 5:51 PM Chris Smith <smi...@gmail.com> wrote:
> >> >
> >> > Do you have any feelings about making the change without deprecation?
> >> >
> >> > On Thursday, June 30, 2022 at 6:31:32 PM UTC-5 Aaron Meurer wrote:
> >> >>
> >> >> How does it decide when to take coefficients? I tried this
> >> >>
> >> >> >>> solve(a*cos(x) + b*sin(x), [a, b])
> >> >> [(-b*tan(x), b)]
> >> >>
> >> >> I would expect an undetermined coefficients solution to be [(0, 0)].
> >> >> OTOH, it would need to be careful about this. This is only valid if
> >> >> the terms in question are linearly independent (this can be checked
> by
> >> >> seeing if the Wronskian is nonzero).
> >> >>
> >> >> Personally, I would prefer if solve() were more explicit and did less
> >> >> guessing about what the user wants. The problem with guessing is that
> >> >> if you do know what you want, it becomes very difficult to tell
> >> >> solve() to do that specific thing. It's especially problematic that
> >> >> the actual behavior of solve depends on seemingly insignificant
> things
> >> >> like how the symbols are specified. Just as a simple example
> >> >> (unrelated to undetermined coefficients), say I have an
> >> >> underdetermined system like solve([x + y + z, x - y - z], [x, y, z]).
> >> >> I would expect specifying [x, y, z] to mean that I don't want the
> >> >> solutions to be in terms of any of those variables (even preferring
> an
> >> >> error to that), but I can't figure out how to make it do that.
> >> >>
> >> >> There is a function solve_undetermined_coefficients, although it
> >> >> currently only supports polynomials. Its behavior seems to be more
> >> >> well-specified for problems like this. One can also extract the
> system
> >> >> manually with collect(), although that's a bit advanced for the
> >> >> average user.
> >> >>
> >> >> It would be better for the solvers to follow the Unix philosophy of
> >> >> "each function does one thing and does it well". So there should be
> >> >> one function just for solving a function algebraically, one function
> >> >> for solving a system, one for solving undetermined coefficients, and
> >> >> so on. For a function like simplify(), there is a benefit to the
> "just
> >> >> do something, even if it might not be exactly what the user wants"
> >> >> philosophy. But I don't see the benefit of that for solve(). If you
> >> >> have an equation or system of equations, you want to solve it in a
> >> >> very specific way, and solving it in some other way is almost always
> >> >> unhelpful (or at least that's been my experience).
> >> >>
> >> >> Aaron Meurer
> >> >>
> >> >> On Thu, Jun 30, 2022 at 4:27 PM Chris Smith <smi...@gmail.com>
> wrote:
> >> >> >
> >> >> > Nearly from the beginning, `solve` has recognized the
> `undetermined coefficients` case wherein a single equation is solved for a
> set of symbols which will simultaneously set it equal to zero. This is
> different than the normal use of `solve`, however, and might be considered
> a bug or feature. As an example, consider:
> >> >> >
> >> >> > [in1] solve(a*x + b - (2*x + 4), (a, b)) # solve for a and b
> >> >> > {a: 2, b: 4}
> >> >> > [in2] solve(a*x + b - (2*x + 4), exclude=[x]) # solve for as many
> as possible, but not x
> >> >> > {a: 2, b: 4}
> >> >> > [in3] solve(a*x + b - (2*x + 4), a) # solve for a
> >> >> > [(-b + 2*x + 4)/x]
> >> >> > [in4] solve(a*x + b - (2*x + 4)) # solve for anything and tell me
> what you did
> >> >> > [{a: (-b + 2*x + 4)/x}]
> >> >> >
> >> >> > The "undetermined coefficients" case is returned from inputs 1 and
> 2 while the more usual "solution" is returned from 3 and 4.
> >> >> >
> >> >> > The request for comment is whether this feature should be removed
> from `solve` so a better defined equation set is provided rather than
> building that equation set automatically when this case is detected as
> one-equation-many-symbols.
> >> >> >
> >> >> > To me it feels natural to get the undetermined coefficients
> solution when I ask for many symbols from one equation. If I want sympy to
> pick any variable other than some I would use `exclude=some` (where `some`
> is a list or set of things to ignore). But not everyone feels this way and
> refusing the temptation to guess is important, too.
> >> >> >
> >> >> > Since this behavior is described in the docstring and has been
> present for many years it feels like a regression of this feature to me
> (though to others it feels like a bug fix). If you use this feature and/or
> have comments, please let us know your thoughts on this:
> >> >> >
> >> >> > 1) should it be kept?
> >> >> > 2) if removed, should there be deprecation?
> >> >> >
> >> >> > Thanks,
> >> >> > Chris
> >> >> >
> >> >> > --
> >> >> > 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/b3553af5-0df2-49cb-bfaa-b3c354429864n%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+un...@googlegroups.com.
> >> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/beaefb88-28cb-4661-ae09-a17778bf0bf0n%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+un...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/826aaa9c-19c3-49e9-95ac-70f71cc4a76fn%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/c878be79-eb62-488a-b43e-b337b0c58460n%40googlegroups.com.
