This is an example of the code that indicates 2 possible bugs in Smath or in the plugins.
The idea of the program is to sort roots of polinomial so, that standard algotithm of
calculating polinomial coefficients produces numerically correct result.
The implementation is very similar to Matlab leja(x) function.

What was found:
1) Vector Summ "summ(1)" operator doesn't work
if another function(x) is used as an argument, despite of the GetType(function(x)) displays
correct type "matrix".

2) I often put 2 or 3 operators in a "matrix row" like ( c[n]:=0 c[1]:=1 ) instead of using "line".
Usually it works fine (Old Mathcad habit).
But in this example matrix of 3 operators produces wrong result with no error indication.
The problem is that "matrix" implementation
(t:=a[k][1]) a[k][1]:=a[k][ii] a[k][ii]:=t) - doesn't work,
but standatd implementation with "line" works.
Am I using some undocumented features ?

---

f_poly.sm (21,99 KiB) descargado 1401 vez(es).

Wrote

I often put 2 or 3 operators in a "matrix row" like ( c[n]:=0 c[1]:=1 ) instead of using "line".
Usually it works fine (Old Mathcad habit).
But in this example matrix of 3 operators produces wrong result with no error indication.
The problem is that "matrix" implementation
(t:=a[k][1]) a[k][1]:=a[k][ii] a[k][ii]:=t) - doesn't work,
but standatd implementation with "line" works.
Am I using some undocumented features ?

As I understand, the expressions in a row matrix are executed from right to left. Is that consistent with your observations?

Take care about known bugs:
- linear indexing vs transposed matrics
- linear indexing and the assignments

Citar

I often put 2 or 3 operators in a "matrix row" like ( c[n]:=0 c[1]:=1 ) instead of using "line"
[...]
Am I using some undocumented features ?

Yes, even if I remember that someone else has used it in the past...

Citar

As I understand, the expressions in a row matrix are executed from right to left.

Correct, this comes from the Reverse Polish notation used at low-level...

Yes, Martin, Smath executes expressions in a "matrix row" in right->left order, opposite to Mathcad and common sense.
I've just checked it. Yet another "featurebug" :d

Citar

Correct, this comes from the Reverse Polish notation used at low-level...

If you think it is correct, than use LISP instead of Smath.
The only point of Smath vs LISP is a good user interface.

Wrote

If you think it is correct, than use LISP instead of Smath.

What I meant to say is that the Martin's explaination is correct; about the SMath behavior I think it's "not the best" if you use the features that you have used or some others similar.

I think that the right to left parsing should be better as general solution, but I don't know if the actual implementation was done to fit something important in the SMath code or if is just a bug (the RPN sometimes can causes confusion writing the algorithms, and a bug is easier to find in undocumented features such as those you have used).


best regards,

Davide

Summ(1) bug/feature update.
Vector/matrix summ doesn't work if it's argument equal to mwabs(f_poly(r)).
But it works if I use eval(mwabs(f_poly(r))) instead.
One more similar observation:
I wrote a simple function
logspace(a,b,N):=mwexp((a+{b-a}/{N-1}*(range(0,N-1)))*ln(10))
to generate logarithmic frequency grid.
The execution of the entire worksheet become suspiciously slow ~ 10 sec.
In order to clarify the issue I tried
logspace(a,b,N):=eval(mwexp((a+{b-a}/{N-1}*(range(0,N-1)))*ln(10)))
and execution time became just 0.5 sec.
What is puzzling me, is that result of mwexp((a+{b-a}/{N-1}*(range(0,N-1)))*ln(10))=
pops on the screen instantly, but somehow the result of logspace() when used, delays the rest of the worksheet execution.
not a logspace() itself. Why eval(mwexp()) is not equivalent to numerical function mwexp() ?

Mentioned here, added in the BTS:

- linear indexing vs transpose (SS-76)
- linear indexing vs assignments (SS-129)
- order of assignments inside matrices (SS-130)

Thank you! I will handle issues reported in BTS.