Eval scalar exponentiation error (bracket balancing)

[Gunni.75]

Hi
There seems to be an significant calculation error of the 'eval multi-variable scalar VI. Evaluation of 0-3^2 leads to +9 instead of -9. The VI 'bracket balancing' converts 0-3^2 to (((0)+((((-(3)))^(2))))) which can be reduced to 0+(-(3))^2.
I'm using Labview 8.2 and the version of 'bracket balancing' is 140. Altering the VI lies far above my skills therefore I ask if there is a updated bracket balancing VI published?
A 'workarouond' is so far to always parenthesize the basis: 0-(3)^2
Thanks in advance

Message Edited by Gunni.75 on 06-14-2010 08:09 AM

[RuedigerE]

Hi, I tested it in LV 2009 and couldn't reproduce what you mentioned (please see Pictrue_1.jpg). Could you test the VI I attached in LV 8.2? Regards Rüdiger

[Darin.K]

This has come up before with no response from NI.  When I looked at it back then I remember tracking the problem down but I can't remember if I actually fixed it or not.  I'll try to look at it again (it wasn't pretty).

Here is something you can try to workaround the problem.  It is a snippet so I have attached the 8.2 version as a VI.  It encloses a number preceding a exponentiation operator in parentheses.

[altenbach]

---

@RuedigerE wrote:
Hi, I tested it in LV 2009 and couldn't reproduce what you mentioned (please see Pictrue_1.jpg). Could you test the VI I attached in LV 8.2? Regards Rüdiger

---

Rüdiger,

While it works correctly using variables as in your example, the result is wrong even in 2009 SP1 if we use constants. This needs to be fixed!

[RuedigerE]

Hi,

thanks for reply! I will write a CAR (Corrective Action Request) and hopefully the problem will be fixed in the next lv version.

Kind Regards

Rüdiger

[Gunni.75]

This replacement approach works. Thanks.

[altenbach]

---

@RuedigerE wrote:

I will write a CAR (Corrective Action Request) and hopefully the problem will be fixed in the next lv version.

---

Thanks. Make sure to post the CAR # once you get it.

[Darin.K]

I have had great success recently using the SubVI setup 'Suspend When Called' which suspends execution when a SubVI is called, pops up its Front Panel and let's you manually enter the values you think it should have produced.  I decided to practice by trying to squash one of the more irritating bugs in vi.lib, the one described here.

Normally when you dumpster dive into about three layers of these formula parsing VIs your head is spinning.  This time I was undeterred and systematically worked through tracking down the problem.  Using the Suspend When Called I could see that when I gave the output I expected, the value was correct, so then I just had to track down the code that was making the change.  This greatly reduced the number of VIs to go poking into.

Finally, I got to NI_Gmath.lvlib:Backward Decompose Number.VI, I'll spare you the rest of this lovely VI and only show the cause of this bug:

The purpose of this VI is to split an expression into a number plus operator followed by another number.  For example 1-2 should split into 1- and 2.  For some reason, unbeknownst to me, they added that check at the end which changes 1- and 2 to 1+ and -2.  Simply removing wiring a false constant to the case fixes the bug, and also seems to handle the unary minus tests I quickly threw at it.

I am sure this predates all forms of Perforce logging so we may never know why this check is there.  Bottom line, Suspend When Called rocks, it cut through the vi.lib morass like a hot knife through butter.