I am trying a simple recursion but without success. I always get the error of the function not being defined in numeric mode and just the first recursion step in symbolics. What am I doing wrong?

In the meantime I found a workarund but I am not sure if its intended to work that way. I add a line (]) and the I delete one of the two placeholders created (the vertical line will still be there) and then I type the function body in the remaining placeholder.

The failing of the symbolic evaluation with parameter n (even when using the sum symbol) is not a bug, I guess, but just a limitation of the symbolics implemented so far. But the error message should be a different one with symbolic eval, as n not being defined is not an error with symbolics. Guess it would be best if the expressions would simplify to themselves if SMath fails with a simplification (f(n) --> f(n)) without an error.

P.S.: I am not an experienced user of SMath at all, but may I suggest we can get back the right arrow for symbolic evaluations (maybe customizeable as in Mathcad). I know they where there in former SMath versions and still are in the online Live version.
Just noticed that I am not able to type simple parenthesis in the Live-version (annoying), but I don't know if that ever was possible - I seldom used it.

---

Hi rmix22

The line() is the correct way...

g(n) fails because the if/else statement can't evaluate what's the case, so can't return an output (if is numeric even if you set the optimization to symbolic); in the same way, if you do not define n, the sum can't return anything...

Quote

The line() is the correct way...

Thanks for the quick answer. Any logic behind this behaviour? I don't need that line add and delete placeholder with non-recursive functions.

Quote

g(n) fails because the if/else statement can't evaluate what's the case, so can't return an output (if is numeric even if you set the optimization to symbolic); in the same way, if you do not define n, the sum can't return anything...

Agreed, concerning the recursive function, as we don't have a way to tell SMath that we want n to be a positive integer (BTW, the assume modifier in Mathcad as so often doesn't work in this case either). But concerning the sum operator SMath could know the result (as does Mathcad) because there should be an implicit assumption of n being an integer.

Thanks for the reply.

Wrote

P.S.: I am not an experienced user of SMath at all, but may I suggest we can get back the right arrow for symbolic evaluations (maybe customizeable as in Mathcad). I know they where there in former SMath versions and still are in the online Live version.

I'd vote for that as well, yet there seems to be no hope... I am not aware of any reaction to former similar posts, but I may be wrong.

If you replace if() by boolean expressions, then symbolic or numeric evaluation will crash smath. This is possibly due to lack of recursion stopping.

---

Wrote

If you replace if() by boolean expressions, then symbolic or numeric evaluation will crash smath. This is possibly due to lack of recursion stopping.

I can confirm, the function should returns an error due to infinite loops (because - correctly - all functions' terms are evaluated, so you fall in a infinite loop)

Wrote

Any logic behind this behaviour?

Don't know, the recursivity on plain functions doesn't work anymore, but I don't know why and from what happen; the line() function enable this feature.

Wrote

But concerning the sum operator SMath could know the result (as does Mathcad) because there should be an implicit assumption of n being an integer.

I agree, BTW the symbolic engine have several things to improve


best regards,

Davide

Wrote

Wrote

P.S.: I am not an experienced user of SMath at all, but may I suggest we can get back the right arrow for symbolic evaluations (maybe customizeable as in Mathcad). I know they where there in former SMath versions and still are in the online Live version.

I'd vote for that as well, yet there seems to be no hope... I am not aware of any reaction to former similar posts, but I may be wrong.

Thats a pity. It would be very useful to be able to have an optical different appearence of the two methods of evaluation. I am not sure but it would look to me that it should not be that much effort to (re)implement that.

Wrote

If you replace if() by boolean expressions, then symbolic or numeric evaluation will crash smath. This is possibly due to lack of recursion stopping.

I wouldn't had expected that function to work being an infinite recursion. Maybe future versions of SMath will be able to detect an overflow or infinite recursion before the program crashes which of course should not happen.
I could image that your function works if you change the order of the factors in the last product. This would require that SMath had implemented some sort of shortcut evaluation (the second factor would not be evaluated if the first one is already identified as zero). But I just tried and this seems not to be the case.

BTW, thanks for your SMath manual - much appreciated!

Wrote

Wrote

If you replace if() by boolean expressions, then symbolic or numeric evaluation will crash Smath. This is possibly due to lack of recursion stopping.

I can confirm, the function should returns an error due to infinite loops (because - correctly - all functions' terms are evaluated, so you fall in a infinite loop)

I wouldn't had expected that function to work either but as I already wrote in my reply to Martin it could with a slight modification if SMath had implemented shortcut evaluation.

Quote

BTW the symbolic engine have several things to improve

As have Mathcad's symbolics ;-)

While searching the forum for recursion some hours ago I stumbled over a posting where somebody posted an example which crashes SMath and somebody else answered that in a new version (old from todays point of view) this will not be the case anymore. I tried the example and it crashes the current (stable) version of SMath. I tried to find that thread to reference it here, but it looks like searching the forum does not work at the moment. Anybody with some more information what happened to recursion over the time of program development? Obviously an improvement was taken back for some reason.

Regards

EDIT: I found the thread I mentioned above (using the internal search - the custom google search still is broken for me). It looks like infinite recursions did not crash versions 0.89 and 0.90 while they do crash the current version 0.96 (and did with version prior to 0.89).
http://en.smath.info/forum/yaf_postst1085_bad-recursive-function-calling-causes-crash.aspx