Parse formula and mod/rem

[xl600]

According to

http://zone.ni.com/reference/en-XX/help/371361G-01/lvhowto/formula_node_and_express/

The mod(x,y) function should be allowed in the formula parsing VIs.  Yet, I get a 23095 error when I try it "mod(x,360)".  If this isn't actually supported, where is a list of functions that are supported?

Thanks,

XL600

[altenbach]

Formula parsing has some differences to the formula and expression nodes. There is a table showing the differences. (Sorry posting by phone)

[xl600]

If you could point me to that table when you get a chance, I'd like to incorporate that into my user guide.

I can substitute mod(x,y) with x-y*floor(x/y)) so it's only a little more complicated.  Annoying there's a difference in the first place.

Thanks!

[altenbach · Accepted solution]

Here is the list of differences. Yes, "mod" is not supported.

[altenbach]

I have never found much use for the formula parsing VIs, because they are not very efficient.

Why don't you try pure LabVIEW code instead? What are you trying to do?

[xl600]

Unfortunately, I'm far to deep into production code to back out the formula parsing concepts.  They're provided as a way to give my users basic mathematical functions for processing collected data.  Only a few of the functions are used, but I can't predict the complexity of what the users may want to define.  My system can pull in analog data from pretty much anywhere we can place our sensors and pull in any number of network variables which may need to be combined or modified (think degrees to radians coversion).

The formula parsing approach gives me a way to provide a textual method for defining these operations.  I preprocess the formulas via channel name substitution.  Ex: {chan1}+0.5*abs({chan2}).

Efficency wise, yes.  They are quite slow.  But my users don't use these very often so I traded lower code complexity for lower efficiency.

Knowing (up front) which functions are supported is thus critical.  I thought that help file was the list of supported functions, but it seems NI didn't make the documented limitations unique to the formula parsing VIs easy to find.

[xl600]

I've been pouring through that differences help page and it seems incomplete.  I hope NI is watching this and will update the differences help page (and link to it directly from the Parse Formula  String VI help page).  These kinds of missing details in help pages are really frustrating.

The parser doesn't seem to support these in addition to all the details from the differences help page:

& (Bit and) (Error -23088)

! (Logical not) (Error -23087)

^ (Bit XOR) (Treated as exponentiation)

&, !, ^ (Bit and, not, or) (Error -23088, -23087,

% (Modulus) (Error -23088)

~ (Bit complement) (Error -23087)

<<, >> (Arithmitic shift) (Error -23087)

rand() (Error -23086) (But rand(x) or rand(<any constant>) works)

Post-increment ++ and -- (Error -23093 or -23083) (But pre-increment seems to work, which is confusing)

[altenbach]

---

@xl600 wrote:

I've been pouring through that differences help page and it seems incomplete.

---

Thanks for checking. One problem is that these formula parsing tools are ancient (probably older than LabVIEW 3) and have collected a lot of dust since. It might be worth bringing this up with NI. I am not qualified to evaluate this. I try to ping some people. 😄

[SteenSchmidt]

That's why we made the Expression Parser toolkit: http://www.gpower.as/downloads/expression-parser-toolset

In the EP user guide you can find some tables comparing the various ways to define math in LabVIEW: http://www.gpower.as/images/downloads/exprparser/ExprParser_User_Guide.pdf

[rolfk]

This is another thread with basically the same conversation. And there is a link to this post on Lava which is an old version of a complete rewrite of the LabVIEW Formula Evalution Parser. It is not as efficient as the one from GPower and doesn't support all operators (a few more than the LabVIEW one but missing the % mod operator too). But it is a lot more efficient than the original LabVIEW formula evaluator was and in a cleaner way implemented although that didn't make the code trivial.