NI Home > Community > NI Discussion Forums

LabVIEW Idea Exchange

Showing results for 
Search instead for 
Do you mean 
Announcements
We've turned on a search before post feature in the LabVIEW Idea Exchange. This new feature will help cut down on the number of duplicate ideas in this space!

The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!
Darin.K

Output Configuration for Add/Multiply Array Elements

Status: New
by Trusted Enthusiast on ‎04-06-2012 04:56 PM

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

Comments
by Member kegghead on ‎04-06-2012 05:34 PM

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

by Active Participant StephenB on ‎04-08-2012 09:01 AM
yeah I CAR'd this several years ago and nothing has happened. So please kudo this!
by Trusted Enthusiast on ‎04-08-2012 09:15 AM

Stephen B: Can you post the CAR number?

by Knight of NI on ‎04-08-2012 12:19 PM

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!

 

by Trusted Enthusiast on ‎04-09-2012 09:22 AM

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?

by Knight of NI on ‎04-09-2012 09:36 AM

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

by Trusted Enthusiast on ‎04-09-2012 09:40 AM

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

by Trusted Enthusiast ‎04-09-2012 10:13 AM - edited ‎04-09-2012 10:14 AM
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...
by Member kegghead on ‎04-10-2012 08:02 AM

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.

by Active Participant GuenterMueller on ‎04-10-2012 08:25 AM
If I remember correctly you can find it in the release notes of LabVIEW 8.5(?)
Latest LabVIEW Idea Exchange Blog Posts
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!
Idea Statuses
Top Kudoed Authors
User Kudos Count
55
27
24
23
23