Replace "Coercion dots" through corresponding conversion function supported by LabVIEW

[ReneW]

If LabVIEW shows coercion dots, I usually insert the corresponding conversion function (as recommended).

Some times it is a little bit annoying to seek the correct function. Especially because I know that LabVIEW knows the desired data type. If I connect the wire to a VI I have to look up the correct type in the context help. Afterwards I have to seek and insert the corresponding conversion function.

I think that LabVIEW should support this replacement a little bit more.

I suggest an interactive support:

  a) If you click on the coercion dot LabVIEW should show a little dialogue and suppose to insert the corresponding conversion function.

  b) If you right click on the corresponding wire the context menu should purpose the corresponding conversion function more directly (see pictures).

New: 

 Old:

[JackDunaway]

---

@ReneW wrote:

If LabVIEW shows coercion dots, I usually insert the corresponding conversion function (as recommended). 

---

From here (and also reference Dealing With Coercion Dots😞

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

[ReneW]

I read the Dealing With Coercion Dots from JackDunaway and saw the green dots. Now I see another another possibility to handle the Coercion Dots:

Instead of inserting the corresponding conversion function, it should be possible to confirm the conversion. The color of such a confirmed conversion dot would change from red to green. This could be done through mentioned methode a): click on the coercion dot... . With a second click on the dot it could be turned back to red again.

[JackDunaway]

---

@ReneW wrote:

Instead of inserting the corresponding conversion function, it should be possible to confirm the conversion. The color of such a confirmed conversion dot would change from red to green. This could be done through mentioned methode a): click on the coercion dot... . With a second click on the dot it could be turned back to red again.

---

I like your idea about changing the color of the coercion dot to a "less angry" color for mitigated coercions. I made a similar suggestion that was met with tepid enthusiasm. A quote from that thread:

"...perhaps even allow the developer to associate permanent comments with Coercion Dots (e.g., to explain mitigated coercions)."

[GregSands]

Jack, I tried your implicit/explicit conversion code, being somewhat surprised that there was a significant difference.  I not only had a similar difference, but if you change your code slightly to remove the NaN computed on the first iteration, the difference is more like 60%!  That is, implicit is 10ms and explicit is 16ms!!!  Mind you, moving the explicit/implicit case outside the For Loop decreases this to 9.5ms vs 12.5ms.  So there's a few things interplaying to give this difference in speed, but I'm still concerned that the explicit conversion is slower.

I wonder whether a better idea to suggest is that the numeric conversion primatives are fixed so that they are at least no slower than implicit coersion.

[Diya]

A very similar idea has already been posted and the explanation for that has been given.

find the comments on this thread Automatic Coersion Handling wherever possible

[LuI]

I prefer to insert an explicite coercion at a position it fits best. It is better to choose the right data type right from the beginning or to convert it 'near the source' rather than having it converted several times near each consumer node...

[Manzolli]

Good point LuI! It depends on the code, if you have many coercions from a single source, it would be much faster do it once, at the source, with the correspondent implicit function, as LuI said. But, if there is only one destination with coercion, looks like it will be faster if the coercion is made automatically. Am I right?

LuI