05-05-2021 03:38 PM
I like to use "Matrix Size" to get the number of rows or columns in a 2D array
05-05-2021 04:22 PM
@Gregory wrote:
I like to use "Matrix Size" to get the number of rows or columns in a 2D array
6 pixels too big!
Actually, I hadn't thought of doing that before. I generally ignore the "Matrix" functions. I'm doing that from now on!
05-05-2021 07:49 PM
@BowenM wrote:
@Gregory wrote:
I like to use "Matrix Size" to get the number of rows or columns in a 2D array
6 pixels too big!
Actually, I hadn't thought of doing that before. I generally ignore the "Matrix" functions. I'm doing that from now on!
Darren's Weekly Nugget 10/26/2009
05-05-2021 09:25 PM
@crossrulz wrote:
Darren's Weekly Nugget 10/26/2009
I'm probably getting way off topic here, but...
In that Nugget, Darren issued the following challenge:
No, it's not a subVI...it's a built-in function. If it were a subVI you wouldn't be able to wire any arbitrary 2D array to it. Not to mention subVI call overhead. And the allocation of an array for the Array Size output. I welcome somebody to post some benchmark results comparing the two approaches...I think you'll find Matrix Size to be faster, although I will admit that there probably aren't too many use cases that require extremely performant row/column calculations...
"Ha!" I thought to myself. "Silly 2009 Darren couldn't see into the future and so he had no idea about malliable VIs. I can too wire an arbitrary 2D array into a subVI". And since nobody accepted his challenge in 2009, here we are. I was curious and did the test with a malliable VI.
Matrix Size is still noticeably faster. Interestingly enough, enabling iteration parallelism brought them much closer to identical, even for higher number of iterations.
So, take that past Darren who was unable to see into the future: You were only a partially right!
05-05-2021 10:20 PM - edited 05-05-2021 10:25 PM
@BowenM wrote:
Matrix Size is still noticeably faster...
I think reading the high res timer value inside the for loop may be skewing your results. I reckon it might be taking longer than the matrix size operation.
05-06-2021 12:33 AM
@TroyK wrote:
I think reading the high res timer value inside the for loop may be skewing your results. I reckon it might be taking longer than the matrix size operation.
Oops. I think you're right... I was being lazy, didn't think of the execution time of the relative seconds. I'll have to try again later.
05-06-2021 03:18 AM
I've been burned a few times by vims...
At some point I wasted 4 hours because an exe wouldn't build anymore. I had to remove 50%, remove the other 50%, iterate, narrowed it down to a few VIs, remove 50% of the VIs, etc.
The simples vim ever (Synchronize Data Flow.vim) was the cause.
"Heavy" vims tend to introduce a noticeable to unworkable delay, especially when they change, or IIRC even when opened and closed.
05-06-2021 03:27 AM
wiebe@CARYA wrote:
I've been burned a few times by vims...
At some point I wasted 4 hours because an exe wouldn't build anymore. I had to remove 50%, remove the other 50%, iterate, narrowed it down to a few VIs, remove 50% of the VIs, etc.
The simples vim ever (Synchronize Data Flow.vim) was the cause.
"Heavy" vims tend to introduce a noticeable to unworkable delay, especially when they change, or IIRC even when opened and closed.
Haver had similar issues. Also, files that use vims may get broken if the vim is changed and need to be force-recompiled or that the vim is manually reconnected again to force a recompile. Sometimes I also get broken wires to the vim but a runnable VI. And if I try to minimize the code to post a bug report, the problem goes away.
05-06-2021 10:09 AM
@BowenM wrote:
So, take that past Darren who was unable to see into the future: You were only a partially right!
If I could have seen into the future, you better believe I'd be sitting on a giant pile of Bitcoin right now.
05-10-2021 05:46 AM
wiebe@CARYA wrote:
The array to cluster + unbundle has the advantage of being 'vertically friendly'.
I'd say a Get Matrix Size saves you a couple of blocks.:)