Allow Output Configuration for the Compound Arithmetic node

[GregSands]

For consistency, the Compound Arithmetic node should provide the Output Configuration property in the same way as Add, Multiply, and most of the other Numeric functions do.

[AristosQueue (NI)]

I had no idea what you were talking about, so I went to look at the Add primitive.

Why in the world do we have that feature on the Add primitive? Why would I *ever* want to turn off type adaptation? I'm seriously confused. Can you explain what this feature is used for? (Meanwhile, I'll be hunting through the LV R&D team to find who implemented this to ask them the same questions.)

[tst]

You can use it in any situation where you would use a conversion bullet after the primitive, and I do occasionally use this.

That said, I rarely use the compound node for numeric data and I do see a potential for "too much work for NI" (meaning other features don't get implemented) because the compound node also supports boolean data.

[CMal]

"Why would I *ever* want to turn off type adaptation?"

The Output Configuration feature is very useful when working with fixed-point datatypes on FPGA.  The output of math primitives will by default not have the same fixed-point representation as the inputs so that data isn't lost.  This feature is a nice way to enforce the same representation on the output as on the inputs.  More importanty, you cannot use the divide primitive with integers on FPGA unless you configure the output to not be floating-point. 

[AristosQueue (NI)]

Ah. Fixed-point. I didn't think of that case. 🙂

I'll make sure the appropriate developer sees this idea.

[GregSands]

Not just fixed-point.  I often use this if I want to Divide two integers and obtain the result as a SGL rather than the default DBL. Of course I could use a conversion bullet after the output, but this is slightly cleaner (since LV 2009 I think).  I don't often use the compound node either, but it seems wrong for it not to have the same functionality.

Now look at the case where the result is a large 3D array - using a conversion means having separate copies of the result for DBL and SGL, whereas (hopefully) using output configuration, this can be optimised by the compiler.

[AristosQueue (NI)]

A) Why wouldn't you put the conversion at the input?

B) How would it be optimized by the compiler? The math still has to be done in one type or the other and then converted. No getting away from that.

[GregSands]

Yes, converting on the input would be equivalent. The only optimization is in not using a higher-precision than required at the output - I guess the Output Configuration is just a clean way of doing that (or more obtuse if you like seeing everything in the diagram).