Hello,

I just revised my finite element analysis SMath scripts and made the following observation with SMath 0.95.

The definitions of Knum and Ksymb are identical except that the optimization setting for the statement is numeric and symbolic respectively.

SMath file

IMHO this tends to be more a bug than a feature.

Given the sometimes unexpected side effects of the optimization settings, I would recommend to provide a clear visual tag on what setting is active for a given statement, preferrably different versions of the assignment and display operators, e.g.:

• a= display result of numeric evaluation
  
• a-> display result of symbolic evaluation (as the corresponding symbol in the math panel suggests)
  
• a:=expr assign (delayed) numeric evaluation
  
• a<-expr assign (delayed) symbolic evaluation
  

eval() would then just enforce immediate evaluation, be it numeric or symbolic, depending on the assignment operator. One might wish to add tags for no evaluation at all, however, I never felt need for it.

One big advantage of the SMath electronic paper over spreadsheets like excel is the self documenting display of what is to be calculated. Currently, one has to inspect every expression via nested RMB clicks in order to find out evaluation (or "optimization" ) settings.

I believe that implementation of the proposed markup could speed up the debugging process, because the sheets would be more transparent and the circumstances would be more reproducible. If I see a screenshot, there is no clue on what optimization settings are used and it is quite tedious to inspect every possibly "guilty" expression.

I am quite sure that my proposal might require significant work but I feel that the symbolic/numeric issue shall keep the developer and the users busy for quite some time. Thus it might be worth the effort.

Best regards, Martin Kraska


PS: Why is [MATH]sqrt(16)[/MATH] not reduced to 4?

Hello,

I think it has something to the transpose bug Transpose-functions-bug. I tried your example with the corrected Syslib.7z and the same result as you presented. Rearranging the expression will get the result right.


I think that in your example happened some similar thing like in the reported bug, as like you used [MATH=eng]B(ee)*transpose(B(ee))[/MATH] instead of [MATH=eng]transpose(B(ee))*B(ee)[/MATH].

Regards,
Radovan

Hello Radovan,

thank you for clarifying the nature of the bug. I agree that this is an example of the wrong symbolic handling of non-commutative multiplication. So this topic may well be deleted or moved by admin.

Best regards, Martin