"Cluster to Array" does not work for cluster of LVClass relatives

[Jim Kring]

The naive side of me expected that the Cluster to Array function would work for a cluster of relalative (sibling) LVClass types, upcasting the LVClass elements to the first common ancestor (e.g., I can use Build Array on related LVClass types and the output array will upcast, in the way I described). I'm I naive or is this a bug?

[Aristos Queue]

Try bundling a double and an int32. Then try to convert that cluster into an array. You'll find that you get a broken wire, not an array of doubles.

The cluster-to-array node requires identical types. Otherwise we'd have an ambiguous coercion dot -- a coercion dot that affects one or more data values within the cluster, but gives no indication about which ones. LV tries to avoid this. I don't see this as a bug.

You need to either

a) Upcast the two nodes before you bundle them in or

b) Specify a cluster type when you bundle the two nodes together that is a cluster of the common parent type.

[Jim Kring]

QUOTE(Aristos Queue @ Sep 13 2007, 06:41 PM)

Try bundling a double and an int32. Then try to convert that cluster into an array. You'll find that you get a broken wire, not an array of doubles.

The cluster-to-array node requires identical types. Otherwise we'd have an ambiguous coercion dot -- a coercion dot that affects one or more data values within the cluster, but gives no indication about which ones. LV tries to avoid this. I don't see this as a bug.

You need to either

a) Upcast the two nodes before you bundle them in or

b) Specify a cluster type when you bundle the two nodes together that is a cluster of the common parent type.

That's what I expected -- that LabVIEW does not have a "feature" that I need. Basically, I have a cluster of siblings and I want to iterate over them (without defining a redundant cluster of parents having the same size as the cluster of siblings). I guess I'll have to go the variant route... again. sigh...

[Aristos Queue]

QUOTE(Jim Kring @ Sep 14 2007, 12:06 AM)

That's what I expected -- that LabVIEW does not have a "feature" that I need. Basically, I have a cluster of siblings and I want to iterate over them (without defining a redundant cluster of parents having the same size as the cluster of siblings). I guess I'll have to go the variant route... again. sigh...

You made a good point, so I talked so some of the other owners of type propagation. There's still discussion going on, but I've filed the CAR (49F8C1J1). We'll see what comes of it.

[Jim Kring]

QUOTE(Aristos Queue @ Sep 14 2007, 10:34 AM)

You made a good point, so I talked so some of the other owners of type propagation. There's still discussion going on, but I've filed the CAR (49F8C1J1). We'll see what comes of it.

Thanks!

IMO, ambiguity of coercion is much less of a problem than not being able to program my application -- I'd rather have the problem of doing detective work to figure out which elements of the cluster are being coerced than to be completely restricted from attempting the ambiguous coercion.

Then, maybe the next issue would become: "how do we make the coercion dot less ambiguous and help the developer figure out the problem?"

Cheers,

[Tomi Maila]

QUOTE(Jim Kring @ Sep 14 2007, 08:06 AM)

That's what I expected -- that LabVIEW does not have a "feature" that I need. Basically, I have a cluster of siblings and I want to iterate over them (without defining a redundant cluster of parents having the same size as the cluster of siblings). I guess I'll have to go the variant route... again. sigh...

Hmm.... Would you like to share use the use case where you do use this cluster of siblings. It's not directly related to this issue but I'm just curious in what cases this particular data structure could be of benefit.

[Jim Kring]

QUOTE(Tomi Maila @ Sep 14 2007, 02:10 PM)

Hmm.... Would you like to share use the use case where you do use this cluster of siblings. It's not directly related to this issue but I'm just curious in what cases this particular data structure could be of benefit.

Yes, I would like to

But, all I can say is that it relates to dependency injection. I'll let you try to figure out the rest

[Tomi Maila]

QUOTE(Jim Kring @ Sep 15 2007, 01:26 AM)

Yes, I would like to

But, all I can say is that it relates to dependency injection. I'll let you try to figure out the rest

I hope this is an easier task than trying to understand all the little details of Aristos Queue's magical in-place map. Actually this reminds me that I still don't completely understand all the details of what not to do and why.

Hmm.. another thing popped into my mind. I wonder if the in-place memory structure could be used to lock a by-reference object when manipulating the content. Not that it currently can be but with a little additional features it could act as a diagram to protect against simultaneous access.

Tomi