How to send multiple clusters of data to consumer queue?

[Bob_Schor]

It's a "sure thing", telling you that it has done the conversion for you.  However, I'm "allergic" to Coercion Dots, so I frequently will insert the "To Variant" function in there, anyway ...

Bob {Allergic} Schor

[James.M]

---

@Bob_Schor wrote:

It's a "sure thing", telling you that it has done the conversion for you.  However, I'm "allergic" to Coercion Dots, so I frequently will insert the "To Variant" function in there, anyway ...

---

Personally, I leave coersion dots all over the place. Do you have a link to somwhere showing how much of a processing impact they have?

[Ben]

---

@James.M wrote:

---

@Bob_Schor wrote:

It's a "sure thing", telling you that it has done the conversion for you.  However, I'm "allergic" to Coercion Dots, so I frequently will insert the "To Variant" function in there, anyway ...

---

Personally, I leave coersion dots all over the place. Do you have a link to somwhere showing how much of a processing impact they have?

---

Coercion dots are a "look here!" message to the developer to let us know we should think a little bit about what is going on.

In some cases coercion dots are a warning we may loose info.

In other cases we may get things screwed up (cast an enum for the wrong data type)

In others it may flag a performance hit (building an aray of doubles inside a For loop only to latter stuff them into an array of singles)

But in other situation LV may actually be doing the conversion the way we intend and we get the same result as if we do an explicit conversion.

In that last case, in older versions of LV, I did benchmarks and found the implied coercion was actually faster.

So as I started thsi reply, Coercion dots are there to get our attention and invite us to think about what is happening. They are not by default bad and in some cases, may actually give better performance.

Ben

[Bob_Schor]

The following is without data, but with "logical thinking" -- from the descriptions of coercion dots, what they are and what they mean in the LabVIEW context, my "logical inference" is that they have no, or (as the Mathematicians would say, "a set of Measure Zero") influence on the speed of compilation or the speed of the resulting code (in comparison to putting the explicit Convert to X function on the wire to "coerce" (I prefer "change the type of) the input wire to the input connector.

However, I find that (for me, Your Milage may Vary) having the explicit Conversion function is helpful as a reminder or documentation aid to what is being done.  The specific case being discussed here, Convert to Variant, is the "Exception that Proves the Rule".  But consider numeric types.  If you wire a Dbl into an input that takes Sgl, you potentially will lose precision in your calculation.  A coercion dot does not warn you of this (unless you pop up on the wire to see why the dot exists), but a "To Single" tells you that you are losing precision.  A similar situation exists with the various byte sizes of the Integer Types.  I also use both Signed and Unsigned integers.  For example, many counters use a U32.  I use such a counter to register a delay (in milliseconds) -- with 32 bits of precision, I can get a delay up to 49 weeks (or is it 49 days?  Anyway, a long time).  We use this delay in an Excel Worksheet to control behavior testing studies, and here I use signed integer, which lets me say that a delay of -1 is an "infinite delay" (because in the context of the running program, a delay of 49 weeks is a good approximation to an Infinite Delay).  It is much easier writing "-1" than the number 2^32 - 1, and easier to do an arithmetic test (Delay < 0) on the signed representation.  When I go to use it, however, I convert it back to the "correct" U32 type.  Keeps the code more transparent and self-documenting, at least for me and my students.

Bob Schor

[James.M]

Thanks for the clarification, Ben!

Bob, have you started an Idea Exchange topic to add a right-click option to insert the relevant conversion node for numerics when there's a coercion dot? e.g. DBL coerced to U8, right clicking wire menu shows "Insert To Unsigned Byte Integer Node" option. This might become moot with the new custom right-click stuff in 2015, though.

This would motivate me to get rid of coercion dots because usually I know they're fine and I'm lazy. I have run in to issues where I use a "<0" comparison when I forgot to convert to a signed integer, but the small amount of debugging these require to fix isn't enough to motivate me just yet 

[Hooovahh]

To me coersion dots can be similar to errors.  It is fine if you decide to ignore errors, but I like to put in the clear errors, to show that I am clearing and ignoring these errors intentionally.  If I see someone just not using the error wire between nodes they might be missing important information.  But if I see clear errors (where appropriate) then I know that the developer was at least thinking about how errors should be handled.

If I see a coersion dot it makes me question if the developer knew what they were doing and did it intentionally, or if they didn't realize the consequence.  As a result I almost always have explicit conversions, but with variants I tend to not have them everytime.