¿there is another form to do this?

[JÞB]

I'd like to point out one other issue about generating random integers that was overlooked in some earlier examples.  the rounding of doubles as implemented per IEEE754 causes a less than ideal distribution of the end points (0 and 45 will be 1/2 as common as 1-44) if implemented per RF and X's first posts.

Altenbach's solution of course does not have this problem but is limited to the case where duplicates are not permitted.

Consider the following Snippet as a general solution

The multiply by two and mod math are there to force the range generated to be even  otherwise if the range was odd an outsid cance exists that Random Number is 1 and and an Odd.5 would round up (x.5 rounds to an even integer)  forcing the range to be even prevents that from happening.

[JÞB]

some purists might point out a minor improvment

[RavensFan]

---

@JÞB wrote:

I'd like to point out one other issue about generating random integers that was overlooked in some earlier examples.  the rounding of doubles as implemented per IEEE754 causes a less than ideal distribution of the end points (0 and 45 will be 1/2 as common as 1-44) if implemented per RF and X's first posts.

---

That is exactly what I said in message 3 which is why is said to use the Round down to Nearest integer version.  The rounding of 0.5 to even integers only applies to the Round to Nearest function, not the Round up or Round down functions.

There is an issue with doing round up.  The random number goes from 0 to .99999......  So if  you round up after mulitplying there is a slightly higher distribution to 1 then it is to the max value you are going for.  Any number from 0 to 1 goes to 1.  Any number from 44.0000....0001 to 44.999999....  goes to 45.  Any number through the range would be 23.0000....0001 to 24 would round to 24.

The round down does not have this problem because 0 to .9999999 will always round down to zero, 44.0000000 to 44.999999.... will always round down to 44.  Likewise for any number in between.

[Darin.K]

---

@altenbach wrote:

---

@Darin.K wrote:
Why build the array at all when the index output is right next door and you simply pass in an array initialized to the right size.

---

I cannot really figure out which diagram you are talking about. 😉

---

I am referring to any diagram using Riffle which feeds an integer ramp to the input. You can simply use the Riffle Index output for the same effect. For input just use initialize array with the proper length. In the For Loop versus Ramp debate, I was simply voting none of the above.

[altenbach]

---

@Darin.K wrote:
You can simply use the Riffle Index output for the same effect. For input just use initialize array with the proper length.

---

A, All clear now. A good solution if the output should be I32. 🙂

The for loop might be a bit more intuitive to adapt if the lower boundary is not zero, but you could also just add a constant to the index result 😉

(It seems Riffle has some weird "partial" polymorphism, for example it coerces e.g. FXP, U8, U16, or U32 etc. inputs to I32, creating an I32 output. A U64 input is coerced to DBL, which cannot hold all possible U64 values. EXT also goes to DBL.)

According to the help, it can only do DBL, CDB, and I32. Of course we can easily support any datatype by using the index output and indexing into the original data array afterwards. 😉

EDIT: A full discussion about riffle can be found here. Darin even shows the above workaround. Small world if the memory is short. :D)

[angoav98]

This is fantastic!!.. very well!!.. congratulations!!.. I would like to know as much as you know!!

Thanks

[Darin.K]

Given the (light-hearted) discussions here about the various solutions:

http://forums.ni.com/t5/BreakPoint/Rube-Goldberg-Code/m-p/1917739#M18502

I thought I would add (or subtract) from the discussion with a few points to consider:  First and foremost the original problem as stated is very specific and quite simple so the minor differences are mostly inconsequential.  However, this is a fairly common operation so I would point out a few things about the search method (RF and X) and the Riffle method.

At large values, the search method can become expensive and sometimes frustrated leading to long operation times.  The Riffle method is potentially wasteful as you are initializing an entire array and then Riffling all of it.

In the general case of choosing M integers from 1..N I reach for two methods which are small tweaks of the two aforementioned methods.  Instead of Riffle, I use the Inside Out Fisher Yates Shuffle which handles initialization and randomization in the same step.  Most of the code is doing two simple steps which should have their own primitives IMO: Generate a random integer and swap two array elements.  Then this would be postage stamp size.  Instead of the straight search and iterate method, I would use a technique called Reservoir sampling to choose the M elements at random.  This also involves a search to catch duplicates, but it adds a value in each iteration so no matter what it always takes M iterations.  Since the values will have a position bias, the smaller array is shuffled to remove this.  I would use Riffle here, but it is biased.

http://forums.ni.com/t5/LabVIEW/Riffle-is-Biased/m-p/1921103

Here are the two methods, again just tweaks of the two versions already presented optimized for the integer selection problem.