SMath refuses to correctly handle the given example: error "Units don't match"

---

units.sm (175 КиБ) скачан 54 раз(а).

Confirmed

me too

Maybe, this problem is related. SMath fails to correctly simplify exponents of units.

---

I found a bloody workaround, which essentially spoils the visual appearance of the formula and is by no ways explicable to students.

Normally, I say that non-matching units are an indication for physically wrong equations. But it turns out, that prior to draw this conclusion, you have to try hard spreading eval() over the components of the equation. You never know if you tried all possible combinations...

I easily can be blamed for confusing the students by recommending inappropriate and unreliable math software, if even arithmetics do not work. Thus, this issue has rather high priority for me.

I just hope that this can be fixed without complete rewrite of the units engine. If the fix requires to always simplify to base units (Pa is a derived unit, as it can be expressed by N, m, s), then be it, as long as I can still change the result unit to Pa or MPa.

---

units2.sm (14 КиБ) скачан 55 раз(а).

I noticed that the operator Eval is only required for the square root

It seems to work without eval if one raises the expression to 0.5 instead of using the square root symbol.

Wrote

It seems to work without eval if one raises the expression to 0.5 instead of using the square root symbol

Can't confirm that.

---

I know that it may sound harsh but I think Andrey should fix symbolic engine issues like this one before developing any other features. This may scare off some users despite being SMath a great tool.

Wrote

Wrote

It seems to work without eval if one raises the expression to 0.5 instead of using the square root symbol

Can't confirm that.

It's strange, it happened to me the same as you but then changed the decimal delimiter and saved the file, closed it and opened it again, this time the calculation was right. it could be an issue related with saving the current session settings.

Can you confirm this ? the first one is opened with period decimal enabled on tools->options, the other one with comma.

---

Kilele, I confirm a dependence on the decimal separator setting, however, quite different from what you show.

---

Yes we are experiencing different results!
For your information I'm using the unofficial portable version 0.96.4909 which I think it is the 32bit patched one, my os is Vista32. I wonder if this is related to the way variables are dealt with on 32-bit and 64-bit systems.

I think that not only the decimal symbol has influence but also the different combinations with the argument separator, some of them make the eval expression fail or even 0.5 is reported as "input string does not correct format", apart from the already mentioned error "units don't match".

At least I hope this thread gives some new insights to Andrew.

Wrote

and if possible give us some minimum survival rules

About your functions the rules are:

- Inside functions "global variables" are all the variables not defined inside the function but defined on the canvas; if you define a variable already defined on the canvas, SMath assumes that you are defining a local variable. If you want to write a global variable use the rule below.

- if you assign a value to an input variable inside a function, the input variable will change globally (the value will propagate outside your function) (passing by reference feature - look this thread).


IMHO is a good way to handle local/global variables, obviously if you know these rules :d


best regards,

Davide

Wrote

What do you think about the troubling case of the function f11 from my file. There all the precautions are taken - all variables are exclusively locals but there seems appearing an impact on the global variables a..c ?

Inside your function f11 you redefine the input variables, so you are using the 2nd rule, that is the way to (over)write the global variables.

Wrote

Of course, as always, it's essential to know the rules

I agree... two rules, not so hard

Wrote

Are they those of C# programming?

Nope, and I think that is better...


P.S. I've update my previous post

this sample by omorr is quite explanatory
http://en.smath.info/forum/yaf_postsm5932_Functions-behave-differently-in-0-9.aspx#post5932
if you use a variable name when calling a function this variable defined with the same name before on the canvas will be overwritten.

Wrote

If I'm not wrong, the main difference between a function and a subroutine (as in BASIC) is that a function use only the input variables, without modifying them.
Are SMath functions behaving as subroutines ? If it's so, the name function is a false one? better is to call them subroutines ?

I don't know if your description is correct, but you can see the SMath functions in this way

Wrote

this sample by omorr is quite explanatory
http://en.smath.info/forum/yaf_postsm5932_Functions-behave-differently-in-0-9.aspx#post5932
if you use a variable name when calling a function this variable defined with the same name before on the canvas will be overwritten.

Thank you for showing us this thread... as you can see the point is not the name, only the fact that you have changed the input argument (passing by reference feature description by Andrey - same thread)

As written by Andrey, there are several SMath features arising from this property...

Wrote

the rules are:

- Inside functions "global variables" are all the variables not defined inside the function but defined on the canvas; if you define a variable already defined on the canvas, SMath assumes that you are defining a local variable. If you want to write a global variable use the rule below.

- if you assign a value to an input variable inside a function, the input variable will change globally (the value will propagate outside your function) (passing by reference feature - look this thread)

[edit] Probably a better way can be found, and I hope that this will be ; actually what I mean is that there is a logic and is not so complicated as appears if you don't know these rules.

I should have posted this link from the same thread
http://en.smath.info/forum/yaf_postsm5930_Functions-behave-differently-in-0-9.aspx#post5930
so replace "name" by "reference" on my previous post, though in most of the cases names coincide with references.

Wrote

If I'm not wrong, the main difference between a function and a subroutine (as in BASIC) is that a function use only the input variables, without modifying them.
Are SMath functions behaving as subroutines ? If it's so, the name function is a false one? better is to call them subroutines ?

According to the conclusion of this article you are right, though this definition depends on the language.
http://en.wikibooks.org/wiki/BASIC_Programming/Subroutines_and_Functions#Conclusion
Maybe this feature could have been implemented to differentiate functions from subroutines or procedures, for example if there is return of variables then it'd be a function and everything would remain local, otherwise, without return it'd be a procedure and these variables would be overwritten globally, provide different type of lines for subroutines and functions, use the keyword "ref" before each paramenter called by reference as in C#, etc.