12-15-2015 11:08 AM
Oh man, that stop logic! There is no reason to use local variables (and certainly no reason to make the "True" case wire a "True" constant). I can try out your VI but it's going to cost you, you're going to have to upload the the actual VI and not a screenshot.
12-15-2015 11:12 AM
Maybe you are right.
12-15-2015 11:18 AM
@crisdragon wrote:
Maybe you are right.
Just looking at it for 1 second: Your VI is still full of race conditions. There is no guarantee that the local variable in the upper ight gets read only after the same local variable gets written in the case below, but the outcome critically depends on the order. Use dataflow!
(I have not looked at the overall algorithm yet.)
12-15-2015 11:41 AM - edited 12-15-2015 11:46 AM
Hi Cris,
It works for me 1000 times out of 1000! You will have to add the input array and output array to the top left and right terminals respectively to run this snippet.
12-15-2015 11:44 AM
12-15-2015 11:46 AM
I'm referring to zad1d.vi in message 12. It appears to give the same output as the native 1D sort function.
12-15-2015 11:53 AM
12-15-2015 12:46 PM - edited 12-15-2015 12:47 PM
Hi gregoryj,
because a VI with known race conditions will work in your example case (computer, CPU, dataset, compiler options, OS, moon phase, many more) it will work always as expected?
What's the problem to remove race conditons and clean up such a small VI?
Atleast the OP should have done this…
12-15-2015 12:53 PM - edited 12-15-2015 12:56 PM
Here is version that fixes the race conditions, and also uses the inplace element structure and swap functions to simplify the array manipulation code.
12-15-2015 12:54 PM
Hi GerdW,
I made no such claim
It works for me 1000 times out of 1000!
And I fully expect a waning moon to throw it off