On Mon, 15 Mar 2021 at 08:54, Sayandip Halder <[email protected]> wrote: > > >> I have recently made significant performance improvements in linsolve. >> It would be good to make more use of linsolve in the other solvers. > > Do you mean this PR?
https://github.com/sympy/sympy/pull/20780 Yes, and the ones it references. >> 4. linsolve/nonlinsolve are reasonable but not feature complete and >> also have an awkward return type > > > I am not sure what you mean by awkward return type. The FiniteSet and > ImageSet returned by linsolve() and nonlinsolve() respectively > are the same as the return type of solveset(). No, solveset returns a proper set that you can use in set operations etc. With linsolve you get either: a) empty set b) a FiniteSet containing one tuple representing the unique solution c) A FiniteSet with a tuple that has the unknowns in as free symbols The last case c) is not a proper set: In [1]: linsolve([x + y], [x, y]) Out[1]: {(-y, y)} It should be something like: In [2]: ImageSet(Lambda(y, (-y, y)), Complexes) Out[2]: {(-y, y) │ y ∊ ℂ} I'm not sure that users actually want an ImageSet like this but the point is that it means the return value is not a proper set. There is no value in returning a Set if it can not actually be used correctly in intersections etc. With that in mind actually the FiniteSet is quite awkward because you can't index into it like you can with the list returned by solve. It only ever has one element so it would be better just to return the tuple instead of wrapping it awkwardly in a FiniteSet. There is the same problem with nonlinsolve for positive dimensional solution sets: In [3]: nonlinsolve([x + y], [x, y]) Out[3]: {(-y, y)} Again that's not a proper Set. With nonlinsolve it gets worse: In [5]: nonlinsolve([sin(y)], [x, y]) Out[5]: {(x, {2⋅n⋅π + π │ n ∊ ℤ}), (x, {2⋅n⋅π │ n ∊ ℤ})} This is a FiniteSet containing two Tuples of two elements one of which is an Expr and the other is an ImageSet. There are so many things jumbled up in there but again it is not a proper Set which would be: In [6]: ImageSet(Lambda((x, n), (x, (2*n + 1)*pi)), Complexes, Integers) Out[6]: {(x, π⋅(2⋅n + 1)) │ x ∊ ℂ, n ∊ ℤ} Again I'm not sure if that is what users really want but since the output from nonlinsolve does not represent an actual Set it can't be used as a Set. Worse it is mixing up Expr and Set in the same Tuple which just looks like gibberish to me. Mixing up Expr and Set also breaks nonlinsolve's own internal logic: In [7]: nonlinsolve([x + y, sin(y)], [x, y]) sympy/core/operations.py:64: SymPyDeprecationWarning: Add/Mul with non-Expr args has been deprecated since SymPy 1.7. Use Expr args instead. See https://github.com/sympy/sympy/issues/19445 for more info. SymPyDeprecationWarning( --------------------------------------------------------------------------- TypeError: unsupported operand type(s) for /: 'ImageSet' and 'One' I really think that we need to go back to the drawing board as far as solver return types are concerned. None of them can handle conditionally existent solutions and none of them has a satisfactory way of handling infinite solution sets. Only solveset uses sets in a way that is actually consistent but its return value is actually really awkward to use. https://github.com/sympy/sympy/issues/16861 > As for feature complete, what more features do you think should be added to > them? > #19038, #17566, #16861, PR 12424 are the most important issues and PRs that > should be tackled at first, in my opinion. Do you have any more in mind that > should be added to this list? I think that the biggest problem is just how inefficient many of these solve functions are. They should be much faster. Work is definitely needed on polynomial systems as they are particularly slow. >> None of these functions really replaces any other so we just have a >> range of different overlapping implementations and inconstent APIs. It >> would be good to unify as much as possible of the implementations and >> make the APIs consistent and more useful. > > > I hope to take up this as my GSOC project. Will there be any mentor for this? There are people who could mentor this. > >> The most immediate thing that is needed is good documentation that >> explains why there are different solvers and when you might want to >> use each of them and discusses the caveats and limitations etc. > > > Agreed. We should start with solve(), which is the most lacking when it comes > to documentation. Actually what I mean is that we need a page called "How to solve equations in sympy" that explains all the possible solvers and when you might use one or when you would use another. It should discuss in detail what the different approaches are for and what the strengths and weaknesses of each are. 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/CAHVvXxRH8PAupon-SQ%2BP99GE6q79ZcTYE%2BdoLi_qMR%3DE8d_2gA%40mail.gmail.com.
