From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Darin.K

Output Configuration for Add/Multiply Array Elements

Status: New

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.

 

AddArrayOutputConfig.png

 

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

 

OutputConfigDialog.png

12 Comments
kegghead
Member

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

StephenB
Active Participant
yeah I CAR'd this several years ago and nothing has happened. So please kudo this!
Stephen B
AristosQueue (NI)
NI Employee (retired)

Stephen B: Can you post the CAR number?

altenbach
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!

 

AristosQueue (NI)
NI Employee (retired)

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?

altenbach
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).

AristosQueue (NI)
NI Employee (retired)

> 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.

Darin.K
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...
kegghead
Member

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".

 

add.png

 

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.

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