Skip to main content
25-Diamond I
May 12, 2016
Solved

Problem with recursive function when evaluated symbolically

  • May 12, 2016
  • 5 replies
  • 5646 views

Normally recursive function can be evaluate symbolically without problems, like

But it looks that the symbolics has troubles with the sum - I get the "generic" variable-undefined error at first hand and when I trace, Mathcad moans that "This function refers to itself inconsistently".

As far as I remember this effect was discussed here quite a while ago in the good old collab days, but I was unable to find that thread.

Is there any explanation for this effect and does an elegant workaround exist?

The only workaround I could find was to replace the sum by a self written summation loop, which I don't consider elegant.

Writing a user function sum() in som way could be an option, but would slow down calculations which, when evaluated symbolically, take very long anyway.

Regards

Werner

Best answer by RichardJ

a) an explanation for the effect (otherwise I would tend to call it a bug)

I am inclined to think it's a case that is not accounted for in the parser to the symbolic engine, which might explain the different error messages, and the strange places they trace back to. Luc's example, where it works for b=2 in MC11 but not in MC15, is not necessarily because of the change in symbolic engine because the whole compute engine was rewritten for Mathcad 12. An additional note is that when I was playing around in MC15 I also created an example that threw an error that traced back to "Must be a scalar" in the if statement, but I didn't keep that example.

5 replies

23-Emerald I
May 12, 2016

Does the fact that the program can have more than one answer if a = 1 have any bearing?

(Prime 3.0)

1-Visitor
May 12, 2016

If a = 1 the program will return 1 due to the first line.

I could be misinterpreting what you're trying to show, but I do not see the connection to Werner's function.  Werner's function could be displayed in an Excel table as:

19-Tanzanite
May 12, 2016

Here a simpler function that gives a different error:

I think "pattern match exception" means Mathcad can't understand the syntax. It's not only associated with the symbolic processor, so I assume the parser does not know how to convert the expression to something the symbolic processor might understand.

19-Tanzanite
May 12, 2016

This also gives a pattern match exception, which traces back to the local range definition:

23-Emerald IV
May 12, 2016

This is what Mathcad 11 makes of it:

As you can see, if b=2 a symbolic solution is found (and equal to the numeric solution, fortunately), but for larger values an error is thrown.

Now the error is: "Must be scalar" and traces back to the condition in the if statement.

I haven't been able to solve that, yet.

Luc

Werner_E25-Diamond IAuthor
25-Diamond I
May 12, 2016

Thanks for all the answers so far.

So some strange things are going on - I am still baffled by the pattern match exception Richard posted.

To make ot clear: The example I posted is not the actual function I tried to implement so it may be, that its quite easy to rewrite it into a simple iteration. But thats not what I an looking for.

What I try to find is

a) an explanation for the effect (otherwise I would tend to call it a bug)

b) a better workaround than programming the summation using a loop

In he meantime I am not that sure that this problem was already dicussed in former times.

WE

RichardJ19-TanzaniteAnswer
19-Tanzanite
May 12, 2016

a) an explanation for the effect (otherwise I would tend to call it a bug)

I am inclined to think it's a case that is not accounted for in the parser to the symbolic engine, which might explain the different error messages, and the strange places they trace back to. Luc's example, where it works for b=2 in MC11 but not in MC15, is not necessarily because of the change in symbolic engine because the whole compute engine was rewritten for Mathcad 12. An additional note is that when I was playing around in MC15 I also created an example that threw an error that traced back to "Must be a scalar" in the if statement, but I didn't keep that example.

21-Topaz II
May 14, 2016

FibonacciZahl.jpg

Werner_E25-Diamond IAuthor
25-Diamond I
May 14, 2016

I am sorry, but your "answer" (you just show a picture) does not relate to my question in any way as far as I can see.

It fear that you just looked at my first example and did not read my question and so you misunderstood what that question was all about. Its about the symbolic evaluation of a recursive function which calls itself in a summation expression. Nothing more and nothing less. Its not about recursion in general and sure not about Fibonacci. Fibo was just a quick example to show that recursive functions normally work pretty well with symbolic evaluation which implies that the problem is due to the summation symbol.

Thanks for taking time anyway

WE

21-Topaz II
May 14, 2016

Indeed, mine is not a solution of your problem, it is only a joke ... a digression on the subject ... I have understood well your problem. You should turn to those who designed and wrote the software. My hidden message is that when I meet an impossible problem, or I fix it again, or try to avoid it by finding other ways to solve it.

However, all my respect for your prestige, but in much of the globe, currently, anyone can answer any question in its own way even if off topic. I'm sorry, but it is the free will ....

Regards.

F. M.

23-Emerald IV
May 15, 2016

I'm afraid it can't be solved the way you'd like, because I think the summation operator symbolically produces a row vector here. I've tried many ways to get around that. If you think of any other ways, just let me know and I'll try them.

Success!
Luc

23-Emerald IV
May 15, 2016

OK. I tried it one more time.

Now you get a symbolic result, but it's one less than the desired result. And if you evaluate it numerically, you get one more than the desired result.

Here goes:

Success!
Luc

Werner_E25-Diamond IAuthor
25-Diamond I
May 15, 2016

LucMeekes wrote:

OK. I tried it one more time.

Now you get a symbolic result, but it's one less than the desired result. And if you evaluate it numerically, you get one more than the desired result.

Thats strange, indeed and it does not work in Mathcad 15 the way you show (see screenshot below). The error always traces to "This function refers to itself inconsistently".

It looks to me like Richards answer ("it's a case that is not accounted for in the parser to the symbolic engine") is the correct one.

So we can see it as a bug or a limitation (which should not be there or at least should be documented).

It also seems that reprogramming the sum as I had done is the only workaround so far - apart from turning the whole recursion into an iteration or even in a closed formula, if possible at all.

Thank for all the replies!

Werner

EDIT: Here's the promised screenshot: