LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
Showing results for 
Search instead for 
Did you mean: 

Output Configuration for Add/Multiply Array Elements

Many times I like to keep my memory footprint small by using "right-size" data representations for my arrays.  Unfortunately, in the event I need to sum the array elements using the 'Add Array Elements' I am stuck in rollover city.  I can then blow up the data to a larger size or write out the sum (or product) longhand.




I would prefer an output configuration to let me specify the representation of the array sum or product:




Neat idea. I usually avoid the primitives for this exact reason. Of course the 'longhand' version isn't terribly long...

Active Participant
yeah I CAR'd this several years ago and nothing has happened. So please kudo this!
Stephen B
Proven Zealot

Stephen B: Can you post the CAR number?

Knight of NI

Excellent suggestion. It is another solution to the non-existing output configuration of "boolean to 0,1" when used to count the number of matching array elements by summing the output.


Enabling output configuration for "add array elements" is more memory efficient (if implemented correctly), so kudos!


Proven Zealot

I generally dislike adding features to the language just to compensate for weaknesses in the LV compiler, so I went to have a talk with the compiler team. They tell me the following is feasible, so I'd like to hear the community's thoughts on this alternate solution:


When debugging is turned off on a VI, it is possible for LV to recognize the pair of nodes "cast" followed by "Sum" or "Product", and then generate code behind the scenes that is equivalent to a loop that casts each item and adds/multiplies it to a running total. Thus without users having to specify the output type on the node, they would pick up the optimization.


Now, it seems to me like this would be a good compiler upgrade anyway, since there are plenty of people who might not notice an output configuation option on the Sum node and would drop the cast nodes anyway, and there's plenty of existing code out in the world that might benefit from the change. My question is: if LabVIEW had this optimization, would you still want the configuration option? The only reason I can imagine for still wanting the output configuration is for performance while debugging is enabled. Is that sufficient to desire this feature?

Knight of NI

Good idea.


Yes, I still would want the output configuration option. Most numeric function have it and, for consistency, all (of course only where it makes sense) should have it.


Like with other numeric function, it should be made clear to the programmer that the coercion to the new type is done before the operation, thus if the output is configured differently, a red coercion dot should also appear on the array input. (Analogous to the current behavior, where if you add two U8 values and configure the output to be U16, both inputs will show a red coercion and the operation happens in U16).

Proven Zealot

> Most numeric function have it


Say what?


[moments later, after looking at pop up menu and then property pages on Add primitive] Huh. Never noticed that option before.


Ok... I'll buy the "everyone should have it" argument.

Trusted Enthusiast
IMO this is not a weakness in the compiler per se, but rather a weakness in the primitive. It is common in cases where the output type is different than the input, such as the previously mentioned Boolean to (0,1). There is an existing feature in many primitives to handle this case cleanly, this is a request to add the same feature to a couple of primitives which seem like a natural fit.



I am not against compiler optimizations, but I would never cast then Sum when it would matter since it is wasteful. No old code would benefit in my case. As to new code, am I now supposed to know and remember all such optimizations so I know when to drop inefficient looking code and when to do the right thing? Once again, I am asking to make the right thing to do the easiest and best looking as well. I prefer the compiler guys work on taking good G to the next level.



Edit: too slow, I see AQ is now buying what I am selling...

Wow. I've been programming in LabVIEW since 4.0, and until today I had no idea I could select the output representation of some primitives like "Add".




Maybe some mention of this in the documentation is in order? Since this feature is already available on some primitives, I'll jump on the "everyone should have it" argument too.

Active Participant
If I remember correctly you can find it in the release notes of LabVIEW 8.5(?)