BreakPoint
Rube Goldberg Code
So we have a front panel with six tiny icon images, each with an apparent size of 48x48 pixels. Peanuts, right? Wrong!
So why is the VI 3.6+ MB??? Each of the six (identical) images is actually 2448x2048 resized to 48x48 (try right-click...original size). That's a lot of hot air!
Actual: 30 megapixels
Effective: 14 kilopixels (2000+ times less!)
@altenbach wrote:
@jwscs wrote:
my very own (very small) rube goldberg
They are probably about equally good. It is likely that the "transpose" is actually not carried out at all, but the output data flagged internally to index the other way.
Effectively, yes, but fewer blocks means easier to read code. 🙂
(seen here in subVI "modbus responce.vi" (sic))
Like the guy behind the deli counter, some users think that thinly slicing a 1D array one element at a time is a good idea. For better inplaceness, i would probably use index array and maybe take the subset at the very end.
Also, if we don't wire the size of "delete from array", we get a single element as scalar, so code like seen above is overly complicated.
These two code fragments do the same thing!
If you ever want to see a literal translation of a text based program into "LabVIEW" (quotes are intentional!) ...
... have a look at the just posted example program to calculate the LCM (Least Common Multiplier) of an array of integers. Well, it seems to work, but why does it need:
- Four stacked sequences
- A couple of dozens local variables
- In fact, except for the two boolean controls show, all other terminals are lined up disconnected in the first outer sequence frame ( bottom picture)
- Every singe calculation reads from local variables and writes to other local variables.
This looks like an Aztec pyramid!
I was able to rewrite the entire thing as simple flat code of 20% of the size (and probably 1% of the complexity!) without any local variables and only a single sequence structure (for timing measurement. Try it!)
@altenbach wrote:
I was able to rewrite the entire thing as simple flat code ..;.
Posting a quick version here (LV 2013). Several optimizations are still possible, but I intentionally simplified certain things for clarity. There still needs to be verification (the input array cannot be zero) and error handling (if the solution is larger than the valid U64 range) and such. (there could be bugs, of course ;))
To create an array of four reference some think we need a FOR loop with four iterations, a case structure with four cases, an initialize array, shift register, "replace array subset", five reference (one in duplicate), all combined in a lot of code....
.... or we could just use "build array". 😄
@altenbach wrote:
To create an array of four reference some think we need a FOR loop with four iterations, a case structure with four cases, an initialize array, shift register, "replace array subset", five reference (one in duplicate), all combined in a lot of code....
.... or we could just use "build array". 😄
I suppose that if we got up to 25 refs on the BD, then this code would be smaller and the compiler would probably compile it out the same so it could save space?
@James_W wrote:
@altenbach wrote:
To create an array of four reference some think we need a FOR loop with four iterations, a case structure with four cases, an initialize array, shift register, "replace array subset", five reference (one in duplicate), all combined in a lot of code....
.... or we could just use "build array". 😄
I suppose that if we got up to 25 refs on the BD, then this code would be smaller and the compiler would probably compile it out the same so it could save space?
Even if you want to use a FOR loop, you would just keep the case structure and auto-index at the output tunnel. All that "Initialize array, shift register, and replace array subset, etc". adds significant extra bulk for no reason at all.
However, once you have a case structure with 25 cases, things are not easy to maintain or debug. There is a significant chance of mistakes.
As an alternative, you could simply get an array of all controls, autoindex on a FOR loop, then filter it e.g. based on label using a conditional output tunnel.
So we get 400 bytes of flattened little endian SGL data via UDP. Apparently the impression is that we need a screenfull of loop code with shrinking and growing arrays and such, duplicate local variables, incorrectly initialized shift registers, sequence structures, etc. ....
All we need is code the size of a postage stamp (the ptbypt filter is placed in a subVI here for simplicity)
Ah, the classical C to LV with variable declaration and all, the epitome of Localitis and Sequentitis. 🙂
/Y
