LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
DanyAllard

Context help on coercion dots to see what is the expected type

Status: Completed
Available in LabVIEW 2012

It could be nice to have a context help on coercion dots to see what is the expected type of the data that is supposed to be wired to. This way you can rapidly determine what kind of conversion to use to avoid the coercion dots.

 

ContextCoercionDots.png

 

LabVIEW ChampionArchitect
12 Comments
GregSands
Active Participant
You can always find the expected type by looking at the context help on the output wire.
altenbach
Knight of NI

That would certainly be helpful. However, it could get quite complicated for polymorphic functions or indicators that accept many datatypes.

 

For example if you wire a complex 1D array to a waveform graph, we get a coercion dot, but the accepted data type is a really long list, e.g.  1D or 2D arrays of DBL, EXT, I32, U8, waveforms, arrays of waveforrms, dynamic data, etc. etc.

 

I suggest to modify this suggestion a little bit and instead display the datatype to which the data is coerced to in each particular instance.

 

(GregS: I don't understand what you mean by "output wire". Where would that be in the figure above?)

Message Edited by altenbach on 06-11-2009 03:06 PM
GregSands
Active Participant

Oops, I might have been still half-asleep when I wrote that 🙂

InternationAL
Member

I don't think GregS has made it clear how to do this, so let's have this suggestion added.  I don't know how many times I've dropped a million conversion functions til I found the one that made the dot go away.  It's that, or having to open help, look up the data type, then go back to LabVIEW and make the correct conversion.  Either way is much more tedious than having the pop-up tell you the incoming data type and the coerced data type.  Kudos!

 

Hey, why can't you click on a coercion dot and have an "insert conversion function" option that would drop the appropriate conversion function and wire it up?  Even better!

Message Edited by InternationAL on 06-15-2009 08:16 AM
altenbach
Knight of NI

A coercion dot is not always worse than the conversion function and there are cases where the coercion is actually faster and more efficient than the explicit conversion. (I'll have to dig out an example and I'm sure I have one).

 

I tend not to insert explicit conversion unless the output branches into several coercions. Especially with scalars, the difference is negligible anyway. 😉

altenbach
Knight of NI

Here's a case where coercion is significantly faster than explicit conversion. The conversion forces another buffer allocation!
CoercionIsFaster.png
(code in this example simply zeroes all negative values of a 2D array)

 

Message Edited by altenbach on 06-15-2009 02:14 PM
JackDunaway
Trusted Enthusiast

altenbach,

 

You are collapsing my entire foundation of data coercion in LabVIEW. You mean, I NEED to leave coercion dots on large datatypes??? It is distressing to think that I need to benchmark "bad" programming practice against "good" because the "bad" may be more efficient.

 

From the help file on coercion dots: "Coercion dots can indicate points where a VI uses more memory and increases its run time." From altenbach: "Coercion dots can indicate points where a VI uses less memory and decreases its run time."

 

Why does the compiler not interpret both snippets the same?

 

If you do not post a product suggestion within the next few days, I may... As a habit, I eliminate the coercion dots just to pretty up the diagrams (even on scalars).

 

Regards, 

Jack

altenbach
Knight of NI

Hi Jack, Since I did not want to hijack (no pun intended!) this idea thread with a much more fundamental discussion, I started a new discussion in the LabVIEW forum. Let's continue the discussion over there. 🙂

 

Thanks!

G-Money
NI Employee (retired)
Status changed to: In Development
 
G-Money
NI Employee (retired)
Status changed to: In Beta