@dstaple You wrote:

The ideal solution would be equivalent to fsolve(...) or evalf(solve(...)) in the case where the number of equations matched the number of unknowns.

So, are you saying that if the solutions from DirectSearch:-SolveEquations were reformatted so that they were in the same format as fsolve solutions, then that would be an acceptable solution to you? If so, a procedure to do that reformatting would be trivial to write.

@dstaple 

Okay, I understand now that you are looking for a finite set of system-satisfying purely numeric assignments to the variables.

You wrote:

It's possible that this would find a solution in some situations where fsolve would fail; it depends if fsolve already tries this technique as one of its internal algorithms, or if it goes immediately for numerical methods.

As the error message that you got indicates, fsolve will always fail when the number of equations differs from the number of unknowns.

@Markiyan Hirnyk 

Of course, a symbolic solution to a system of nonlinear equations is rarely possible. But I think that you are criticizing my solution because it contains complicated RootOf expressions. A solution expressed in terms of RootOf is still a useful solution. It can be numerically evaluated with evalf, and hence it can be plotted. Here is the most complicated RootOf expression from the original system, the solution for y1 in terms of x2, plotted.

S:= [seq(eliminate({eq||(1..3)}, V), V= combinat:-choose({x1,x2,y1,y2}, 3))]:
Y1:= op([3,1,2,2], S);
plot(Y1, x2= 1..5);

Anyway, in this case you can ignore the RootOf solutions and still have a complete set of solutions with one equation relating every pair of variables.

Please post your complete code. I cannot run your code without numeric values for k, l, m, and r.

@tira 

I corrected all your syntax errors---all the ones mentioned by Preben and several others. Also, I made all the integrals numeric. Then I tested a single point, like this:

evalf(u(1., .4));

(You should always check a single point before plotting a complicated function. If there are any free variables left in the answer, then you know that there are still syntax errors.) The result that I got was

Float(undefined) + 0.*I.

(I was surprised by how quick the answer was returned.) This may indicate that at least one of your integrals does not converge. So I changed the starting point for all the integrals from 0 to 1 to avoid singularities. I still got the above answer. So, I guess that there are other singularities.

I would post the corrected worksheet, but I lost it when I stepped on the power switch of my computer, and I don't have time right now to redo it.

Your delta should be Dirac.

What does f[z1] mean? Is f the same as F?

@tira 

I am not an expert on pdsolve(..., numeric). I do know that it is often wrong. However, whenever I've found it wrong, there have been telltale signs. I do not see those signs in this case. If the situation is that changing a single sign causes you to get the solution that you actually expect (from a done-by-hand symbolic solution), then I strongly suspect that there was a sign error made in that done-by-hand solution.

@tira

Are you claiming that the plots produced by pdsolve in your most recently posted worksheet are wrong---that they don't match some exact solution that you have? Please post a worksheet with that exact solution and the corresponding plots.

@tira Okay, I got the worksheet file. Thanks. I ask again What do you need? I see no error in your worksheet.

I suppose that you want a solution with the integer part and the fractional part juxtaposed, i.e., without any intervening symbols. So solutions that use a plus sign are no good, right?

@Markiyan Hirnyk The cfrac prettyprint machinery can be successfully employed like this:

Mixed:= r-> CFRAC([trunc(r), [op(r-trunc(r))]]):
Mixed(17/6);

Note the use of capital letters: CFRAC. Also note that it is necessary to use trunc instead of floor so that negative numbers are handled correctly.

The original number can be retrieved via

numtheory:-cfrac(%);

The InertForm prettyprint machinery can be successfully employed like this:

Mixed:= r-> InertForm:-Display(`%+`(trunc(r), r-trunc(r))):
Mixed(17/6);

I don't think that there's an easy way to retrieve the original from that.

I think that mixed numbers are immensely practical, not "art for art's sake." Who wants to make a recipe with 17/6 cups of flour?

@itsme

Many thanks for the pointer. I was not previously aware that Finance is as powerful as you suggest. Can you show an example of solving and plotting a user-supplied stochastic differential equation? I would find that most instructive.

@lt Your Reply is a completely new Question rather than a followup to the previous Answer. Please post it as a new Question.

@jockoflocko You wrote:

...I thought that every variable declared outside of a procedure could be used in the procedure without declaring it again....

That's mostly true. You can access the value of any variable declared in a scope more global than the procedure without needing to declare it again. But if the variable appears on the left side of an assignment statement, then it needs to be declared global.

@wolfman29 For a real range, the left endpoint can be -infinity and the right endpoint can be infinity. A complex range must be a rectangle (possibly infinite) specified by (lower left corner)..(upper right corner). For example:

Simply real: -infinity..infinity
A finite complex range: -1-I..1+I
The right half plane (real part nonnegative): 0-I*infinity..infinity+I*infinity