Coerce Dot on a String

[DJDDA]

"AdminPass" is the (string data type) value of a strict type definition. I've often been told that coerce dots are bad. The Unbundle By Name node is reading the value of AdminPass as stored in a file; in this particular case, the binary value needs to be shifted several places. Is this coerce dot indicative of a problem, or is this expected here?

Edit: Image


Message Edited by DJDDA on 12-04-2007 03:07 PM

[Ben]

"I've often been told that coerce dots are bad. "

That is how they are presented too noobs, and under many cicumstances they can be a sign of something bad.

Good or bad depends on were you find them and waht they are doing to you.

I think the only "global statement" I can make about them is that they are always a sign that LV is doing some type of conversion and you should think about what their presence means.

In this case, it is the typedef that is bringing ou the dot. A non typedef data type must be coerced into a typedef'd form.

So the image you shared is more of "FYI" than a "Watch out".

Ben

[DJDDA]

Ah, thank you!

(So there's no likely problem with coercing a string into a type def, right?)

[Ben]

yes, no negative.

Ben

Message Edited by Ben on 12-04-2007 03:50 PM

[altenbach]

---

Ben wrote:

In this case, it is the typedef that is bringing ou the dot. A non typedef data type must be coerced into a typedef'd form.

So the image you shared is more of "FYI" than a "Watch out".

---

It was always my impression that a coercion forces a datacopy. I would think this is also the case for typedef coercions (wild guess!).

Does anyone have more information? For example, if I am dealing with huge datasets, would such use of typedefs use more resources?

[Ben]

Hi Christian,

Take a look at this diagram.

It appears that coercion and buffer copies do not always go hand in hand. What puzzles me is why coercion in one case but not the other?

This is LV 8.2.1 BTW.

I'm stumped!

What do YOU think?

Ben

Message Edited by Ben on 12-05-2007 11:19 AM

[Ben]

Here are the files I used for the previous post.

Ben

[DJDDA]

Weird. The fourth "String" on the top structure's Bundle node should be acting the same as the fourth string on the bottom structure, right? I could try to justify the third one down, but the fourth one... ?

It's nice to know that I'm not breaking anything by having my one coerce dot, but now I'm curious about how this works!

[Ben]

Hi DJ,

I made a phone call and this is what I heard back (with some didaction (sp?)

---

Hi Ben,

   This is Noah from National Instruments.  I have been doing some more
   research into your question about the coercion dot with writing string
   values to Type Def string values.  I believe I have an answer for you.

   What we were seeing in your post was that the coercion dot was present
   basically whenever we had two different sources of the string going to
   the two separate Type Defs, or when the wire was “branched off” and the
   buffer allocation was showing up in the Match Pattern VI.

   After testing it out some on my own along with talking to some other
   engineers around me, I see a similar result, but I believe I have the
   reason why.  When the string is being written to the Type Def and coming
   from the same source, or not “branched off,” the coercion dot does not
   show up and the buffer allocations appear inside of the Bundle By Name
   function.  This is expected behavior because the cluster is just acting
   as a pointer to the actual data having the string data come from two
   different sources where it is “branched” means that the copy is created
   in memory before it reaches the Bundle By Name VI.  However, when the
   String data comes from the same source, the coercion actually takes
   place inside of the Bundle By Name VI.  I know that you said you were
   seeing this in LabVIEW 8.2.1, so I tested it out in 8.2.1 and 8.5.
   Using the Always Copy VI in 8.5, I can see that the coercion dots show
   up on the Bundle By Name VI like they do in the top portion of your VI.
   This VI simply forces the buffer allocations to be made before the
   Bundle By Name VI is reached.  So in summary, this is expected behavior
   and has to do with the fact that the source of the string data is coming
   from two different places, so the copies in memory are made before they
   reach the Bundle By Name VI.  I have attached an image that shows how
   this looks in 8.5 with the Always Copy VI and Buffer Allocations shown.

   I hope this answers your question and clears it up a little.  If you
   have any more questions, please feel free to call back and we can take
   this further.  Also, if you would like for me to post on the forum with
   this response, I will be more than happy to do so.  However, you are
   also welcome to post a response as you have been working on the forum
   already.  Please let me know if you would like for me to post my answer.
   Thanks and I hope to hear from you soon!

   Noah ...   National Instruments
   Applications Engineer

---

It will take some time to digest. If you can re-state this for the rest of us to understand.... Go for it!

Ben

[DJDDA]

"It will take some time to digest. If you can re-state this for the rest of us to understand.... Go for it!"

I'll take a shot at it: There's usually no coercion dot because the string that hits the Bundle node is really just asking to update the target of a pointer that's already in memory. However, when the functionality of a node dictates that it allocate new memory for its data, the Bundle node detects that the pointer is different and doesn't know that the data is identical; thus, it attempts to convert it, which doesn't hurt anything because it's already in the right form.

Right?