Problem with recursive function when evaluated symbolically

[Werner_E]

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

[Fred_Kohlhepp]

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

(Prime 3.0)

[MJG]

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:

[Werner_E]

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

I don't think so.

I know that the sum is implemented in Mathcad in a (mathematical) wrong way. In Math a sum with an upper limit  lower than the lower limit should return zero. But thats implemented differently in Mathcad (in a way more related to programming).

But this should not be a problem here, because the sum is only evaluated, when a and b are greater than 1. Otherwise the "return 1" statement stops further evaluation.

Nevertheless I also tried using an otherwise statement, but to no avail.

WE

[RichardJ]

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.

[RichardJ]

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

[LucMeekes]

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_E]

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

[RichardJ · Accepted solution]

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.

[LucMeekes]

Some further food for thought:

Luc

[-MFra-]

[Werner_E]

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

[-MFra-]

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.

[Werner_E]

> anyone can answer any question in its own way even if off topic. I'm sorry, but it is the free will ....

Sure, if somebody asks you the way to the railway station you are absolutely free to tell him the time instead. But I hope you understand that this kind of behavior is somewhat irritating and confusing and is therefore considered inappropriate by many people.

I also replied cause I was not sure if I overlooked any hidden message. And you clarified that there was indeed the hidden "if I have a problem, I fix it or work around" message. It seems it's probably my fault that I had not discovered this information on first sight, 'nough said, I guess.

Regards

WE

[-MFra-]

Dear Werner,

it was not really my intention to irritate you, with my simple answer. Rather, your answer, I find it slightly irritating because it seems to come from the depths of the infinite universe ....

Bye

[LucMeekes]

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

[LucMeekes]

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_E]

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: