More precise

hirnyk — Mon, 25 Oct 2010 17:44:46 Z

Cite from Maple 13 Help: If the fsolve command does not find any solutions, it returns the empty sequence (NULL) or returns unevaluated. This means that there are no solutions, or the fsolve command cannot find any solutions.

See ?fsolve,details .

procedures are good for you

acer — Mon, 25 Oct 2010 19:26:25 Z

You should be able to handle this in one of two ways. You can either test that the result is of a type (that a solution would take), or you can test whether the result is NULL or an unevaluated `fsolve` call.

result := fsolve(...);

if result = NULL or type(result, 'specfunc(anything,fsolve)' then
  no_solution_found := true;
end if;

# or, in the multivariate case,

if not type(result, set(symbol=complex(numeric))) then
  no_solution_found := true;
end if;

Notice that if you are choosing to test whether the result has a given form then the type-check may depend on how you called fsolve. These next two should illustrate that. Note also that you can choose to test whether the numeric result is purely real (ie. of type numeric which would be purely real instead of type complex(numeric) which might have nonzero imaginary part).

> result := fsolve( sin(5*x+3) , {x});
                      {x = 0.02831853072}

> type(result,set(symbol=numeric));
                              true

> result := fsolve( sin(5*x+3) , x);
                         0.02831853072

> type(result,numeric);
                              true

One can see, that it's a bit easier to check whether the `fsolve` attempt failed. If you had success, then how you pick apart the result will depend on how you called fsolve, and perhaps on how many variables were involved or whether the input was a univariate polynomial (in which case multiple solutions may be returned). How you test for that, or how you pick apart the solution, will thus depend on the problem at hand.

Now here is a related digression. You have realized that the result maybe a so-call unevaluated fsolve call, which is a fancy way of describing the situation that fsolve returns something that looks like the original call -- ie. a function call to `fsolve` itself.

If you test this at the top-level, outside of a procedure, then Maple will try once again to evaluate that function call when you inspect it by passing it on to your test. You likely don't want that, since you don't want your code to waste time duplicating a non-fruitful computation.

But if you instead perform the original fsolve call and the subsequent check inside a procedure, where result is a declared local variable, then any unevaluated fsolve function call will not get re-evaluated when your pass it around for the test.

Let's verify that claim, by simply counting how many times the argument to fsolve itself gets called. We'll use a procedure `f` as the thing to be solved-for, but the overall effect is the same even if the thing to be solved-for is an expression.

> restart:

> f:=proc(x)
>   global count;
>   count := count+1;
>   sin(5*x+3)-4;
> end proc:

# First let's do it inside a procedure.
 
> p:=proc(F)
>    global count;
>    local result;
>    result := fsolve(F);
>    printf("total number of f calls done: %a", count);
>    if type(result,numeric) then
>       print("root found");
>    else
>       print("no root found");
>    end if;
>    printf("total number of f calls done: %a", count);
> end proc:

> count := 0:
> p(f);

total number of f calls done: 828
                        "no root found"
total number of f calls done: 828

Notice how the total number of calls to `f` did not increase due to calling `type` against the result

# Now, let's do it at the top-level, outiside if any procedure.

> count := 0:
> result := fsolve(f);
                        result := fsolve(f)

> printf("total number of f calls done: %a", count);

total number of f calls done: 828

> if type(result,numeric) then
>    print("root found");
> else
>    print("no root found");
> end if;

                          "no root found"

> printf("total number of f calls done: %a", count);

total number of f calls done: 1656

Look what's happened. The total count of calls to `f` has doubled, following the `type` check!

The very act of passing the unevaluated fsolve call (assigned to `result`) to `type`() at the top-level causes it to get re-evaluated and thereby duplicates the entire unproductive attempt. But inside the procedure `p`, the variable `result` is a local variable and as such gets only one-level evaluation when passed into `type`(), and so does not cause a re-computation attempt.

When done at the top-level, in the case that the computation failed and returned unevaluated, the mere act of checking it causes the failing computation to be needlessly redone. This can be quite an important distinction when one is concerned with efficiency or when the computation takes a very long time. The very same issue would arise when calling `int` to do symbolic integrals and then passing around an unevaluated `int` call, except that `int` may be safe from this effect due to its having remember tables to store prior results. But the issue can arise elsewhere, since not all Library routines which can return unevaluated have remember tables.

This is one important reason why programming in Maple (ie. writing and using procedures) is important.

acer

catchig fsolve output

zfaigl — Mon, 25 Oct 2010 18:42:12 Z

In that case, I assume this is a good solution to handle that solution has been found by fsolve:

If we have this equation:

eqn1 := f1(t)=f2(t)

Let the output of fsolve be tmp1

tmp1 := fsolve(eqn1, t = 0 .. 1)

to catch that solution has been found:

if `and`(tmp1<>NULL,type(tmp1,float)) then ... end if

What is your opinion?

BR,

Zoltan

A good idea, but...

hirnyk — Mon, 25 Oct 2010 19:04:39 Z

@zfaigl There is a chance that the fsolve command produces a few solutions. For example, see few.mw

RE: Procedures are good to use

zfaigl — Tue, 26 Oct 2010 14:04:30 Z

Thank you Acer! I learnt again something on Maple. Zoltan

MaplePrimes - answers and comments on Question, question on fsolve

More precise

procedures are good for you

catchig fsolve output

A good idea, but...

RE: Procedures are good to use