On Wed, Mar 23, 2022 at 4:39 PM Oscar Benjamin
<[email protected]> wrote:
>
> On Wed, 23 Mar 2022 at 19:42, Aaron Meurer <[email protected]> wrote:
> >
> > So I'm starting to wonder if the real fix here isn't so much to "fix
> > solve" (although solve() should definitely be improved and cleaned
> > up), but rather to treat solve() as the "interactive only" function
> > for equation solving, just as simplify() is the "interactive only"
> > function for simplification.
>
> I don't think we can save solve this way. Even if I wanted to make an
> "interactive" solve function I wouldn't want it to be so inconsistent.
> Most of the return types are awkward even for interactive use.
> Remember the number one thing someone wants to do with the output:
> substitute it into something.
>
> There are so many other problems with solve internally and externally
> that whichever way you look at it the whole thing needs to be
> rewritten from scratch. It's impossible to do that while preserving
> the existing behaviour which is itself impossible to even define (the
> docstring doesn't even try!).
>
> The only actionable takeaway I see from the idea that solve could be
> considered "interactive only" is that maybe backwards compatibility
> could be ignored and it could be okay to change the output to be a
> list of dicts always.
>
> I agree with the idea that solve should be implemented as a wrapper
> around more carefully defined routines but ultimately there still
> always needs to be a "find explicit solutions to these arbitrary
> equations if possible" routine and it should be possible to use that
> in a programmatic way.
Yes, it's true that there are still a lot of problems with solve().
But the point is that if you are going to go for a "one function"
approach, the best you can hope for is "you get what you get". There
aren't a dozen flags to simplify() that let you tweak what it does
here and what it does there (and in fact I see we should probably
fight this temptation. There's already "inverse" and "doit" flags,
which IMO shouldn't be there). If you use simplify(), and you don't
like what it does, you should instead use specific simplification
functions. Those functions each work in very specialized ways and do
let you precisely control what they do.
Similarly, if we want a single solve() function that handles solving a
single equation, systems of equations, overdetermined and
underdetermined equations (and systems), inequalities, diophantine
equations, equations with symbolic constants, solutions with
parameters, restricting solutions with assumptions, elimination, etc.
all at once, then I think it's reasonable to just let it do whatever
it does. If you don't like what operation it chose to do or how it
chose to represent the answer, then you should instead call the
specific function that does exactly what you want. That's a much
better API than trying to precisely control all these things at once
with keyword arguments, and trying to unify all those very different
things into a single return type.
For example, in my example above, a systems of inequalities solver
would treat [x**2 - 2, x > 1] as a system of inequalities (or error
because the first term is not an inequality). A single equation solver
would treat it as an equation with an assumptions restriction. Both
are valid things but importantly they are distinct things.
Another example is solving the equation |z| = 1 (abs(x) - 1), where z
is a complex number. Do you want re(z)**2 + im(z)**2 = 1? Or do you
want something like z = exp(I*theta), where theta is a new parameter
created by the solver (with "theta in [0, 2*pi)" specified somehow)?
Or do you want the set {x + I*y | x**2 + y**2 = 1}? Or something else?
All are legitimate things that you might want. And only one of them (z
= exp(I*theta)) actually makes sense with subs(), so I'm not even sure
if we can really say "the output of solve() should be passable to
subs()". Inequality solutions also aren't generally meaningful as
subs() inputs either.
Aaron Meurer
>
> --
> 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/CAHVvXxSM2JOLxthB7qr1sAUHTbVMj5TY18iwn0eAcRJJGPmW-g%40mail.gmail.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%3D6LP4FgBFC6c18fa3T%3D-Y_9U29pE%3DZWhVp3p5VhNQTqHig%40mail.gmail.com.
