SymPy Bot Summary: There were test failures.

@Krastanov: Please fix the test failures.

Test results html report: http://reviews.sympy.org/report/agZzeW1weTNyDAsSBFRhc2sYqIEKDA

Interpreter: /usr/bin/python (2.7.1-final-0)
Architecture: Linux (64-bit)
Cache: yes
Test command: setup.py test
master hash: b085b35
branch hash: d758bc9d839ab02befb5844a005de946ee6780e6

Automatic review by SymPy Bot.

The test still fails.

Implemented functions are apparently not callable, which is a good thing, because the order of the arguments would be arbitrary (at least in terms of this method). But the way that they print does not make this clear.

I did not understand you last post.

In a = implemented_function(......) the a will be a class Function and a(x) will be Expr and finally a(1).evalf() will just call a._imp_(1).

And yes, currently the arguments for the nsolve expression have an arbitrary order, but this is not a problem because they are already applied. I mean that nsolve(x*y*z, x, 0) will return root_nsolve(z,y) or root_nsolve(y,z) and not root_nsolve without the y and z applied.

The workaround for Matrix is done.

SymPy Bot Summary: All tests have passed.

Test results html report: http://reviews.sympy.org/report/agZzeW1weTNyDAsSBFRhc2sY-5AKDA

Interpreter: /usr/bin/python (2.7.1-final-0)
Architecture: Linux (64-bit)
Cache: yes
Test command: setup.py test
master hash: 329f634
branch hash: a4bf8f8c82cd34dbecaf43c91bc1654fee5dd732

Automatic review by SymPy Bot.

Now it is ready for a review.

@asmeurer, can this go in as I would like to use it in plotting examples.

SymPy Bot Summary: There were merge conflicts; could not test the branch.

@Krastanov: Please rebase or merge your branch with master. See the report for a list of the merge conflicts.

Test results html report: http://reviews.sympy.org/report/agZzeW1weTNyDAsSBFRhc2sY1tcPDA

Interpreter: /usr/local/bin/python2.5 (2.5.0-final-0)
Architecture: Darwin (32-bit)
Cache: yes
Test command: setup.py test
master hash: f2e2705
branch hash: a4bf8f8c82cd34dbecaf43c91bc1654fee5dd732

Automatic review by SymPy Bot.

@asmeurer, I am sorry for taking so long to address your remarks on this PR.

You had already reviewed the workaround that I use in order to work with Matrix and list. The need for the workaround has not disappeared.

You asked for an option to enforce the order of the arguments for the generated function. This was added.

Test are running now. If they pass, can this go in?

The most widely used cases (1D problems) work ok. The multidimensional cases work thanks to the workaround.

SymPy Bot Summary: ✳️ All tests have passed.

Test results html report: http://reviews.sympy.org/report/agZzeW1weTNyDAsSBFRhc2sY5Y0YDA

Interpreter: /usr/bin/python (2.7.2-final-0)
Architecture: Linux (64-bit)
Cache: yes
Test command: setup.py test
master hash: 985c21a
branch hash: 6762c90

Automatic review by SymPy Bot.

Hmm... I'm not sure I understand what's going on here. The concept of "symbolic nsolve" is rather obviously self-contradicting and I get the feeling that you're gluing some unrelated functionality onto nsolve().

@ronan, It is possible that my proposition is not idiomatic in sympy,
so I will ask a question before trying to defend the proposal:

if you want for example the function:
a ---> solution of tan(a*x)-x
what should you do in sympy?

Obviously if this PR is accepted, the docstring should be made clearer
(if you did not get it, the new user wont either).

Actually, we can't solve x = tan(a_x), so, a fortiori, we can't define the function. Also, I'm not even sure what function you mean: is "solution of tan(a_x)-x" supposed to be the set of solutions, a particular solution specified somehow, something else?

@Krastanov be careful about user names. @ ronan pinged some other guy. You wanted @rlamy.

@rlamy I think he means strictly in numerical terms (because this is nsolve). So it probably means just one solution, whichever one nsolve finds with the given starting value. @Krastanov correct me if I am wrong.

@rlamy, my example was not the best one. I give a more detailed examples and justification here.

TL;DR @asmeurer is correct, and this will return only the first solution found by nsolve.

Examples why one would want this functionality:

(in some form, not necessarily part of nsolve)

Here is a more canonical example: "solution to x=tanh(a*x) as a function of a" This one is very important for solving some toy models in the physics of phase transitions. For example a user will want to plot the phase diagram for a simple Ising model. To do this he will need to evaluate these solutions many times. Presumably he will be aware of the fact that there are 3 (or 1) solutions to this equation and will set his starting seed accordingly.

Back to the example of "x=tan(a*x)". This again is a classical example from physics. It gives you the characteristics of a wave on a massive spring attached to a mass (or in acoustics it can be a toy model for a flute). If I want to know the frequency as a function of the mass you need to evaluate it.

Why it is natural to have this in nsolve:

Well... Give me a more intuitive way to write this:
plot(nsolve(tanh(a*x)-x, x, 2), (a,0,10), title="Ising model magnetization vs temperature")

Obviously the title is unimportant, but I wanted to give a complete example.

The only way to do this in sympy at the moment is:

f = Function('f')
imp = lambda a : nsolve(tanh(a*x)-x, x, 2)
from sympy.utilities.lambdify import implemented_function
f_imp = implemented_function(f, imp)
plot(f_imp(a), (a,0,10), title="blahblah")

@rlamy, maybe it will be clearer if I say that I "fake" lazy evaluation in python.

@rlamy, You raised the question about "defining what a solution means". By "solution" I mean the output of nsolve for sensible numerical seed. Obviously if the initial guess is not sensible the results will be useless. However in this case nsolve should not have been used to start with.

It seems that what you want is plot(lambda a: nsolve(tanh(a*x) - x, x, 2), (0, 10), title="Title"). I think that it's an issue with plot(), not with nsolve(). Allowing a syntax like plot(callable, (x_min, x_max)) would be more generally useful than what you're trying to do here, and probably less complicated as well.

@rlamy

To me it seems uglier to mix sympy expressions and python expressions. What is the use of a symbolic library if you have to use lambda on each step to fake lazy evaluation. But this discussion is tangential to the issue here. Instead I give you yet another example that is currently impossible/cumbersome:

How do you integrate the curve that I just plotted in the previous example?

In [40]: expr = nsolve(tanh(y*x)-x, x, 2)

In [41]: integrate(expr, (y,0.5,0.6)).evalf()
Out[41]: 0

In [42]: integrate(expr, (y,1.1,1.2)).evalf()
Out[42]: 0.0588406804168056

Disclaimer: the limits for the integral are close because of numerical instability. I suppose that this can be fixed with a better choice of kwargs.

For me it is still very unclear what the issue is. Could you try to clearly state why this should not be part of nsolve? One reason that I could guess is that solve functions should return sets of solutions, so nsolve should return {x} instead of x. But this is just not how nsolve works at the moment. If this is the issue, I agree, but if it is please say it explicitly.

@rlamy btw if you think that plot() should work with lambdas, do you think the same thing about integrate, Derivative, etc.

If this is the case you are pointing to a deficiency in sympify and not in plot.

I think what we need, perhaps, is a Table(expr, (x, xmin, xmax, step))
class which can accept an explicit or (usually) an implicit expr and
then uses all the tricks of the trade to give values for the dependent
variable over the range of independent variable. I think a symbolic
nsolve expression will be of limited use since a given initial guess
for x may be insufficient for obaining a solution (or staying on a
given solution branch) as y changes. The Table could then be plotted,
integrated and differentiated (the latter two being approximations
dependent on the step size).

@smichr, I like your proposition very much (there are minor details on which I disagree, but we can discuss them when we start working on this). Just for reference - see also InterpolatedFunction from Mathematica.

However I believe that here is a deeper issue that sparked my disagreement with @rlamy. nsolve behaves like a mathematical function (returning a scalar) instead of a solver (returning a set). I think this should be fixed.

behaves like a mathematical function (returning a scalar) instead of a solver (returning a set)

What type of set would you return and in what case(s)?

@Krastanov: it's basically the nature of nsolve() that it returns a single solution. In the case of x = tan(a*x), I don't see how it's even possible for it to return the full infinite set of solutions.

The real issue is that you're making nsolve() a lot more complicated by allowing it to return completely different types depending on circumstances. That kind of behaviour is an accident waiting to happen in users' code and is hard to memorise.

@smichr, @rlamy, check Mathematica's documentation for NSolve returning set of solutions.

example:
in simple cases like nsolve(x-1) return {1} instead of 1.
In case there are multiple solutions a smarter nsolve (like in mathematica) just returns them all in a set.
In case there are an infinite number of solutions raise some warning.

@rlamy, nsolve is returning "maximally evaluated expression" (the basic idea behind Mathematica, see reference.wolfram.com/legacy/v1/contents/4.2.7.pdf the second paragraph). I don't see how this is unexpected from a symbolic algebra library.

@rlamy, I filed an issue (more of a feature request). If you are not persuaded by my arguments and if the others agree with you we can just close the request and move the discussion to the issue tracker.

http://code.google.com/p/sympy/issues/detail?id=3259

I still believe that the approach in this PR is the best proposed so far for solving the problem, however it will be counterproductive if we just argue over the semantics.

@rlamy, You have not answered my last question about your view on the possibility to have integrate(lambda ...) and so on. I find the question important.

I agree that this functionality would be useful to have. Whether it should be part of nsolve or some other functionality I don't care. To put an argument forward for "doing things symbolically" as opposed to "just using lambdas", would it be possible to let an implemented function take in symbolic arguments, and remaining unevaluated until a numerical argument (or evalf) is called? In other words, it would just be sugar for creating a custom Function with eval/_eval_evalf that calls nsolve.

@asmeurer. The discussion with @rlamy made me think about something like that. Maybe a lazify decorator that permits a python function called with symbolic arguments to return an instance of Application (or Function if they do get merged together).

It would work something like that:

@lazify(some_info_about_the_args)
def nsolve(...):
    .... the same old nsolve

There are many issues to be ironed out with such approach, especially when we have so many sympy functions that guess, for example, the free symbols.

Also, it should be considered which approach is more idiomatic for sympy. It is a beautiful feature, but lazy evaluation is not part of python.

I am closing this. There is an issue for the subject: http://code.google.com/p/sympy/issues/detail?id=3276