Wiring the 'N' terminal inside a For Loop

[Yair]

QUOTE(Justin Goeres @ Sep 12 2007, 04:17 PM)

Our local users' group last night had a presentation based on the http://zone.ni.com/devzone/cda/tut/p/id/6103' target="_blank">Tips and Tricks to Speed LabVIEW Development session from NIWeek. Since I missed that one at the conference, I went. On one of the slides, there was a new (to me) tip that wasn't part of the presentation.

Actually, I'm fairly sure you aren't the last ones to learn this.After Darren presented this session at NIWeek, both of us said that we were actually thinking (even before the presentation) of doing a nugget about this behavior. I guess Darren is more of a gentleman than I am, since I still have it in my list and I guess that means we decided that I would do it, but I didn't get around to it yet. Anyone else who wants to can do it instead.Of course, Justin, you would have to follow the NI forums to see those nuggets. :PBTW, this is also considerably better than the array size method because it will take into consideration all the indexing inputs of a for loop.

[jpdrolet]

QUOTE(crelf @ Sep 14 2007, 01:15 PM)

We just had a mini-debate here and came up with the answer that it is both a bug and a feature. I think that topic deserves its own thread

It seems to be a bug or at least an inconsistent feature... When evaluating Variant [Path "ABC"] == Variant [Path "abc"] it returns True which is the expected value on Windows, while flat data are different .

[Aristos Queue]

QUOTE(jpdrolet @ Sep 17 2007, 02:22 PM)

It seems to be a bug or at least an inconsistent feature... When evaluating Variant [Path "ABC"] == Variant [Path "abc"] it returns True which is the expected value on Windows, while flat data are different .

The rule is consistent: Variant equality tests "does the data inside this variant have the same behavior as the data inside this other variant."

On a case-insensitive platform, c:\ABC and c:\abc behave the same. So the two variants compare as equal.

On all the platforms, NaN behaves the same as NaN, so two variants containing NaN compare as equal.

This is not the same as comparing the contents of the two variants (otherwise you'd get NaN != NaN) nor as comparing the flat form of the data (where you'd get that flattened c:\ABC is not equal to flattened c:\abc).

[jpdrolet]

QUOTE(Aristos Queue @ Sep 17 2007, 04:37 PM)

The rule is consistent: Variant equality tests "does the data inside this variant have the same behavior as the data inside this other variant."

On a case-insensitive platform, c:\ABC and c:\abc behave the same. So the two variants compare as equal.

On all the platforms, NaN behaves the same as NaN, so two variants containing NaN compare as equal.

This is not the same as comparing the contents of the two variants (otherwise you'd get NaN != NaN) nor as comparing the flat form of the data (where you'd get that flattened c:\ABC is not equal to flattened c:\abc).

Thanks for the statement of the rule. Can you elaborate on other rules on Variant comparison? As to why the same data is stated different when hosted in different typedefs?

[Aristos Queue]

QUOTE(jpdrolet @ Sep 18 2007, 08:27 AM)

Thanks for the statement of the rule. Can you elaborate on other rules on Variant comparison? As to why the same data is stated different when hosted in different typedefs?

That's a type difference. To me it follows the same rule -- the data would behave different on the diagram at least insofar as you would get a coercion dot between data of the same typedef and data of different typedefs of the same type.

The characterization of the rule is, by the way, just my own statement of it. I don't own that code. This is just what I've derived from practice and reading between the lines of the documentation. The docs talk about the things that Variants are supposed to be able to do (sortable, for example) and that necessitates certain aspects of comparison.

Simple comparison is only going to tell you that two variants are different. If you want to know *how* they are different, use the Variant type analysis VIs in vi.lib: vi.lib\Utility\VariantDataType\

[Louis Manfredi]

QUOTE(rolfk @ Sep 15 2007, 02:38 PM)

Yes upgrade notes would not have worked. They are both in LabVIEW as long as I can remember, which is about version 2.5 or maybe the parse enum wasn't in there but at least 3.0. Possibly 2.2 for Mac only, had it already too.

Rolf Kalbermatter

Thanks Rolf-- makes sense, wasn't there when I first started with 1.x on the Mac, then I was away from LV awhile doing other kinds of engineering, then back at Version 3.x or so in Windoze, so it went from non-existant to old news without me noticing.

--Which just goes to show, my original point-- seems too bad that I have to rely on 3rd party sources of info, like LAVA, for this kind of thing. What other neat features are out there that I don't know about?

Best, Louis

[Gabi1]

QUOTE(Aristos Queue @ Sep 13 2007, 08:29 PM)

Here's one that works for any array data type. Call it the Monte Carlo method... I hope everyone understands that I put the False case of the case structure right above the True case in this image... this is not just a case structure hanging in space. :-) The value of the Boolean is always True.

http://lavag.org/old_files/monthly_09_2007/post-5877-1189708094.png' target="_blank">

Would be even slower if one would implement an exponentially decaying treshold, which would depend on the last nb that came out of the array

i love it. alough the queue is a tough competitor :worship:

[Rolf Kalbermatter]

QUOTE(Louis Manfredi @ Sep 18 2007, 11:09 AM)

Which just goes to show, my original point-- seems too bad that I have to rely on 3rd party sources of info, like LAVA, for this kind of thing. What other neat features are out there that I don't know about?

Well, such is life. Most things I found by accident, searching actively for something or through user groups/mouth of word/LAVA/Info-LabVIEW etc. and when then looking for them they were eventually somewhere in the printed or online docs, but it is simply to much material to read through completely.

I have long ago resorted to work with what I know and try to learn new things by various opportunities and simply not let myself be bothered that there are still many golden eggs out there that I do not know about. If I would have a photographic memory I would simply scan all the documents in a matter of flipping through them and rely on that, but alas, I'll have to do with what I can.

Rolf Kalbermatter

[Grampa_of_Oliva_n_Eden]

QUOTE(rolfk @ Sep 19 2007, 02:19 AM)

Well, such is life. Most things I found by accident, searching actively for something or through user groups/mouth of word/LAVA/Info-LabVIEW etc. and when then looking for them they were eventually somewhere in the printed or online docs, but it is simply to much material to read through completely.

I have long ago resorted to work with what I know and try to learn new things by various opportunities and simply not let myself be bothered that there are still many golden eggs out there that I do not know about. If I would have a photographic memory I would simply scan all the documents in a matter of flipping through them and rely on that, but alas, I'll have to do with what I can.

Rolf Kalbermatter

Yes.

Funny how things go around in circles.

So this is where the Upgrade notes, if exhaustive would make for a wonderful read.

Imagine if they upgrade notes read like the readers digest version of our Tips and Tricks!

Still dreaming, stil hoping.

Ben

[Louis Manfredi]

QUOTE(rolfk @ Sep 19 2007, 02:19 AM)

I have long ago resorted to work with what I know and try to learn new things ...

Rolf Kalbermatter

Of course, not such a bad approach-- once you've been programming in any language for a while, the trade-off between time spent learning the new (or old) features & shortcuts and time saved using them begins to heavily favor working with what you've got. At the absurd extreme, there isn't anything you can do with LabVIEW that couldn't be done programming a fast processor with perhaps an eight instruction subset of it's assembly language, given time to write code...

But this N terminal thing does seem basic enough that it ought to show up when you call for detailed help from the <ctrl-H> window.

Louis

[ned]

QUOTE(Louis Manfredi @ Sep 19 2007, 09:51 AM)

But this N terminal thing does seem basic enough that it ought to show up when you call for detailed help from the <ctrl-H> window.

I'm going to be a voice of dissent here and suggest that this is sufficiently basic that it doesn't need to be documented. You run a wire to the N terminal and you don't get a broken wire, so it must be valid LabVIEW code. What other value, other than the actual value of N, could possibly be a reasonable value on that wire?

[Grampa_of_Oliva_n_Eden]

QUOTE(ned @ Sep 19 2007, 12:55 PM)

... What other value, other than the actual value of N, could possibly be a reasonable value on that wire?

If you wire a constant "5" to the N form outside and also wire two arrays that are auto-indexed and one of the arrays has four elements and the other has three,

the inside N wire wire read "3" and NOT the "5" wired to the outside.

Ben

[Justin Goeres]

QUOTE(ned @ Sep 19 2007, 09:55 AM)

I'm going to be a voice of dissent here and suggest that this is sufficiently basic that it doesn't need to be documented. You run a wire to the N terminal and you don't get a broken wire, so it must be valid LabVIEW code. What other value, other than the actual value of N, could possibly be a reasonable value on that wire?

I think there are a couple things at play here that make this behavior interesting, and not "sufficiently basic that it doesn't need to be documented." One is what Ben said, namely that you can run a wire that appears to just be "through" the N terminal, but its value changes on the way past the N. The other is that there are apparently a bunch of us around here, representing dozens of people-years of LabVIEW experience, that weren't hip to this little gem. I think those two factors alone point to the behavior being not at all "sufficiently basic." As I pointed out in the first post, all of this is terribly obvious once you see it, but there's something about the behavior that's a bit outside the box and may not be obvious even after drawing 10,000+ For Loops.

Now, I don't think it should be in the Release Notes or anything (since it's apparently been this way for 10 years or more), but I think Ben's comment alone would be a worthwhile Note in the documentation. On the other hand, stuff like this clearly gives geeks like us something to get excited about, so maybe it's better left for us to discover :thumbup: .

Just to add a final snark: I'd question what other features of LabVIEW you think are "sufficiently basic that [they don't] need to be documented." Perhaps NI should remove the documentation of the Add and Multiply nodes from the LabVIEW help? They're awfully basic, and the order of the inputs doesn't even matter!

[Grampa_of_Oliva_n_Eden]

QUOTE(Justin Goeres @ Sep 25 2007, 09:00 AM)

...Perhaps NI should remove the documentation of the Add and Multiply nodes from the LabVIEW help? They're awfully basic, and the order of the inputs doesn't even matter!

When did that change? Are you sure? ( I swear I read the release notes!)

At one time the Advanced Course used to teach that the top input of a add node would be re-used while that was not the case with the bottom. So if you had a huge array that you needed to add an offset value to every value, the result would be put back in the same buffer used for the input terminal of the add node.

Is it any wonder why the buffer re-use rules are so hard to understand and apply.

Ben

[Aristos Queue]

QUOTE(Ben @ Sep 25 2007, 08:50 AM)

At one time the Advanced Course used to teach that the top input of a add node would be re-used while that was not the case with the bottom. So if you had a huge array that you needed to add an offset value to every value, the result would be put back in the same buffer used for the input terminal of the add node.

Sorry, Justin... Ben is right. When you're playing "hide the dots" on an RT system, order of terminals does matter.

[crelf]

QUOTE(Justin Goeres @ Sep 25 2007, 11:00 PM)

Perhaps NI should remove the documentation of the Add and Multiply nodes from the LabVIEW help? They're awfully basic, and the order of the inputs doesn't even matter!

Yes it does - you can control memory management through implaceness depending on how you wire them.

[Justin Goeres]

QUOTE(Aristos Queue @ Sep 25 2007, 08:13 AM)

Sorry, Justin... Ben is right. When you're playing "hide the dots" on an RT system, order of terminals does matter.

Is that a Note in the docs somewhere, then? (and yes, I am too lazy to look, thank you very much.)

You're all just piling on because I can't tell the difference between bits and bytes in that other thread, aren't you? Perhaps I'm losing my mystique.

[crelf]

QUOTE(Justin Goeres @ Sep 26 2007, 02:57 AM)

You're all just piling on because I can't tell the difference between bits and bytes in that other thread, aren't you?

Well, now that you mention it

[Grampa_of_Oliva_n_Eden]

QUOTE(Justin Goeres @ Sep 25 2007, 12:57 PM)

... Perhaps I'm losing my mystique.

Add some pointy spectacles to your avatar and you'll be restored in my book!

Seriously, I'm just piling on LV-Trivia as the oppertunity presents itself.

Ben

[TG]

QUOTE(Thang Nguyen @ Sep 12 2007, 06:31 PM)

@Ben: Could you tell me what is the format into string VI? I don't know about this . I have to you the property strings[] and array indicator to get the string of an enum.

@All: You guys are experts in LabVIEW, so if you have time, it's really helpful if you can list down these tricks in VI. I really want to learn more about these stuffs. It's hot :thumbup: .

Thang Nguyen

You are making a good point Nguyen.

I am always amazed at how little I know (the holes in my knowledge) and I been reading LabVIEW user manuals for years.

It would be really nice to see some of the little tricks of the trade explained here. Trust me they are not known by everyone.

Might save someone a lot of grief.

[Michael Aivaliotis]

QUOTE(TG @ Oct 20 2007, 04:22 PM)

You are making a good point Nguyen.

I am always amazed at how little I know (the holes in my knowledge) and I been reading LabVIEW user manuals for years.

It would be really nice to see some of the little tricks of the trade explained here. Trust me they are not known by everyone.

Might save someone a lot of grief.

This is why I spent a weekend a while back compiling this http://wiki.lavag.org/tips' and tricks" title='LabVIEW Wiki article on tips and tricks' alt='Wiki article on tips and tricks' style="border-bottom: 1px dotted #3366BB; color: #3366BB; cursor:pointer; text-decoration:none;" class="wiki">tips and tricks page. This is the whole point of the Wiki.