Design challenge: find biggest block of true in boolean array

[Florian.Ludwig]

Hi dear LabVIEW experts,

with the VI below I'm finding the biggest block of consecutive true elements in a boolean array.

But as this will be performed on thousands of arrays which will have 2 to 3 million elements each, I can't help but think: There must be a better implementation. 🙂

Could you please point me in the direction of a better way to do this? Some neat trick I haven't thought of myself yet?

Regards Florian

[GerdW]

Hi Florian,

here's a different approach:

Comments:

- find block and calc length of current block

- compare with stored results (length) and take new values, if bigger block is found

[Florian.Ludwig]

Hi,

thanks for that suggestion!

It's a good idea to do it all within the loop - sometimes I just miss the obvious.

I've put our solutions into a benchmark vi. Yours is faster than mine 2,23 ms vs. 2,65 ms per array. I made some modifications to your code because it showed different results.

I've also added a 2nd idea of mine - but it really sucks 36,93 ms!

I must say that I originally thought my 2nd implementation would be slower, but I really wanted to know for sure. 🙂

Any other suggestions? Anyone?

Regards Florian

[smercurio_fc]

Gerd's solution has a very slight error in calculating the size of the block. Missing a +1.

Here's another variation. Runs about the same as the others in terms of speed.

[Florian.Ludwig]

Thanks for posting,

but I'm afraid I introduced that bug into Gerds code

Sorry about that - fixed it.

Both of your snippets look pretty lean. I doubt much improvement could be made.

I was hoping for some "trick" though

altenbach?

Regards Florians

[JW-JnJ]

---

@Florian.Ludwig wrote:

I was hoping for some "trick" though

---

Challenge Accepted!

[Florian.Ludwig]

Nice,

this really saves a lot of diagram space!

It is similar to my 2nd idea - but the execution is better.

On my machine it is ten times slower than the two earlier posts by GerdW and smercurio though.

Regards Florian

[smercurio_fc]

The reason why it's slower is because it forces you to iterate through all of the array elements. Gerd's and my solution don't do that. They only loop for as many "blocks" that you have. I believe your example array had 3 blocks, so the loops only run that many times, which is way smaller than 2,000,000.

A good example of why smaller diagram code does not necessarily equate to faster or more memory efficient code. In fact the code also creates another array of 2,000,000 elements (of integers).

[Florian.Ludwig]

Hi,

you are of cause right smercurio. That's exactly the reason why I expected my second approach and JW-L3CE's to be slower.

The trick I was hoping for would not use a loop at all I guess. I remember the time when I learned that many operations can be performed on arrays without looping through the data.

I was hoping for a similar eye opener like back then. Ahhh the good old days

Regards Florian

[altenbach]

---

@smercurio_fc wrote:

Gerd's solution has a very slight error in calculating the size of the block. Missing a +1.

Here's another variation. Runs about the same as the others in terms of speed.

---

I would probably only keep the largest size and it's index in a shift register. building large arrays at the loop boundary just to later throw away everything except one element each seems expensive.