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+unsubscr...@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/CAKgW%3D6Jj5z0KE0PLcqF04pRJQBKy4BPxsf_V43GPaYBjfAAKZA%40mail.gmail.com.

Reply via email to