LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Find elements in array

Solved!
Go to solution

Agreed with the readability compared to yours. So one more try (Just for fun :))

 

2D array-Non zero-Another way.png

-----

The best solution is the one you find it by yourself
0 Kudos
Message 11 of 17
(1,673 Views)

@for(imstuck) wrote:

I agree on the less iterations. But, I didn't benchmark it and can't confirm which is faster. I call a not equal node one time, you have to call search 1D array multiple times (which probably doesn't have that much overhead in this situation anyways). But, i don't think a loop iteration where the loop does nothing takes very long Smiley Tongue. Often times I will pick easier redability over possibly a little more efficient (assuming yours is more efficient) solution. I think it's much easier to look at my code and see "if not equal to zero, replace with 100". 

 

But, this is IMO only, and others may differ.


Think about what is really happening under the hood with the search 1D array.  It is a loop to exit when a certain item is found or all of the elements have been searched.  With this thought in mind, I would say NOT using the Search 1D Array would be more efficient.  It's also easier to read.



There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 12 of 17
(1,658 Views)

@crossrulz wrote:
Think about what is really happening under the hood with the search 1D array.  It is a loop to exit when a certain item is found or all of the elements have been searched.  With this thought in mind, I would say NOT using the Search 1D Array would be more efficient.  It's also easier to read.

Are you sure? I thougth it was a binary search, in which case it would be faster to sort the array first, then pass it in *I believe* but am not sure.

0 Kudos
Message 13 of 17
(1,652 Views)

@for(imstuck) wrote:

Are you sure? I thougth it was a binary search, in which case it would be faster to sort the array first, then pass it in *I believe* but am not sure.


 I suggest reading the help: "Because the search is linear, you need not sort the array before calling this function."

0 Kudos
Message 14 of 17
(1,648 Views)

@for(imstuck) wrote:
Are you sure? I thougth it was a binary search, in which case it would be faster to sort the array first, then pass it in *I believe* but am not sure.

Maybe one of these days, this idea will be implemented. 😄 Currently, it is not.

0 Kudos
Message 15 of 17
(1,645 Views)

@nathand wrote:

@for(imstuck) wrote:

Are you sure? I thougth it was a binary search, in which case it would be faster to sort the array first, then pass it in *I believe* but am not sure.


 I suggest reading the help: "Because the search is linear, you need not sort the array before calling this function."


HOw DO i GET To the HelP? I NEED AsSitance ImmEdiately. How do I open context help? Smiley Tongue

0 Kudos
Message 16 of 17
(1,643 Views)

The gap is closing, but there is an inescapable fact of life "C code blows away LV code".  What does that mean here?  Despite the fact that Search 1D array is equivalent to a For Loop with a condtional terminal, the search primitive is implemented in C and will smoke the For Loop.  In LV12 I get about a factor of 3 difference.

 

The point is not to move to C, but rather to keep in mind that the more work you keep "under the hood" (ie. in primitives), the faster your code will be.  There are a few exceptions, but those are typically a result of a blunder by NI.

Message 17 of 17
(1,629 Views)