From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
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:
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?
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).
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.