"Initialize Map" VI similar to "Initialize Array"

[_carl]

I find the process of initializing Maps in LabVIEW to be unintuitive and inconsistent with the initialization process for other similar concepts (such as, say, arrays).  After some initial trial and error, the process I've settled into for creating maps is to drop a map constant, and then to drag and drop the appropriate data types onto it for my key and value. I first looked for an Initialize Map VI (which doesn't exist) and then tried to create the constant by wiring up appropriate types to an "Insert Into Map" and creating the constant from there -- but this doesn't work as expected because the terminals don't update appropriately.

What drove me to coming to the forum today though, was that in creating a malleable VI with a map inside of it, I found a breaking point for the "drop constant and drag values into it" approach. Since the map data types need to be dynamic to support malleable VIs, I've had to get creative to get around that...

[wiebe@CARYA]

Of course you can make a vim that does this...

Question is should it be added to LabVIEW?

I'd use it.

[AristosQueue (NI)]

We considered and rejected this node when we made the sets and maps API. I will lay out the reasoning, but I will not close this idea. If enough people think the reasoning is flawed, they can add kudos for R&D to reconsider.

For creating dynamic typing in a VIM, our intended solution is the diagram disable structure around a Build Map node. Same applies to set data types. Indeed, there are many types in LabVIEW that you build by using diag disable around the code that would normally construct the value. This is an intended pattern. We only add a specific node when there's a reason to do this in regular (non-VIM) code. Your comment says "... in malleable VIs, etc." There isn't much of an "etc". It is Malleable VIs and template VIs (used in scripting) where you need the dynamic typing, and the diag disable structure supports those.

The reason not to have an explicit "Initialize Empty Map" node is to avoid adding complexity to the API. We don't need to have more items in the palette for people to learn if there's already ways of accomplishing that thing, unless that dramatically simplifies the code involved. Because the diag disable was already an established paradigm for type construction in malleable VIs before the introduction of sets and maps, and because VIM authors need to be generally aware of that technique anyway (queues, clusters, user events, etc), we didn't see any need to add something to avoid that for sets and maps.

If you are building up a complex type (eg. map of maps), there's only performance disadvantage to constructing the interim empty map, which is what would happen with an Initialize node. With the diag disable notation, the interim empty map is avoided entirely.

[_carl]

@AristosQueue, the thorough explanation is much appreciated.

Your comment says "... in malleable VIs, etc." There isn't much of an "etc". It is Malleable VIs and template VIs (used in scripting) where you need the dynamic typing, and the diag disable structure supports those.

Not exactly.  A dynamic initialize VI allows you to avoid defining data types twice, which is valuable in a normal VI.  If the type of value data gets updated, I currently also have to update the data type of the constant.  Typically this is just an annoyance because it will break a wire and I'll be alerted to the issue.  However, if the data types can be converted to one another, then there won't be a broken wire and I may be inadvertently converting data when storing it into the map (which could be a painful-to-track-down bug).

---

---

The reason not to have an explicit "Initialize Empty Map" node is to avoid adding complexity to the API.

---

I realize I'm repeating myself, but I honestly found the lack of an Initialize Map VI to be confusing when I first used maps. I also feel that it would add more value on the Map palette than, say, the "Convert Map to Array" and "In Place Map Access" items which really aren't necessary.

[wiebe@CARYA]

I think this is key:

We considered and rejected this node when we made the sets and maps API. I will lay out the reasoning, but I will not close this idea. If enough people think the reasoning is flawed, they can add kudos for R&D to reconsider.

The palette was deliberately kept simple. The to array was added because it isn't too obvious that this can be done.

Lots of functions can be made, but as this functionality is brand new, nobody knew what would be useful.

 So if enough people find this useful, it might still be added.

A dynamic initialize VI allows you to avoid defining data types twice, which is valuable in a normal VI.  If the type of value data gets updated, I currently also have to update the data type of the constant. 

I'll have to see this... I'm not sure what a dynamic initialize VI is?

[AristosQueue (NI)]

> A dynamic initialize VI allows you to avoid defining data

> types twice, which is valuable in a normal VI.

Carl, can you provide a picture of this scenario? The only situations that sound like what you're asking for that I could envision are all solved by creating a typedef of the map, and I'm confident that isn't what you were suggesting. So I need more context to understand, please.

[_carl]

‎05-05-2021 01:37 PM

> A dynamic initialize VI allows you to avoid defining data

> types twice, which is valuable in a normal VI.

Carl, can you provide a picture of this scenario? The only situations that sound like what you're asking for that I could envision are all solved by creating a typedef of the map, and I'm confident that isn't what you were suggesting. So I need more context to understand, please.

---

@AristosQueue, here's an example of what I was thinking:

[_carl]

> A dynamic initialize VI allows you to avoid defining data

> types twice, which is valuable in a normal VI.

Carl, can you provide a picture of this scenario? The only situations that sound like what you're asking for that I could envision are all solved by creating a typedef of the map, and I'm confident that isn't what you were suggesting. So I need more context to understand, please.

[fabric]

---

@AristosQueue (NI) wrote:

The only situations that sound like what you're asking for that I could envision are all solved by creating a typedef of the map

---

The more I use maps and sets the more uses I find for them.

Increasingly, I find myself coding small tasks by building a "temporary" map that leads to a compact implementation. For these cases I don't want to bother with typedefs. I just want to build a map, manipulate some data, then discard the map. 

Such use cases can easily be solved using typedefs, but they are the kind of typedefs that get named "data" or something just as meaningless. They have no context outside of the tiny piece of code they reside in, and shouldn't really need to exist in the first place!

[AristosQueue (NI)]

I see what you're talking about. That's not really equivalent to "Initialize Array"... that's just "give me an empty map of these types". The comparison to Init Array sent my brain down the wrong rabbit hole because initialize is about reserving space in the array data structure for later manipulation, which is why I said there's no equivalent. But you make a good demonstration on a use for "Empty Map" VIM. Likewise, "Empty Set". Thanks for the feedback. I'll update backlog notes.

(Tangent: In your picture, I assume that's your code today. You likely want to move those Index Array nodes inside the diag disable structure... they're just as much dead weight, but compiler will still generate code for them unless you've turned off debugging on that VI.)

[pauldavey]

A dynamic initialize VI allows you to avoid defining data types twice, which is valuable in a normal VI.  If the type of value data gets updated, I currently also have to update the data type of the constant.

 This is where you should create a TypeDef of the Key and/or Value of the Map, even if it is a simple data type.

[wiebe@CARYA]

A dynamic initialize VI allows you to avoid defining data types twice, which is valuable in a normal VI.  If the type of value data gets updated, I currently also have to update the data type of the constant.

 This is where you should create a TypeDef of the Key and/or Value of the Map, even if it is a simple data type.

Haven't made (nor needed) a typedef in ages.

But I do agree. A map either is ad-hoc, and the type can be a constant, or it's not and then it should 'live' somewhere. A typedef, or in the private data of a class: