Allow All LabVIEW Supported Number Types in Formula Node (Extended Precision, 64 bit Integers, etc)

[X.]

The Formula Node (FN) is indispensable when implementing numerical algorithm in LV. There is just no way to get it right with wires and built in functions.

The problem is that it is limited to Double Precision only.

Since all functions available in the FN are implemented as primitives supporting extended precision, it is not like NI doesn't have the needed algorithms at hand.

Hence, please upgrade the FN to allow use of extended precision numbers (internally but also as inputs and outputs).

Note: I know about Darin. K's wonderful tool to transform text-based formulas into VIs, but sometimes there is just too many inputs/outputs for this approach to be a viable route, not mentioning that there is then no way to decipher (and modify) the resulting code...

[crossrulz]

I do find the FN much better for interpreting complex math algorithms.  64-bit integers should also be included if you are adding the extended floating point.

[X.]

Sure. I will ask a moderator to amend the title.

There already is a suggestion to include complex numbers which could use an extension to Extended Precision Complex Numbers.

[altenbach]

I don't think the formula node is a great place to implement advanced algorithms (hard to edit, no debugging, etc). If you want to program in text, you might as well use a language that is lower in the alphabet and make a dll to be used in LabVIEW.

We now also have MathScript, which supports many more datatypes, so I doubt anything new will happen to the formula node.

> There is just no way to get it right with wires and built in functions.

I typically get things right using only wires and built-in functions 😄

What is your need for extended precision? If it is so important, it would seem more useful to add extended precision support to anything in e.g. the linear algebra palette (currently only DBL and CDB), but this would be a separate idea.

However, DBL seems sufficient for all I do. If you operate near the edge of DBL (e.g. with huge condition numbers in matrices), going to EXT won't add that much more elbow room, ~3 decimal digits, or less than 20%)

[X.]

Is MathScript as fast as FN?

Is MathScript part of base LV?

I don't know where you get the 20% extra digits, but there is a difference (to me) between the minimum encoded value in DBL (~10^-323)and EXT (~10^-4920).

Now of course you cannot display these values in LV because they are cast to DBL (a bug reported elsewhere but ignored by NI), but internally the distinction is preserved.

So yes, when I multiply a very small number by a very large number with an expected result of O(1), I appreciate the small number not being cast to zero or the large one to Infinity (I am oversimplifying, but that's the idea).

[altenbach]

I was talking about the matissa size, not the dynamic range in the exponent.

Still, on a cosmic scale, the diameter of an electron is basically zero compared to the size of the solar system (and that size ratio is less than 1e30) 😄

[Darin.K]

If you are going to calculate say Pi using a series approximation, you will be limited by the round-off error, not the limitation of DBL representation.  If you do the approximation in EXT, you can find the value to the limit of DBL precision.  That is what EXT is well suited for, giving a few extra digits to mitigate round-off errors in an otherwise DBL world.

My own biased opinion is that I pointed NI in the right direction, and perhaps even added a kick to the backside to get them moving in the right direction.  As a developer you only need to specify the formula you are implementing, along with the inputs and outputs.  Under the hood you can generate the equivalent G code, it can be messy, very messy, and thanks to my code I have seen G that no person would ever create by hand.  The point is that the G code need never be seen outside of the compiler.  In fact, when I script the G code I often skip the BD cleanup and just plop 30 or so nodes down at the origin.

[X.]

Correct me if I am wrong, but you cannot put for, while, etc, statements in your Math interface tool... That's what is neat about the FN.

I checked the MathScript node, and whereas it does indeed work with extended precision, unfortunately, for most special functions, it seems to be limited to double precision. Not that any special function is available in the FN...

[Darin.K]

Correct me if I am wrong, but you cannot put for, while, etc, statements in your Math interface tool... That's what is neat about the FN.

You cannot.  I can.  That experiment will probably not be released into the wild.  I actually find that the ability to interchange arrays and scalars as inputs eliminates the need for most of those control structures, and is more robust.  I do like the support I have added for numeric integration and summation which uses loops.

[SteenSchmidt]

Would a 3rd party toolset that evaluates string expressions be of any use, or must it be built-in?

This: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Quick-Drop-Simple-Math/idc-p/2301676#M21455 (GPMath) allows conditionals for piece-wise defined functions, as well as ~200 functional keywords. It supports all the numeric data types, which, I must add, entails much more than merely changing the input/output data type - in many cases the internal algorithms have had to be tweaked slightly to accommodate certain numeric types (this has also uncovered some numeric conversion bugs in LabVIEW, duly reported to NI but not yet fixed).

Cheers,

Steen

[X.]

There is a performance issue to be taken into account... Did you release your toolkit? Does it support any LV type without coercion?