Design challenge: find biggest block of true in boolean array

[Matt_W1]

Since I can't bypass the cost of range checking in LabVIEW I couldn't make the skipping algorithm always faster than the basic one. So I had it switch from basic to switching when it performed better on my computer.

With the example data mine is 175ms ms vs 304 ms of the next best. It should be about equal the current best posted algorithm in the worst case, and much (10x+) faster in better cases. I didn't test it really thoroughly so there could be errors in it.

[smercurio_fc]

---

@matt W wrote:

Since I can't bypass the cost of range checking in LabVIEW I couldn't make the skipping algorithm always faster than the basic one. So I had it switch from basic to switching when it performed better on my computer.

With the example data mine is 175ms ms vs 304 ms of the next best. It should be about equal the current best posted algorithm in the worst case, and much (10x+) faster in better cases. I didn't test it really thoroughly so there could be errors in it.

---

I was unable to replicate these times. I did note that you made some explicit run-time changes to the VI:

• You made the VI reentrant.
• You disallowed debugging

These are going to skew the results, not allowing you to compare apples to apples.

[ben64]

Surely not the most efficient, just having fun discovering the PtByPt functions!

Ben64

[altenbach]

---

@smercurio_fc wrote:

At the worst case the input array has an alternating pattern of ones and zeros. I suspect, though, that the likelyhood of this is extremely remote.

---

Your VI does not correctly handle edge cases, for example if the array only contains FALSE, Your size will be 1, which should be zero.

You are also doing the "<0" twice on the same value, but I suspect that the compiler will eliminate one of these comparisons.

[Matt_W1]

While mine slows down if you turn those options off (since mine's speed is dependent on being inline). The other two I'm comparing against do not gain anything even though they have been placed into similiar functions (so it is apples to apples).

I attached the testing code I used and a screenshot of my results. It's possible I'm missing something so let me know if you have an idea on the source of our performance discrepency. I'm running on 2011sp1.

[altenbach]

Matt, you code gets stuck forever in the first loop if there is a single TRUE surrounded by FALSE somewhere. Needs some tweaks. 😉