Rube Goldberg Code

[PeterFoerster]

Here's another small one:

The lower one simply isn't scalable. The picture shows the algorithm after cleaning it up.

[altenbach]

---

@PeterFoerster wrote:

The lower one simply isn't scalable. The picture shows the algorithm after cleaning it up.

---

Here's what I would do... 😄

 

[PeterFoerster]

Well, that's part of why I posted it here... Nice one!

At least now I know what the thing I get from quickdrop when wanting "index array" does...

Edit: Also, mine doesn't work for a single color. Then again, why would anyone need it to?

[RavensFan]

We've all seen Rube Goldbergs where the programmer copies the Index Array Function unnecessarily.  And we've seen where they go and wire up every index connector of the Index Array with a constant.

But I don't think I've seen this before where they continually add 1 to the array index in a long series to get the next element.  Just to make it even more painful, they actually added 1 every time and didn't even use the +1 increment function.  (You know, just to double the work that they had already expononentially created.)

Seen here

For bonus points, it also as the =True? comparison elsewhere in the VI.

[JÞB]

---

@RavensFan wrote:

We've all seen Rube Goldbergs where the programmer copies the Index Array Function unnecessarily.  And we've seen where they go and wire up every index connector of the Index Array with a constant.

But I don't think I've seen this before where they continually add 1 to the array index in a long series to get the next element.  Just to make it even more painful, they actually added 1 every time and didn't even use the +1 increment function.  (You know, just to double the work that they had already expononentially created.)

Seen here

For bonus points, it also as the =True? comparison elsewhere in the VI.

Just because,  I tried a BD clean-up The result was "amazing"  I would have shared a view of that with y'all except:

BEAUTIFUL! 

---

[Hooovahh]

Someone better not tell them the index is resizable, and defaults to getting the next element...or you know auto indexing loops.  Also using a double as the index made me cringe a little bit.

[JÞB]

Note to self:

Do not ever crash the CCT!  

After crashing and attempting to close LabVIEW the darn thing was still running.

After BLOWING LabVIEW away via Task Manager and re-opening LabVIEW I created a new Blank lvproj.  

Doesn't that look a lot like the CCT Dependancies list?

I'll be back after a reboot I guess.

[tst]

---

@JÞB wrote:

Doesn't that look a lot like the CCT Dependancies list?

---

Nope, or if it is, it is an extremely partial list, because the CCT has a bunch of VIs of its own and your scrollbar shows there isn't enough space there for those (not to mention that your dependencies list is a bit weird in that it doesn't show those VIs under the vi.lib folder, which it usually should. I think you might be seeing separate utility copies which LV might be using for itself?).

But yeah, the CCT was never optimized for large BDs. I tried quite a few years back and gave up when I saw the level of effort compared to the potential result (let's just say the NI picture control was not designed for effiency with raster images).

[altenbach]

(seen here)

Is the absolute value function really that hard to find? (Yes, the other case is just wired across).

[altenbach]

Flattening a U16 numeric to a little endian string is trivial, but some seem to need a screenful of code. (seen here) (The actual code contains several of these in parallel, this is just a small excerpt)

In other parts of the code they are reversing the operations with a similar detour, even invovling a matrix (!!!) datatype, no kidding! See for yourself.