Eval Formula Node rounding bug?

[tomlawton]

Hi-

anyone else found that the behaviour of int(x) is different (wrong?!) in a parsed formula than in a Formula Node or Expression Node?

It seems to behave like floor(x)... (At first I though it was like intrz(), then I checked negative numbers...)

(LV2021.0.1f2, MacOS)

 

So, 3 problems:

• Is this a bug- or have I misread the (sparse) documentation for acceptable functions in parsed formulae?
• Anyone got a workaround in a parsed formula..? -No mod(x,y) of course...!
• How the hell do you contact Support these days to report bugs..?!

TIA...

~Tom

[GerdW]

Hi Tom,

---

@tomlawton wrote:

anyone else found that the behaviour of int(x) is different (wrong?!) in a parsed formula than in a Formula Node or Expression Node?

It seems to behave like floor(x)... (At first I though it was like intrz(), then I checked negative numbers...)

---

Mind to share some examples for "buggy" input values?

For me (LV2016-32bit, Win10) it seems to behave as described in the help with bankers rounding…

[tomlawton]

Oh- perhaps a Platform issue- I'll check on a PC in a second..

But here's what I see on a Mac:

[tomlawton]

Oh- nope- PC too:

(LV21.0.1f2, 32-bit)

[GerdW · Accepted solution]

Hi Tom,

when you debug your example all the way through those FormulaParsing functions you will see the int(x) is translated into function #22, which is executed as "round towards -inf". (Tested with LV2016-32bit). That is not what is described in the LabVIEW help as "round to nearest"…

IMHO you may contact NI support and ask for clarification or a bug report number!

(In my previous post I just checked the FormulaNode.)

[tomlawton]

Thanks Gerd for digging down to that! (gosh, it's just layer on layer of pure LabVIEW, not quite as nicely wired as I would like, and with scary brittleness, e.g. Function Decomposition.vi; that's not how I'd do that...! Maybe it's for speed...)

Now questions 2 & 3 remain...

Is there a workaround, with just the functions available in a parsed formula?

(for now, since I can, on my own machine I'll just fix Three Register Calculation.VI:

and replace the Round Towards -Infinity with Round To Nearest... Talk about brittle... 😂

And how does one report bugs these days?! Once upon a time, I'd have contacted my NI rep, who would have passed me on to someone in Support... but those days have gone....

Thanks for your swift replies!

[dan_u · Accepted solution]

Not a nice solution, but you could add 0.5 to the input value.

Regarding support: ni.com/ask

[GerdW]

Hi Tom,

---

@tomlawton wrote:

(for now, since I can, on my own machine I'll just fix Three Register Calculation.VI:

and replace the Round Towards -Infinity with Round To Nearest... Talk about brittle... 😂

---

That's the worst "solution" you could implement as your program will behave differently on other computers!

You got a much better workaround from Dan - when you don't need bankers rounding...

Btw.:

Why do you want to use ParseFormula including "int(x)" function?

To replicate the "round nearest with bankers rounding" you need something like this:

In the image you also see a corner case: floats allow for "negative zero" while integers don't know about that…

[tomlawton]

Thanks! That does indeed get around the problem for now- and however un-nice, better than my local fix in vi.lib... 😂

And thanks for the support link- I'll get it reported. Then when they ever fix it, I'll need to remember to stop adding 0.5... 😆

[Yamaeda]

I'm fairly sure int(x) in most languages gets the integer part of a number (thus rounding down), same as doing a Modulo 1 (quotient and remainder).