Hello

under the link FEM files I posted two files which are basically identic, but differ just in the dummy argument in the definition of the functions dx, dy, L, B and K (under the headline "Aufbau der Elementsteifigkeitsmatrizen" which means assembly of element stiffnes matrices).

In File FEM_a.sm the dummy argument is "a", in FEM_e "e" is used. Both variables are used earlier outside the definitions. "a" is an input parameter, "e" is a loop iterator in the code chunk for graph matrix generation.

The version with "a" works (last plot of the sheet shows the displacement of the truss framework), while the version with "e" fails.

As one can see using dynamic preview at the definitions, usage of "a" generates a valid function definition with the dummy argument shielded from the global namespace but usage of "e" does not. The latter just generates a definition using the global current value of "e".

So far I assumed that all variables used in function definitions are global unless they are used as function parameters (dummy arguments). In this case, the parameters shadow any outside variables with the same name. Am I wrong in that? Is it wrong to expect definitions not to depend on choice of internal parameter names?

Best regards, Martin

BTW:

Thank you mkraska. Need to check it when will have a time.

Best regards.

Hello mkraska,

I think I found the problem about this. It seems that the safest way when defining a single line function is to use line() environment in spite of the fact that the function is in the single line. It seems that single line functions will get some global things especially when the vectors and matrices are involved and their indices as well, and can make a confusion to the user. Just hoover your mouse over the defined functions dx, dy, L, B and K. Quite a confusing output, isn't it for both of your cases. Now, when you put your functions in the line() environment, this will suppress the possible misunderstanding. Look the picture at the corrected example with "e" variable as a function argument and the functions defined in the single line() environment. My advice for you is to use the same thing in the correct "a" example, just in case.

FEM_e-correct

This might be also the answer to your problem in the following post http://en.smath.info/forum/yaf_postsm6632_Problem-with-Matrix-Algebra.aspx#post6632

I should have noticed this before, sorry.

Regards,
Radovan

Hello Radovan,

thank you for digging into the details. I just tried the workaround proposed by you. Your hint with the other bug report inspired me to check how version 0.91 behaves: Both FEM_a.sm and FEM_b.sm work fine. I also confirm that the matrix algebra problem was due to the same function definition bug introduced in version 0.92 and persisting till present.

This lead to all truss element matrices being identical and thus even the reduced system being rank deficient (which Smath had all reason to complain about).

I consider failing single line function definitions being a bug, given that a natural look of the expressions is one of the strengths of smath over line oriented programming language based interfaces as matlab or maxima.

The line operator is a good way to extend the function definition capabilities. However, I cannot see the logics behind requiring it for shielding local parameters in a function definition.

@ Andrey: Of course, it's your decision to classify the problem as bug or as feature and I have no idea on how complex fixing the bug or changing the feature would be. Still I clearly vote for return to pre-0.92 way of parameter handling.

Just taking the chance of placing a feature request:

Much of that function definition is just required as a workaround for the lack of mathcad like range variables. They are a really intuitive concept (unless spoiled by the 0/1 first index issue). Range variables would make my examples more math-like and less code-like. I guess one would need the concept of implied iteration over vector-valued indices just like in matlab.

Perhaps just a matter of taste, but I am biased by teaching mechanics instead of math and informatics.

Again, Andrey and Radovan, thank you for your help.

Best regards, Martin.

Hello Martin,

Wrote

...I just tried the workaround proposed by you. Your hint with the other bug report inspired me to check how version 0.91 behaves: Both FEM_a.sm and FEM_b.sm work fine. I also confirm that the matrix algebra problem was due to the same function definition bug introduced in version 0.92 and persisting till present.

To be honest, I've never been quite sure what was the difference between a single line function and a function with a single line() environment. I always just use single line first, and if this does not work or look something suspicious to me I try single line () then.

Regarding your examples, it seems that something is wrong as you mentioned. For instance, your file with "e" variable - FEM_e.sm is working for me in both 0.91 and 0.92 (in spite of warnings about new version) but does not work in 0.93 and 0.94. (by working I mean that no error about the inverse matrix was reported). On the other hand, I tried the file from http://en.smath.info/forum/yaf_postsm6632_Problem-with-Matrix-Algebra.aspx#post6632 as well. The same situation, v0.91 and 0.92 will work but 0.93 and 0.94 will not. Moreover, ranks were different for 0.93 and 0.94 - rank(KS)=8 for v0.93 and rank(KS)=6 for 0.94.

I also noticed that hoovering the functions you mentioned, there are differences when using "a" or "e" as a dummy argument. In versions v0.91 and 0.92 there are no differences while there are differences in versions 0.93 and 0.94. Here are the poictures

---

-------


Again, making single line() function will get the results for both v0.93 and 0.94. We also have to take into account that the determinant of matrices Ks K.r are quite close to zero and this causes problems. I even tried to get rank(KS) for the working versions. For the working v0.91 and 0.92 I still can not calculate rank(KS) (large or small numbers reported) although the calculation went Ok. For both v0.93 and 0.94 when putting line() the rank(KS) took quite a long time then (I interrupted the calculation without result).

Quite strange and confusing.

Regards,
Radovan