LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Design challenge: find biggest block of true in boolean array

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

0 Kudos
Message 1 of 37
(3,506 Views)

Hi Florian,

 

here's a different approach:

check.png

Comments:

- find block and calc length of current block

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

 

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 2 of 37
(3,503 Views)

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

0 Kudos
Message 3 of 37
(3,482 Views)

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.

 

Message 4 of 37
(3,467 Views)

Thanks for posting,

 

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

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 Smiley Wink

altenbach? Smiley Happy

 

Regards Florians

0 Kudos
Message 5 of 37
(3,456 Views)

@Florian.Ludwig wrote:

I was hoping for some "trick" though Smiley Wink

 


Challenge Accepted!

Find Max Occurence.png

Josh
Software is never really finished, it's just an acceptable level of broken
Message 6 of 37
(3,443 Views)

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

0 Kudos
Message 7 of 37
(3,434 Views)

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).

Message 8 of 37
(3,419 Views)

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 Smiley Happy

 

Regards Florian

0 Kudos
Message 9 of 37
(3,409 Views)

@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.

0 Kudos
Message 10 of 37
(3,401 Views)