Earlier, I wrote this:
QUOTEThere are points in this graph where we are modifying a value on one wire which results in a change in value on another parallel wire.
That statement is FALSE. I made this statement because I really believed that was what was happening in the diagram. When everyone started asking, "Where is it?" I went back to study the diagram in detail, and had to think about each and every wire branch, and I realized I was wrong. I am sorry for leading you about on a wild goose chase.
I said that use of a parent class in the child class object leads to a hole in LV's dataflow safety.
I now retract that statement. There's still something at the back of my head nagging at me that a hole exists, but obviously the Map class doesn't demonstrate it. For now, assume the hole doesn't exist and this was just the fevered worrying of a developer who has spent too many years staring at LV class inplaceness and has become paranoid that some data-copy-bug is actively stalking him. At the moment, we have no known issues with this. Everyone who said, "I don't see why this should be a problem" was correct.
I also need to correct one other point about Always Copy primitive:This error results from my own poor understanding of a new LV feature. In the original posting of the Map class, I used some Always Copy primitives to force a copy of the constant's value before wiring it to a Swap primitive. This turns out to be unnecessary. Since the Swap prim is not something that modifies values, I thought that the swap would be inplace with the instance coming out of the constant, and thus would cause problems for the constant. Turns out that LabVIEW is smarter than that and the Swap prim will make a copy rather than stomp on the constant's value. So the Always Copy prim is not needed.
The rest of my comments -- the need for the Swap prims, etc -- appear to be correct.
Now, on to the rest of the questions...
QUOTE(Tomi Maila @ Aug 30 2007, 03:11 AM) To proove myself right here, I attach a version of AQ's map where all the in-place tircks are removed. And it appears to work.
I have decided that I didn't explain some aspects of this very well. Specifically, Tomi posted a version of the Map class with all the inplaceness tricks removed, which works fine, and he wanted to know why the inplace tricks are needed. So I have created a MUCH simpler example: the Linked List.
Download File:post-5877-1192399595.zipThis is a linear list of data, where it is easy to append to the start of the list without ever reallocating all the existing entries. To access items in the list, you have to traverse down the list -- there is no direct access the way there is with an array. I've gone with a very flat hierarchy for implementing this example so that the bare minimum number of VIs exist.
Just as with the Map, the key bit of magic is a child class that uses its parent class in the private data cluster. In this case, the parent class is Root and the child class is Node.
There are only four operations currently defined on the list:
- "Dump to string" allows the list to be shown as a string for debugging (so you can evaluate whether it is working right or not)
- "Insert at front 1" is one implementation of inserting at the front of the list
- "Insert at front 2" is a second implementation of inserting at the front of the list; compare the two implementations
- "Insert at index" walks down the list to a given index and performs an insert at that point
If you open Demo.vi you will see two link lists, one being inserted using version 1, the other being inserted using version 2.
Ok... so let me try to deal with a long list of questions that have been raised by the Map class. To begin with, the Swap block. Here are the block diagrams for LinkedList.lvlib:Node.lvclass:InsertAfter
1.vi and LinkedList.lvlib:Node.lvclass:InsertAfter
2.vi. (I used red text so you could see there was actually a difference in those two long names!)
In each picture, there's a point marked "A". In version 1, at point A, we make a full copy of the entire list. The information in the cluster is being moved out of one cluster and into another cluster. So LV decides there has to be a copy made so that the two clusters aren't sharing the same data. This defeats the purpose of the LinkedList which is supposed to do inserts without duplicating the list. In version 2, at point A, we use the Swap primitive, new in LV8.5. We take a default Root object and swap it with the contents of Next. Now the contents of the Unbundle are free to be put into a new cluster without duplicating all that data.
Tomi: Does that make sense?
QUOTE(NormKirchner @ Sep 26 2007, 03:08 PM) I'm confused as to why it is necessary to have the map node methods if they are never used, why not just have them at the branch node level?
The Map Node class is the parent for both Branch Node and Leaf Node. As such, it has to define the interface that both of the children classes must match. Map Node defines the API, and then Branch and Leaf implement it. In the simpler Linked List example, I have done away with the base case. I only have Root and Node, rather than a common parent for each of them. This decision not to have the common parent is a bad architecture decision in many cases because now if I want to have behavior on Root that does not apply to Node, I have no obvious place to put such code. As hierarchies get deeper, such decisions can lead to all sorts of weird hacks.
QUOTE(NormKirchner @ Oct 1 2007, 10:46 AM) Another thing that just came up, is in the CompareKey.vi.
Each of the comparison items needs to be a compare aggregates rather than elements.
This needs to be changed if the data type of the key becomes anything other than a scalar.
Any reason not to?
If the data type changes from String to LabVIEW Object (as I intend to be able to do in the next version of LV), then Compare Elements will still work just fine -- a class is a scalar as far as any operations on the class are concerned. The fact that there is data bundled together underneath to implement that scalar is hidden away.
Note: Do not take this comment as a reason to believe that we'll have class comparison working in the next version of LabVIEW. I may intend this happen, but then, I intended to have classes in 8.0, and we see what happened there...QUOTEAnother item that bubble sorted to the top was the input/output array in 'In Order Fetch Keys' needs to be an array of the the key data type rather than just an array of strings.
Yes. I missed that one.
------------------------
Ok. I think I'm caught up on the backlog of questions on this thread. If there are any I missed, please repost them.
There is simply no way a user can learn these techiques if there is not a very comprehensive introduction to these techiques. This is also true for the most advanced users like the ones here at LAVA.
