MATH Box Changing My Parenthesis and Solving the Wrong Equation (Solved)

[Mike Nash]

Expressions are Cut and Paste from the MATH box before and after hitting Enter.

What I enter:

((in-imin)/(imax-imin))^((LOG((omid-omin)/(omax-omin)))/
(LOG((imid-imin)/(imax-imin))))*(omax-omin)+omin

What it becomes:

((in - imin) / (imax - imin)) ^ (((LOG((omid - omin) / (omax - omin)) / LOG((imid - imin) / (imax - imin))) * (omax - omin)) + omin)

All nicknames are Reals.
imin = 0
imid = 10
imax = 100
omin = 0
omid = 50
omax = 100
in   = sweeps 0 to 100 (so I can trend the curve!)
out  = result(R109)

"out" should give a curve 0 to 100 but at "in" of 10, "out" should be 50. Do-more's reordering of the operations results in a fixed "out" of 30. If I do the exponent calculation separately and then use the result in place of the LOG/LOG portion, it gives the correct results.

I have tried various arrangements of the parenthesis, but have had no luck. (I have about gone blind trying to match them up.)

Granted, if the curve shape is changed only seldom, I should do the exponent calc only as needed, but I wanted to see this work... Excel does give the proper result and the Do-more version result using the 2 versions and subbing LOG10 for LOG.

I'll admit my math skills are beyond rusty and this was an uphill climb for me to get this figured out. I haven't done anything with LOG in over 30 years. I didn't remember you even could solve for an unknown exponent.

This is overly complicated but if the MATH will leave my expression as-is it becomes a one rung solution. Otherwise, I could LERP the at-whim scaling points to 0-1, solve for the exponent p of y=x^p, solve for the output y then scale with LERP to the at-whim output points.

[BobO]

Parser bug? Certainly shouldn't be changing priority when it's fully specified. We'll look into it.

[franji1]

It is correct.  You need to put parentheses around the part that does NOT include the + omin.

But I can almost guarantee that you need to replace your XOR operator ^ with raised to operator ** and then your operator precedence should work as expected.  The Math regeneration is correct based on the operator precedence between + and ^, and also between + and **, but I am not at a PC right now to verify that.

Regardless, when in doubt about operator precedence, use parentheses to eliminate any possible ambiguity.

[Mike Nash]

It is correct.  You need to put parentheses around the part that does NOT include the + omin.

But I can almost guarantee that you need to replace your XOR operator ^ with raised to operator ** and then your operator precedence should work as expected.  The Math regeneration is correct based on the operator precedence between + and ^, and also between + and **, but I am not at a PC right now to verify that.

Regardless, when in doubt about operator precedence, use parentheses to eliminate any possible ambiguity.

Ding Ding Ding! And we have a wiener! Me that is. I even went and looked at the operators I was supposed to use, noted LOG and ** and still messed it up. I went and looked, then jumped to Excel which used ^ and of course I then cut and pasted from Excel and ** was completely gone from my head.

Thank you gentlemen. I really was hoping it was something I was doing wrong. It works a treat now. Sure are a lot of (((((()))))))s to boggle my mind, but they are all just right now.

((((in - imin) / (imax - imin)) ** (LOG((omid - omin) / (omax - omin)) / LOG((imid - imin) / (imax - imin)))) * (omax - omin)) + omin

[BobO]

I like this answer much better.

[franji1]

To greatly simplify the expression and what was going on, if you entered the expression
V0 ^ V1 + V2

the precedence of ADD is greater than the precedence of XOR, so the implied parentheses end up being
V0 ^ (V1 + V2)

However, for the expression
V0 ** V1 + V2

the precedence of ADD is LESS THAN the precedence of RAISED TO POWER, so the implied parentheses end up being
(V0 ** V1) + V2

In Designer and DirectSOFT, the MATH instruction will ALWAYS regenerate the expression WITH THE IMPLIED PARENTHESES.  This is done because WE don't even remember the precedence rules (order of operations), so why should we expect our customers to?  Hence, when you enter an expression, the parentheses will AUTOMATICALLY show up where they are IMPLIED.  The only time we DON'T add the parentheses is in the EXTREMELY OBVIOUS situation of using binary operators that are in the SAME PRECEDENCE GROUP and that are Commutative AND Associative.  So if you entered V0 + V1 + V2, you will end up with V0 + V1 + V2 (no need to insert implied parentheses because ADD is in the same precedence group with itself (duh!) and ADD is Commutative and Associative).  However the MATH regeneration of V0 - V1 - V2 WILL insert the implied parentheses (V0 - V1) - V2 because subtraction is NOT Associative (a - b is not the same as b - a).

So, any time you see the "wrong" parentheses placed in a re-generated MATH expression, it's probably because the operator precedence order is NOT what you thought.

You will never be wrong when writing longer arithmetic and/or logical expressions to OVER-USE parentheses to ensure the operator precedence is EXACTLY what you want/need.  Once you enter the expression, Designer will REGENERATE the expression with MINIMAL VERBOSE parentheses (not too many, not too few, but JUST right).

In case you were wondering, here is the precedence priority table (based on C/C++ precedence rules):
1. || (logical-OR)
2. && (logical-AND)
3. | (bitwise-OR)
4. ^ (bitwise-XOR)
5. & (bitwise-AND)
6. == != (equality)
7. > >= < <= (relational)
8. >> << >>> (bit shift)
9. + - (add/sub group)
10. * / % (multiply/divide/modulus group)
11. ** (raised-to-power)
12. ~ ! - (unary operators: bitwise invert, logical NOT, unary minus)

I would not bother "memorizing" or utilizing this table (we don't) - just use parentheses to leave no doubt.

[Mike Nash]

I am absolutely in favor of the parentheses, but I have always had trouble pairing them up visually. The final expression has 13 pairs. So I was spending a lot of time trying to figure out why they were moving even when I felt I was using more than needed. For me, this even meant copying to wordpad and trying to get them where I could "see" the groupings. 

Excel will try to help by coloring them, but the colors don't stay there, are too similar at times, slow you down if cursoring with the keyboard, and are too small anyway.

I have no idea what would work better for me other than pencil and paper, so I am not actually complaining, it is my shortcoming I am dealing with.

My biggest problem is due to the different uses of characters to mean the same or different things depending on programming language. I keep getting tripped up over == instead of =, != rather than <>, and ** for ^. It still gets me that I did go to the MATH help and look up which ones I needed and still overlooked the ^. Totally my bad.

I was actually trying to get this curve fit figured out for an old PLC5. It doesn't have any native scaling instructions so their CPT (math) instruction would work best using this same equation. It's just easier to figure out in the Do-more simulator. I didn't figure it in time so if a curve is needed the exponent has to be entered as an already calculated entry.

And thanks for the lesson. I am going to have to remember that I can't trust myself to remember.

[franji1]

One of the small helpers we added in 1.4 to MATH and STRPRINT/EMAIL (free form editors) is that you can hit Ctrl+Enter to help you layout the edited text, so instead of entering the large expression as one long line with window-edge-wrapped CR (like this topic's example):

((((in - imin) / (imax - imin)) ** (LOG((omid - omin) / (omax - omin)) / LOG((imid - imin) / (imax - imin)))) * (omax - omin)) + omin

you could hit CTRL+ENTER to place critical CR to help while entering:

Code: [Select]

((((in - imin) / (imax - imin)) **
  (LOG((omid - omin) / (omax - omin)) /
   LOG((imid - imin) / (imax - imin)))) *
 (omax - omin))
+ omin
(but you are 100% responsible for figuring out those critical places to hit CTRL+ENTER).

The entered instruction does NOT maintain those CR, so it only helps while in the editor.  It's a little bit of help, but not much.

Color-ized parentheses will help infinitely more.  It's on our TODO list (but it is not trivial).

[Controls Guy]

If not colorizing, I can't remember if DMD at least highlights matching paren pairs.  IOW, if you type a closing paren, does it highlight the matching open paren in bold or color or flashing or something?  Some editors do that, and I find it helpful, and it might take less effort than permanent static pair-match-colorizing.

Also, allowing brackets and curly braces would help us keep it straight too.

Or....have a graphical parser, so we can paste in a graphic from an equation editor formatted so a human can read it.  Looks better on the ladder printout too!   [runs ducking and covering head]

[Mike Nash]

I use the CTRL+ENTER and it certainly does help, but I have trouble remaining consistent about when I insert it, yes.

⁽(_(x+y)-1)^)**z

Maybe not. 

(_b(_aX+Y_a)+1_b)

(^'(^''X+Y)^''+1)^'

I got nothin'.

[franji1]

If not colorizing, I can't remember if DMD at least highlights matching paren pairs.  IOW, if you type a closing paren, does it highlight the matching open paren in bold or color or flashing or something?  Some editors do that, and I find it helpful, and it might take less effort than permanent static pair-match-colorizing.

It does not, but that would ALSO be cool (color all parentheses but also bold/flash current paired parentheses)

Also, allowing brackets and curly braces would help us keep it straight too.

Definitely.

Or....have a graphical parser, so we can paste in a graphic from an equation editor formatted so a human can read it.  Looks better on the ladder printout too!   [runs ducking and covering head]

The ultimate (for display/print), but you still have to enter/edit it somehow.  Display features are different than editing.

[franji1]

but I have trouble remaining consistent about when I insert it, yes.

Agreed.  Like I said, it was a "small" helper.   

[Controls Guy]

The ultimate (for display/print), but you still have to enter/edit it somehow.  Display features are different than editing.

Hmmm, cool idea - have the editor display your character mode entry in normal math formatting!  In my case, I was just teasing about cutting and pasting a JPG or other graphic format of an equation entered in an equation editor into the MATH box editor, and having DMD OCR it and parse.  Hence the "running and ducking" part.