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 sqrt(16) not reduced to 4?

Edited by user 23 March 2014 19:03:31(UTC)  | Reason: Not specified

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