Is a data wire a node ?

[Eugen Graf]

Is a data wire a node ?

I think a node shoud have:

Input

Output

Functionatity

A wire has it (Funktionality is the tamporary saving of data value).

What do you think about it?

[crelf]

QUOTE (Eugen Graf @ Jun 9 2008, 08:45 AM)

Is a data wire a node ? I think a node shoud have: Input, Output, Functionatity. A wire has it (Funktionality is the tamporary saving of data value). What do you think about it?

No, it doesn't. I see it as a pointer back to the output of the last node. That said, LVOOP wires might be considered differently, as branches instantiate?

[Eugen Graf]

QUOTE (crelf @ Jun 9 2008, 03:01 PM)

No, it doesn't. I see it as a pointer back to the output of the last node. That said, LVOOP wires might be considered differently, as branches instantiate?

Ok, a pointer, not a "C-local variable"?

Or is it like this?

struct inputs1;

struct inputs2;

struct outputs1;

struct outputs2;

and if i call a SubVI, than

VI2(inputs2)

{

return output2=0

}

VI1(inputs1)

{

return output1 = VI2(inputs1);

}

and so on. I think you understand what I mean.

Thank you

[shoneill]

QUOTE (crelf @ Jun 9 2008, 03:01 PM)

No, it doesn't. I see it as a pointer back to the output of the last node. That said, LVOOP wires might be considered differently, as branches instantiate?

All branches can cause data copies. The only difference is that a LVOOP copy (By reference to its class) includes references to methods.

Otherwise no different from any other branches really.

Shane.

[crelf]

QUOTE (Eugen Graf @ Jun 9 2008, 09:03 AM)

Ok, a pointer, not a "C-local variable"?

Can't help you there - it's be far too long since I've used C. If you want to make a point, I'd prefer it if you could without referencing other languages - try describing it instead.

[crelf]

QUOTE (shoneill @ Jun 9 2008, 09:19 AM)

All branches can cause data copies. The only difference is that a LVOOP copy (By reference to its class) includes references to methods. Otherwise no different from any other branches really.

Good point.

[Aristos Queue]

A wire is equivalent to a C++ const variable declared on the stack. In other words, it is a variable that you can only assign to once.

Nodes are the functions that read those variables and write new variables.

Having said that, a wire that forks is a bit different. This

NodeA ------------------+----------------NodeB                        |                        |                        |                        +----------------NodeC

is equivalent to this:

NodeA ------------- CopyNode--------------NodeB
                        |
                        |
                        |
                        +----------------NodeC

[crelf]

QUOTE (Aristos Queue @ Jun 9 2008, 10:45 AM)

Nodes are the functions that read those variables and write new variables. Having said that, a wire that forks is a bit different. This... is equivalent to this...

So a wire isn't a node, but the act of branching can be considered a node?

[Aristos Queue]

QUOTE (crelf @ Jun 9 2008, 10:15 AM)

So a wire isn't a node, but the data associated to the act of branching can be considered a node?

More exactly, the *act* of copying data can be considered a node. Wires are data. Nodes are actions. Specifically, nodes are actions on that data.

[LAVA 1.0 Content]

QUOTE (Aristos Queue @ Jun 9 2008, 11:25 AM)

More exactly, the *act* of copying data can be considered a node. Wires are data. Nodes are actions. Specifically, nodes are actions on that data.

But not all branches are data copies. Ex: Get array size (does not mod data) can be scheduled before array is used.

Ben

[crelf]

QUOTE (Aristos Queue @ Jun 9 2008, 11:25 AM)

More exactly, the *act* of copying data can be considered a node. Wires are data. Nodes are actions. Specifically, nodes are actions on that data.

Right - that was what I was thinking, but not typing I appreciate your elloquence.

[Eugen Graf]

Thank you all for explanations.

Regards, Eugen

[Justin Goeres]

QUOTE (Aristos Queue @ Jun 9 2008, 08:25 AM)

More exactly, the *act* of copying data can be considered a node. Wires are data. Nodes are actions. Specifically, nodes are actions on that data.

So the dot at the junction (if you have show dots at wire junctions turned on) is (or can be) a node. How delightfully literal!

[Eugen Graf]

And what is with tunnels ?

[Yair]

QUOTE (Eugen Graf @ Jun 9 2008, 10:51 PM)

And what is with tunnels ?

The wires on separate sides of the tunnel are not the same wire.

[Eugen Graf]

QUOTE (Yen @ Jun 9 2008, 09:56 PM)

The wires on separate sides of the tunnel are not the same wire.

So a tunnel will copy the data from one wire to other and is a node at all because of copy action ? Ok.

Is a input or output of a subvi a node? Do it copy data? I think no, but I am not sure.

[crelf]

These are all great questions Eugen, but I'm interested in why you want to know - what are you up to? :ninja:

[Eugen Graf]

QUOTE (crelf @ Jun 9 2008, 11:17 PM)

These are all great questions Eugen, but I'm interested in why you want to know - what are you up to? :ninja:

I think you know it, I want to write my tutorial and have to know these things to be sure what I write.

[crelf]

QUOTE (Eugen Graf @ Jun 9 2008, 05:21 PM)

I think you know it, I want to write my tutorial and have to know these things to be sure what I write.

Oh - Okay - I didn't know that you were writing a tutorial. Good luck!

[Yair]

I'm not sure you should get so hung up about the term "node". Personally, I think of any structure, primitive or subVI as nodes, but if you take Stephen's C++ analogy ("Nodes are the functions that read those variables and write new variables") then the answer to your question is yes, because the wires are separate.

Personally, I don't think this level of detail should go in most tutorials and you can probably find better terminology.

As a side point,

QUOTE (Eugen Graf @ Jun 9 2008, 11:46 PM)

So a tunnel will copy the data from one wire to other and is a node at all because of copy action?

Is a input or output of a subvi a node? Do it copy data?

In both cases, a copy of the data may be made, but LabVIEW tries to optimize the memory usage and reuse existing buffers when possible instead of allocating new ones. This can happen both in case structures and in subVIs and is not always easy to predict. If you want more data, a search for "inplaceness" should reveal all kinds of stuff.

[Aristos Queue]

QUOTE (Eugen Graf @ Jun 9 2008, 04:21 PM)

I think you know it, I want to write my tutorial and have to know these things to be sure what I write.

This isn't the kind of information I would ever put into a tutorial for beginners. It's theoretical information for folks who are interested in language theory. I can pretty much guarantee -- based on almost a decade of teaching LV to programmers of C++ -- that it would be very unhelpful to get any programmer to actually think of wires as variables. It doesn't work to think of the dataflow that way. You'll end up with people dropping controls as a way of "instantiating" a variable (i.e. giving a wire a starting point). Trust me on this. I've seen it happen more than once.

LV is best explained as data which flows from node to node, and noting the wires merely as connections between nodes. Don't try to get into any "a wire is a variable" nonsense.

QUOTE (Eugen Graf @ Jun 9 2008, 03:46 PM)

So a tunnel will copy the data from one wire to other and is a node at all because of copy action ? Ok.

A tunnel is neither a node nor a wire. A tunnel is a tunnel. And depending upon what structure that tunnel is on, it has different behavior. A tunnel on a sequence structure is a no-op. A tunnel on a loop is not. But you cannot define a tunnel in terms of "variable" and "function". It is a director in the dataflow.

QUOTE

Is a input or output of a subvi a node? Do it copy data? I think no, but I am not sure.

A subVI call does not copy data, though it may be what causes a forking wire to decide to copy of data.

[crelf]

QUOTE (Aristos Queue @ Jun 10 2008, 02:26 PM)

You'll end up with people dropping controls as a way of "instantiating" a variable (i.e. giving a wire a starting point).

Or enabling datasocket on FP controls as a method of passing data around its own BD...

[Rolf Kalbermatter]

QUOTE (Aristos Queue @ Jun 10 2008, 02:26 PM)

LV is best explained as data which flows from node to node, and noting the wires merely as connections between nodes. Don't try to get into any "a wire is a variable" nonsense.

I have an electrical engineering background and when I first encountered LabVIEW the similarity of it's diagrams with an electrical schemata was what made it very easy for me to grasp the idea and even like it very much. The rest was just getting used to specific LabVIEW ideas such as how loops, cases and such were done and here traditional programming theory from my Pascal days which used to be thought in rather formalistic ways back in those days helped of course.

Thinking of wires as variables only occurred to me later when I tried to come up with explanations of how LabVIEW works but it never struck me as something elegant and I never really tried to push that idea much further.

Rolf Kalbermatter

[crelf]

QUOTE (rolfk @ Jun 21 2008, 05:29 AM)

I have an electrical engineering background and when I first encountered LabVIEW the similarity of it's diagrams with an electrical schemata was what made it very easy for me to grasp the idea and even like it very much.

I used to use that analogy when I was introducing EEs to LabVIEW until one day when one of them really got hung up on what the voltage (value) was on a wire before the dataflow got to it. I tried in vein to explain it to him, but he just never got past that.

[Rolf Kalbermatter]

QUOTE (crelf @ Jun 21 2008, 07:14 AM)

I used to use that analogy when I was introducing EEs to LabVIEW until one day when one of them really got hung up on what the voltage (value) was on a wire before the dataflow got to it. I tried in vein to explain it to him, but he just never got past that.

Ahh well! Some people are sometimes so hung up about something they can't see that it's just a good or sometimes not so good analogy. Guess he wasn't into software at all, so that may explain it a bit.

I did know programming as it was part of my study and I wasn't to bad in it either. Just never really liked it very much until I encountered LabVIEW.

Rolf Kalbermatter