Forensic LabVIEW Archaeology

[altenbach]

After looking at the code posted by Darin.K here, I thought it would be fun to do forensic archaeology on code like that. The example finder and vi.lib still has pleny of pre-LabVIEW 5 code fragments here and there.

How much can we really tell by looking at old code (or front panels?)

Some telltales:

1. Consistent use a "continue if true" loop conditions. (Stop if true did not exist back then).
2. No modern style front panel objects.
3. Consistent use of multiple "output size=1" index arrays as we see here (Index array was not always resizeable).
4. The direct wire of the error to the case selector as we see here is however a newer development. Maybe the code received some maintenance at one point?
5. The excessive use of stacked sequences made somewhat sense on the old 640x480 (or even 1024x768) monitors.

(On a side-note, long ago I have found that "complex to (r;theta)" is less efficient if you are only interested in the magnitude. Bettter is "absolute value".)

Is there a good summary table listing the major advancements for each version? (there are the upgrade and release notes of course, but it is a bit scattered).

Anyone remember for example...

• When did attributes nodes change to property nodes?
• When was the major internal algorithm change for FFTs?
• When did the gmath toolkit become part of LabVIEW? (Hey, I still have it listed as a seperate registered product on my-NI. :D)
• ...please post similar questions....

[Darin.K]

When I see this, I tend to think old-school.

As to the questions, the only one I can think of off the top of my head is that attributes nodes probably went away with the advent of the VI server in LV5.

In LV2 is what not uncommon to have controls on the right side of a subVI to accept values from the sequence locals.  Plus in the good old single threaded days, if there was a problem with execution order of your VI you could just nudge a subVI a little to the right or left to get it just right.

[altenbach]

OK, having some friday afternoon fun, I posted this solution, then I was wondering how unflatten 24bit pixmap actually does it.

Wow, this code is old!!! Again, index array was not resizable, so we needed three instances of it and calculate the incremented positions for the second and third index. Then we convert the three U8s to U32s, shift some of them (some are shifted by 0, a NOOP!) and add them all up at the end.

I get the same result by simplifying the code significantly (bottom). 😄

I would guess it is faster and more efficient. Maybe I should do some benchmarking. 😄

 

EDIT: nah, my version is only about 15% faster. Not really worth it. 😉

PS: I made also a loop-free version (decimate...join...reshape) which seems even faster by a few percentages. There is probably some slack left. ;)).