07-01-2011 02:11 PM - edited 07-01-2011 02:11 PM
I went through it so quickly that I didn't even notice that you had fixed my original. Does it help my case to say that that code is almost three years old? No, I guess not...
07-01-2011 02:37 PM
Did you say the code was written by a thre year old?
07-01-2011 03:00 PM
Hmmm.. I realized the index array can be replaced with a while loop.
I wonder which is faster This has 10 nodes compared to the 9 in the first "fix" and 11 in original.
07-01-2011 08:13 PM - edited 07-01-2011 08:14 PM
@LV_Pro wrote:
Did you say the code was written by a thre year old?
Ouch...
07-04-2011 02:36 AM - edited 07-04-2011 02:40 AM
Ok, I'll admit I haven't actually opened and looked at the case structure, but if i remember correctly from my bench marking tests Jeff, while Jim's code may be "Rube'd" it'll run faster than your's. The reason being that a string into a case structure always needs a default case, and LabVIEW seems to take more time to run this than a boolean check and case structure. It seems to check how many cases it has, if the string matches an existing case and then if not, it runs the default case. Jim's code just does a simple boolean check and on long strings, or where you are only looking to match one string (a boolean check). Jim's technique is more effiecient in time and memory in LabVIEW - certainly before LabVIEW 2010.
- Not sure if that is a Rube Jeff!
Please feel free to correct me anyone who has actually bother testing this or can remember better!!
James
07-04-2011 11:16 AM
@Jeff Bohrer wrote:
Hmmm.. I realized the index array can be replaced with a while loop.
I wonder which is faster This has 10 nodes compared to the 9 in the first "fix" and 11 in original.
What is the benefit of replacing the Index Array with a While Loop?
I would have used the index array myself. Is it indeed a Rube? Since it is not really adding complexity.
-curious-
07-04-2011 06:44 PM
OK the challange involved Jim fearing seeing his latest snippet in the thread. So I went to his images - I would have posted it in reply WITHOUT regard to any R-G constructs found. BONUS a compare to constant feeding a case selector WAS found- It may be faster to do so in this instance. If so Jim RG'd it for optomization and I'll take the knowledge and apply it
07-05-2011 12:38 PM - edited 07-05-2011 12:39 PM
Interesting way to see if a boolean array as changed (top of image).
It is also not very clear why we need to read the local variable into the output if it is the same as the input array (TRUE case, not shown)
(Also substituting a local variable for a shift register as suggested is probably not such a great idea!)
07-05-2011 01:04 PM
@altenbach wrote:
Interesting way to see if a boolean array as changed (top of image).
It is also not very clear why we need to read the local variable into the output if it is the same as the input array (TRUE case, not shown)
(Also substituting a local variable for a shift register as suggested is probably not such a great idea!)
Because the output and input are not the same until after the vi is executed. I thought about using a feed back node. Two differnt ways to do the same thing.
07-05-2011 01:36 PM
@aeastet wrote:
Because the output and input are not the same until after the vi is executed.
In your TRUE case, they are the same so there is no need to wire the 1D array across the case structure at all, right?