BreakPoint

cancel
Showing results for 
Search instead for 
Did you mean: 

Rube Goldberg Code

I like to use "Matrix Size" to get the number of rows or columns in a 2D array

Message 2281 of 2,309
(4,516 Views)

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

0 Kudos
Message 2282 of 2,309
(4,506 Views)

@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 


GCentral
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 2283 of 2,309
(4,495 Views)

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

 

BowenM_4-1620267807099.png

 

 

Matrix Size is still noticeably faster.  Interestingly enough, enabling iteration parallelism brought them much closer to identical, even for higher number of iterations.

 

BowenM_3-1620267547017.png

 

 

So, take that past Darren who was unable to see into the future:  You were only a partially right!

Message 2284 of 2,309
(4,483 Views)

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

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
Message 2285 of 2,309
(4,475 Views)

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

0 Kudos
Message 2286 of 2,309
(4,462 Views)

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.

0 Kudos
Message 2287 of 2,309
(4,449 Views)

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.

Certified LabVIEW Architect
Message 2288 of 2,309
(4,445 Views)

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

DNatt, NI
Message 2289 of 2,309
(4,408 Views)

wiebe@CARYA wrote:


The array to cluster + unbundle has the advantage of being 'vertically friendly'.

Array Size With Unbundle.PNG

 


I'd say a Get Matrix Size saves you a couple of blocks.:)

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
0 Kudos
Message 2290 of 2,309
(4,257 Views)