LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Array Manipulation Bug

Solved!
Go to solution

I''m running into an Array Manipulation bug that sometimes generates an extra element causing a bogus numbers to be added to the array for some odd reason.  It doesn't do this all the time, but it does it sometimes.  Which is of course is inconstant. 

 

I can't quite see what I'm doing wrong, and why it is inconsistent results.  There should never be a "0" in the array's, but it keeps showing up.  But it only shows up if an extra element is added to the array.  I tried to isolate it using Case statements, but both Array manipulation routines are doing it.

 

This routine example is intended to exercise Array mathematical operations.  However these VI's are sometimes adding elements and inserting "0" at random times.  How am I incorrectly using these Array Manipulation VI's?

 

The problem is in these Sub-VI's:

 

LOTTO_Shuffle_Balls.vi

LOTTO_Scramble_Balls.vi

 

With the top level VI being:

 

LOTTO_Draw_Balls_With_Statistics.vi

 

 

0 Kudos
Message 1 of 9
(3,638 Views)
Solution
Accepted by topic author emw129

Just looking at "Shuffle", your multiplied random number can occasionally exceed the highest index, thus no element will be deleted but a default element added. (You need to insert this function after the multiplication)

 

Your code seems extremely convoluted and inefficient. Have a look at riffle.vi for a built-in alternative. There are also many other ways (example) to do that much simpler.

Message 2 of 9
(3,617 Views)

Nothing jumps out at me as to problematic array operations.

 

It would help if you saved the VI's with values in the controls saved as default.  Perhaps it is some odd combination of values causing a problem.  We can't replicate your problem to investigate without some help.

0 Kudos
Message 3 of 9
(3,616 Views)

@altenbach wrote:

Just looking at "Shuffle", your multiplied random number can occasionally exceed the highest index, thus no element will be deleted but a default element added.

 


Same for "scramble", but here the array is in-place and the size cannot change. Do you see it change?

 

If you multiply a random number with the array size, you need to round to -infinity to get a guaranteed valid index. There is no reason in the world to convert to U16, especially if you using it as index (always I32) or comparing it with an array size (also always I32). Can't you see all these red coercion dots, indicating type mismatch?

 

Some silly code constructs in "scramble":

  • How many times do you think You need to see if the array size is >0? This does not belong inside the loop. And if the size is zero, the loop does not even execute, so that other case can never occur. No case structure needed!
  • Index array is resizeable, no need for two instances, same for replace array subset. Have a look at the "in place element" structure do do all at once.
Message 4 of 9
(3,606 Views)

Here's a simple draft of working code. Seems somewhat simpler than yours. 😄

 

(You should add some sanity checks on the inputs, for example the number of balls should be larger or equal to the number drawn.)

 

 

0 Kudos
Message 5 of 9
(3,582 Views)

I think it's safe to say that there is another, different, lesson to be learned here.  Never say something is buggy unless you are quite certain that it is.  I almost always assume it's my code because 9 time out of 10, it is.  😉

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 6 of 9
(3,556 Views)

Problem appears to be random number generation, it appears that converting from floating point to an integer sometimes rounds up to the next nearest highest number, instead of the lower one.  I always thought that conversion only removed the decimal points and didn't do any up rounding.

0 Kudos
Message 7 of 9
(3,526 Views)

Yes, it rounds to the nearest integer.

 

You actually had two statistical problems, one just more subtle. Yes, you had a chance to get a value that is too high by one, but also the probability of getting zero was only half of the probability of getting the typical values (the other half was for the values that were too big). You would never get a job in Vegas with these mistakes :D)

 

Still, the process of constantly resizing arrays by trimming and appending is not efficient and a telltale sign of beginner code. It is easy to change the code so the array is fixed in size and the array operations are in-place. Try it!

0 Kudos
Message 8 of 9
(3,523 Views)

@emw129 wrote:

Problem appears to be random number generation, it appears that converting from floating point to an integer sometimes rounds up to the next nearest highest number, instead of the lower one.  I always thought that conversion only removed the decimal points and didn't do any up rounding.


You are mixing up conversion, rounding and truncation, and to add one other option, coercion.

What you meant to happen was truncation or rounding to -Infinity, which when dealing with statistical or banking numbers is a complete nightmare. I'm sure banks would love to truncate all numbers to the nearest cent or maybe even dollar and keep the change. There were guys in the past who implemented that in banking software, sending of the fractional cents from such "rounding" operations to their own bank account and they were found out because the amount on their account quickly rose to suspicious heights!

 

Rounding is another interesting topic, as there are different kinds of rounding out there. What we all learn in school is the typical rounding, where 0.5 is always rounded up towards +Infinity, while anything below that is rounded down. But there is also something called bankers or statistical rounding where 0.5 is always rounded to the nearest even number. This may seem like peanuts, but when dealing with statistical numbers, always rounding up 0.5 would create a bias when you work on large amounts of numbers.

 

LabVIEW implements as default rounding the bankers rounding but supports all other roundings (towards -Infinity, towards +Infinity and towards 0, with specific nodes on its numeric function palette.

Rolf Kalbermatter
My Blog
Message 9 of 9
(3,481 Views)