Wiring the 'N' terminal inside a For Loop

[robijn]

In most cases you can use this code for doubles. I think this is faster than any of your attempts so far !

[Justin Goeres]

This technically breaks the "no subVIs" rule, but I gave myself a pass because it uses recursion in LV85. It also takes a variant as an input .

EDIT: Yeah, yeah, the error wire should go into the recursive call. -5 points.

[crelf]

QUOTE(Justin Goeres @ Sep 13 2007, 11:42 PM)

This technically breaks the "no subVIs" rule...

That's delicious!

[LAVA 1.0 Content]

An alternative approach to array sizes:

Kevin

[Justin Goeres]

QUOTE(crelf @ Sep 13 2007, 07:08 AM)

That's delicious!

What's truly delicious is the amount of RAM it uses for large arrays! :thumbup:

This is the process info for Example.vi in my previous post:

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

All arrays are DBL.

Array of 1 element: 56.1 MB (roughly LabVIEW's baseline usage on my machine with this .lvproj open)

Array of 1000 elements: 80.2 MB

Array of 10000 elements: 1.3 GB and climbing when I killed the process

It should be noted that my test machine has (only) 1GB of RAM, so it entered Swap Hell a minute or so into the calculation (where the curve goes pretty flat at around 1.0 GB).

[crelf]

QUOTE(kevinP @ Sep 14 2007, 01:16 AM)

An alternative approach to array sizes:

:thumbup:

[Louis Manfredi]

QUOTE(Aristos Queue @ Sep 12 2007, 11:05 AM)

I don't think that would've helped for your enum example nor Justin's wire-the-N. Those have been in LabVIEW for a long long time.

--Well, if they've been around for a long while, certainly upgrade notes is the wrong place to point these features out. But, I've been around for a long while too, (dozen years or so with LabVIEW, CLD) and both features are new (and useful) to me. I geuss that's why I aways follow the LAVA traffic, but it would be nice if the NI documentation did a better job of showing this sort of thing to us. (I'm sure both are in the documentation and I'll find details on the enum one now that I know to look, but why did it take LAVA to let me know to look?)

Best Regards, Louis

[Aristos Queue]

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.

[crelf]

QUOTE(Aristos Queue @ Sep 14 2007, 04:29 AM)

Here's one that works for any array data type. Call it the Monte Carlo method...

I was hoping that you were using this to solve, but it looks like you're using this instead

PS: The "42 + 0i" is cute

[jaegen]

This is definitely my favourite so far.

Jaegen

[LAVA 1.0 Content]

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

Here's one that works for any array data type.

This one should also work for any data type. I do love me queues...

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

[PJM_labview]

QUOTE(Aristos Queue @ Sep 13 2007, 11:29 AM)

Here's one that works for any array data type...

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

This is not quite correct. If the array is an array of error cluster and if one of the error is the constant used on the BD (as unlikely as it seem) this may return the wrong result.

PJM

[crelf]

There's nothing like using a disk cache to determine array size:

I could make it polymorphic and determine the denominator by datatype, but I'm not that keen...

QUOTE(PJM_labview @ Sep 14 2007, 06:57 AM)

If the array is an array of error cluster and if one of the error is the constant used on the BD (as unlikely as it seem) this may return the wrong result.

Good catch!

[PJM_labview]

Here is another one that would probably win in the "slowest" category.

PJM

[jpdrolet]

QUOTE(PJM_labview @ Sep 13 2007, 04:57 PM)

This is not quite correct. If the array is an array of error cluster and if one of the error is the constant used on the BD (as unlikely as it seem) this may return the wrong result.

PJM

An error cluster won't match because the type is different, I32 vs CDB for the "error code". To be sure to have a different type, index an array element and bundle it in a cluster for variant comparison.

By the way, anyone ever wondered why error code 42 is "Generic Error" ???

[Jim Kring]

QUOTE(jpdrolet @ Sep 13 2007, 03:48 PM)

By the way, anyone ever wondered why error code 42 is "Generic Error" ???

It is the http://en.wikipedia.org/wiki/The_Answer_to_Life,_the_Universe,_and_Everything' target="_blank">Answer to Life, the Universe, and Everything.

[PJM_labview]

QUOTE(jpdrolet @ Sep 13 2007, 03:48 PM)

An error cluster won't match because the type is different, I32 vs CDB for the "error code".

Oops, and I though I looked at the code carefully enough... You are correct, this is not an error cluster.

PJM

[CaseyM]

QUOTE(jpdrolet @ Sep 13 2007, 03:48 PM)

An error cluster won't match because the type is different, I32 vs CDB for the "error code".

True, but it's noteworthy that using this method you can still get an incorrect result if you happen to have an array that contains the same element that you append to the very end of the array.

[Aristos Queue]

QUOTE(cmay @ Sep 13 2007, 07:13 PM)

True, but it's noteworthy that using this method you can still get an incorrect result if you happen to have an array that contains the same element that you append to the very end of the array.

Yeah.... I should've put a typedef'd enum into the cluster -- same trick that the GOOP Toolkit uses to create a guaranteed unique datatype. But I figured this was pretty close to sufficient, and I didn't take the time. Just pretend that I typedef'd the cluster itself -- that'll keep the variant comparison from claiming the two values are equal unless someone is deliberately trying to break the VI by using the VI's own typedef. ;-)

[crelf]

QUOTE(Aristos Queue @ Sep 14 2007, 12:30 PM)

Instead of a cluster, use an empty array.

...or use a DBL that's an NaN (NaN != NaN).

[Grampa_of_Oliva_n_Eden]

QUOTE(crelf @ Sep 14 2007, 10:02 AM)

...or use a DBL that's an NaN (NaN != NaN).

But that becomes an issue if the cluster was a typedef since the defualt value of typedef'd constants will not retain their default if the typedef is editied.

Ben

[jpdrolet]

QUOTE(crelf @ Sep 14 2007, 10:02 AM)

...or use a DBL that's an NaN (NaN != NaN).

You need a comparison that would match TRUE if and only if compared the appened element. NaN will be different from all elements including the appened one.

However, while NaN != NaN, you will find unexpectedly that Variant[NaN] == Variant[NaN]. Is that a bug or a feature? It seems that variant comparison strictly requires the same type but makes a typeless comparison on flat data.

[shoneill]

QUOTE(tcplomp @ Sep 12 2007, 08:05 PM)

Well that's what the http://forums.ni.com/ni/board/message?board.id=170&message.id=267659&page=1&view=by_date_ascending' target="_blank">NI forums is for in dept problem generation instead of solving

Ton

In fairness, the NI forums didn't create the problem, it only highlighted it. I had some email communication with ben about a year ago on this subject.

If anyone knows of a method to get the array size of an array via reference, please let us know. My preferred method is casting the "VALUE" to an array of variants, and using the "Array size" on this......

Or using the OpenG version of stripping it from the variant VALUE string itself.....

Shane.

[crelf]

QUOTE(jpdrolet @ Sep 15 2007, 01:33 AM)

...while NaN != NaN, you will find unexpectedly that Variant[NaN] == Variant[NaN]. Is that a bug or a feature?

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

[Rolf Kalbermatter]

QUOTE(Louis Manfredi @ Sep 13 2007, 01:21 PM)

--Well, if they've been around for a long while, certainly upgrade notes is the wrong place to point these features out. But, I've been around for a long while too, (dozen years or so with LabVIEW, CLD) and both features are new (and useful) to me. I geuss that's why I aways follow the LAVA traffic, but it would be nice if the NI documentation did a better job of showing this sort of thing to us. (I'm sure both are in the documentation and I'll find details on the enum one now that I know to look, but why did it take LAVA to let me know to look?)

Best Regards, Louis

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