  Rank: Advanced Member Groups: Registered
Joined: 22/02/2014(UTC)
Posts: 81
Was thanked: 11 time(s) in 10 post(s)
|
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 ? Edited by user 07 March 2014 04:20:00(UTC)
| Reason: Not specified
|
|
|
|
|
|
 Rank: Advanced Member Groups: Registered
Joined: 15/04/2012(UTC) Posts: 1,988  Was thanked: 1127 time(s) in 723 post(s)
|
Originally Posted by: tomtit  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? |
|
|
|
|
|
|
 Rank: Advanced Member Groups: Registered, Advanced Member Joined: 13/01/2012(UTC) Posts: 2,650   Location: Italy Was thanked: 1338 time(s) in 878 post(s)
|
Take care about known bugs: - linear indexing vs transposed matrics- linear indexing and the assignmentsQuote: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... Quote: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... Edited by user 05 March 2014 23:50:23(UTC)
| Reason: Not specified |
If you like my plugins consider to support SMath Studio buying a plan; to offer me a coffee: paypal.me/dcprojects |
|
|
|
|
|
Rank: Advanced Member Groups: Registered
Joined: 22/02/2014(UTC)
Posts: 81
Was thanked: 11 time(s) in 10 post(s)
|
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"  Quote: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. Edited by user 06 March 2014 00:00:35(UTC)
| Reason: Not specified
|
|
|
|
|
|
Rank: Advanced Member Groups: Registered, Advanced Member Joined: 13/01/2012(UTC) Posts: 2,650 Location: Italy Was thanked: 1338 time(s) in 878 post(s)
|
Originally Posted by: tomtit 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 Edited by user 06 March 2014 02:43:01(UTC)
| Reason: Not specified |
If you like my plugins consider to support SMath Studio buying a plan; to offer me a coffee: paypal.me/dcprojects |
|
|
|
|
|
Rank: Advanced Member Groups: Registered
Joined: 22/02/2014(UTC)
Posts: 81
Was thanked: 11 time(s) in 10 post(s)
|
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() ? Edited by user 08 March 2014 00:52:15(UTC)
| Reason: Not specified
|
|
|
|
|
|
Rank: Advanced Member Groups: Registered, Advanced Member Joined: 13/01/2012(UTC) Posts: 2,650 Location: Italy Was thanked: 1338 time(s) in 878 post(s)
|
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) Edited by user 26 April 2014 12:54:13(UTC)
| Reason: Not specified |
If you like my plugins consider to support SMath Studio buying a plan; to offer me a coffee: paypal.me/dcprojects |
|
|
|
|
|
  Rank: Administration Groups: Developers, Registered, Knovel Developers, Administrators, Advanced Member Joined: 11/07/2008(UTC) Posts: 1,616  Was thanked: 1978 time(s) in 666 post(s)
|
Thank you! I will handle issues reported in BTS.
|
 1 user thanked Andrey Ivashov for this useful post.
|
|
|
|
Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.
