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.
Any idea that has received less than 3 kudos within 3 years after posting will be automatically declined.
It would be nice if LabVIEW handles the coersion automatically by inserting the required conversion function with inserted function in different color or in any other representation wherever possible so that user understands there is a coersion happening and in the same case we will not have performance pitfalls. Example scenario is show in the picture.
If the user still want the coersion, there can be an option of "Forced coersion" in the right click menu of the inserted function.
I certainly agree with the motivation behind this suggestion, as I am pretty much paranoid about coercion dots. However, I'm generally not a big fan of "auto" or "express" anything except maybe the auto tool selection. I do, however, love having convenient options.
What if this was a context menu option? There could be a direct link to the "Conversion" palette under the "Insert" menu:
Or the insert menu could directly refer to the proper conversion function:
i like the overall idea, but i don't think it should always happen automatically; for instance, there are many times i wire an indicator with a different value only to immediately change the type of the indicator to match the type of the wire. i'd be fine with a special mouse mode (via a keyboard modification) or with jim's idea of a fast menu option.
It would be nice if LabVIEW handles the coersion automatically...so...we will not have performance pitfalls.
Assuming explicit coercion is faster than implicit coercion is just an assumption. This snippet shows that implicit coercion outperforms explicit coercion by about 11% on my machine.
So, it might be better to keep the little red buggers around! Do I agree with this behavior? Not necessarily, but I think it's important to air misconceptions about coercion dots and ensure they are mitigated properly (where, sometimes, the proper mitigation technique is to let them remain).
A better link (which was a product of the above link I posted) goes into more detail about Dealing with Coercion Dots.
A good quote from there:
"Mindlessly throwing in a conversion operation is just covering things up with a bandaid. It's not solving the problem, but just deals with the problem more explicitely. The data still needs to be converted and possibly a new buffer allocated. You don't gain much! Of course if the wire branches to several coercion dots, converting once possibly makes sense.
The correct way to deal with coercion dots is deciding on a better representation for the data from the ground up an solve things upstream. Change the representation of the control itself! Rewrite the subVI to give the correct output repesentation! Whatever is most logical."
Very interesting, Jack... It looks like we should individually take the initiative to become LabVIEW mythbusters more often! This is a case that demonstrates how we should continually re-evaluate old habits for their validity.
My aversion to coercion dots goes back to a certain school of LabVIEW style that I'll leave unnamed.
It seems strangely unjust that explicit coercion often results in less efficient code... (, indeed!) I guess we shouldn't be surprised, though.
Any idea that has received less than 3 kudos within 3 years after posting will be automatically declined.