maths in netlinx studio

REBUILD_EVENT

has anyone got a clue about mathematics in netlinx studio?

i often try to calc things like -sMyTemp*0.292+32.667 and i get errors unless i
try (-sMyTemp*0.292)+(32.667) which maybe makes sense if one knows the rules.
i don't know them...

i remember having problems especially with minus and comma before, i never got what i wanted

ericmedley

I'm not sure if I'm understanding your problem correctly but you might be running into an issue with the decimal places. The first thing is to make sure you're decalring the variable sMyTemp as a floating point variable.

I'll admit that I'm really old-school when it comes to this kind of thing and I still do the old-fashioned method of multiplying my whole equation by (in your case) 1000 to get rid of the decimal place, doing the math, and then dividing the whole thing by 1000 to get it back down.

Another thing to try is go ahead and make the constants 0.292 and 32.667 into variables and see if that helps.

So for example:

define_variable

FLOAT sMyTemp
FLOAT some_variable_1=0.292
FLOAT some_variable_2=32.667

And then the equation will look like


result = (sMyTemp * some_variable_1) + some_variable_2


Now, if you're referring to the convention of the equation, the rule is the same for most programming. What's in the parens gets done first.

So, the order from the above equation will be

step 1
sMyTemp * 0.292

then the result of the above will have

32.667 added to it.

Hope that helps.

EJM

REBUILD_EVENT wrote:

has anyone got a clue about mathematics in netlinx studio?

i often try to calc things like -sMyTemp*0.292+32.667 and i get errors unless i
try (-sMyTemp*0.292)+(32.667) which maybe makes sense if one knows the rules.
i don't know them...

i remember having problems especially with minus and comma before, i never got what i wanted

yuri

it has something to do with the decimal. If you do this:

sTemp * 2 + 2

it will work... but sTemp * 2.2 + 2.2 needs brackets around the floats.

btw:
sTemp * (2.2) + (2.2) will also work

NMarkRoberts

When you work or have worked with lots of different languages with different operator precedence and float handling you learn to code arithmetic defensively, verbosely, and unmistakably getting what you want. It doesn't matter if the code takes 10 lines instead of 1 if you know what you are getting at the end.

Eric lists a few good policies. Here are some of mine:

(1) Use parentheses everywhere to enforce the precedence you want even if right now you know what the compiler's precdence rules are, because the next person who looks at your code might not remember the rules - and that person might be you in a couple of years.

(2) Explicitly type partial products by holding them in a local variable so you know exactly what you are getting at each step, and you then don't have to guess how the compiler will handle it. Here's a quickly thrown together not-very-good example, uncompiled and untested:

stack_var integer nMyPartial

nMyPartial = type_cast(a/b)
nMyResult = nMyPartial * c

(3) Avoid floating point partial products entirely using Eric's "multiply by 1000 first" approach.