How long has the feature been there? Aaron Meurer
On Thu, Jun 30, 2022 at 5:51 PM Chris Smith <[email protected]> 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 <[email protected]> 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 [email protected]. >> > 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 [email protected]. > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6LCZi9R4cSu36GUS4wgprH2ARLp_2ntujbjPtGbvkG%3D-Q%40mail.gmail.com.
