closed review Random Number - Integer (Numeric Package)

[Phillip Brooks]

This OpenG Review is closed.

Based on Jim's suggestion in my post Select Random Array Indices, I submit this VI: 'Random Int Number - Within range'.

The existing OpenG Random Number VI would presumably be renamed and added to a polymorphic VI.

I chose I32 data types for compatibility with array indexing functions. The default values of one and zero allow this to be used with 'Not Equal to Zero?' to simulate a coin toss.

Discuss.

Random Int Number - Within Range__ogtk.vi

UPDATE:

I was going to provide a link to the existing OpenG 'Random Number' documentation. A Google search found that Jim already submitted something similar to the old OpenG forums, see here. Jim mentions that the high and low are negatively biased and solves this by adding one to the high value and then rounding down.

I think his is better. Rather than duplicate Jim's post and test code, is there a way we can import the discussion from the OpenG board to the LAVA board?

Edited October 13, 2011 by jgcode

[jgcode]

I think his is better. Rather than duplicate Jim's post and test code, is there a way we can import the discussion from the OpenG board to the LAVA board?

Cut and paste.

I am sure everyone who is interested in the discussion can click to the OpenG archive and read the OP.

Keep that thread going by posting in this LAVA thread, no worries.

[Phillip Brooks]

By Jim Kring (Copied from OpenG forums; posted there 21 April 2008 - 05:17 PM)

Proposal

I propose that we add support to the "Random Number - Within Range" for integer values by making it a polymorphic function that outputs a uniform distribution for integer inputs (that includes both the Low and High input values). Behavior for floating point inputs would remain unchanged.

Background

There have been a couple recent discussions about generating random integers with the "Random Number - Within Range" function, shown below:

When using the "Random Number - Within Range" function with integer inputs, most people (incorrectly) assume that the output will have a uniform distribution of integers between High and Low. When, in reality, the High and Low values will have half the rate of occurence than the values between High and Low, as shown in the screenshot and example VI, below:

EXAMPLE___Problem_with_Random_Integer_Generation.vi

Let's look at why this happens. Say we have a range from 1 to 10. Values from 1 to 1.5 will be rounded to 1. Values from 1.5 to 2.5 will be rounded to 2, values from 2.5 to 3.5 will be rounded to 3, ..., ..., .., values from 8.5 to 9.5 will be rounded to 9, and values from 9.5 to 10 will be rounded to 10.

As you can see, the values of 1 and 10 each occur in a range of 0.5 out of 9, whereas the values of 2 through 9 each occur in a range of 1 out of 9. 1 and 10 have half the rate of occurence of 2 through 9.

The solution is to extend the total range to High + 1 and then round the output value down, as shown in the screenshot, below:

With this correction, the distribution is now uniform, as shown below:

Open Issues

Convert to Poly VI or create a new, seperate VI for integers?

25]The Polymorphic VI can be named "Random Number - Within Range.vi__ogtk.vi", so that replaces existing instances of the DBL implementation in users' code. For users' existing code that is inputting floating point values into this function, the DBL poly instance will be used and thier code will remain unchanged. For users' existing code that is inputing integer values into this function, the new integer implementation instances will be used. This choice relies on the assumption that the new integer behavior is desired whenever integers are wired into this function. An alternate approach would be to simply add a new, seperate VI for the integer types --

e.g.

, we might call this

Random Integer

.

Edited September 28, 2011 by Phillip Brooks

[Wouter]

I'm in favour for such a VI.

[Aristos Queue]

A) I definitely would not provide default values for those input terminals. Make them required. I can't believe that the majority use case is going to be coin flipping between zero and 1. If you want to write a specialized "Coin Flip.vi", fine, but give that one a boolean output.

B) What happens if High is less than Low? Perhaps an absolute value node should be added to the subVI?

[Ton Plomp]

I would suggest to make the Upper limit required, and check for the min/max (use the native sort 2 number primitive).

And I would make this a polymorphic VI with all the Int/UInts and double.

Ton

[Phillip Brooks]

A) I definitely would not provide default values for those input terminals. Make them required. I can't believe that the majority use case is going to be coin flipping between zero and 1. If you want to write a specialized "Coin Flip.vi", fine, but give that one a boolean output.

B) What happens if High is less than Low? Perhaps an absolute value node should be added to the subVI?

Since an integer value has no NaN or ±Inf equivalent, some real number is required. The existing function uses defaults of zero and one, so this would be consistent. The fact that an integer zero or one output can be interpreted as a Boolean was simply an observation. (Maybe default input values of 1 and 20 would be in order for the D&D folks )

I would suggest to make the Upper limit required, and check for the min/max (use the native sort 2 number primitive).

And I would make this a polymorphic VI with all the Int/UInts and double.

I like the 'Max and Min' function rather than the absolute value. I think we would have to subtract one from the improperly entered High value (less than low) and then round up in order to get the proper distribution. That would make the function overly complex.

Since the function name contains "in range", should we change the labels for the inputs to 'a' and 'b'? If so, how do you select which one to make required? (Maybe both? Neither?)

Please note that there is fairly complete collection of VIs for various data types and some extensions (like random array elements) located in sourceforge. They were submitted some time ago by dafemec as part of the thread I copied and pasted from.

So; I start a thread about a random array subset vi. A suggestion was made to maybe be a bit more simple and extend the existing random number function. I create an example, the find a nice collection of stuff. This stuff includes datatype specific versions of the function that started the whole discussion.

What do we want to do? Should we load the sourceforge files into this thread?

Links:

• 
  
  • Random Number Sequence - Within Range (I16).vi
    
  • Random Number Sequence - Within Range (I32).vi
    
  • Random Number Sequence - Within Range (I8).vi
    
  • Random Number Sequence - Within Range (U16).vi
    
  • Random Number Sequence - Within Range (U32).vi
    
  • Random Number Sequence - Within Range (U8).vi
    
  • Random Numbers - Within Range (CDB).vi
    
  • Random Numbers - Within Range (CSG).vi
    
  • Random Numbers - Within Range (CXT).vi
    
  • Random Numbers - Within Range (DBL).vi
    
  • Random Numbers - Within Range (EXT).vi
    
  • Random Numbers - Within Range (I16).vi
    
  • Random Numbers - Within Range (I32).vi
    
  • Random Numbers - Within Range (I8).vi
    
  • Random Numbers - Within Range (SGL).vi
    
  • Random Numbers - Within Range (U16).vi
    
  • Random Numbers - Within Range (U32).vi
    
  • Random Numbers - Within Range (U8).vi
    
  • Single Random Number - Within Range (CDB).vi
    
  • Single Random Number - Within Range (CSG).vi
    
  • Single Random Number - Within Range (CXT).vi
    
  • Single Random Number - Within Range (DBL).vi
    
  • Single Random Number - Within Range (EXT).vi
    
  • Single Random Number - Within Range (I16).vi
    
  • Single Random Number - Within Range (I32).vi
    
  • Single Random Number - Within Range (I8).vi
    
  • Single Random Number - Within Range (SGL).vi
    
  • Single Random Number - Within Range (U16).vi
    
  • Single Random Number - Within Range (U32).vi
    
  • Single Random Number - Within Range (U8).vi
    

Edited September 28, 2011 by Phillip Brooks

[jgcode]

What do we want to do? Should we load the sourceforge files into this thread?

I would do whatever makes it easy for reviewers to get to the code to contribute to this thread.

E.g. post a zip containing everything for a one-click download (as opposed to 30+ clicks)

[jgcode]

I vote to add an I32 VI (using Jim's code) and polymorphize the API.

We can look at supporting more datatypes in the future when there are good enough reasons to do so.

[Phillip Brooks]

I vote to add an I32 VI (using Jim's code) and polymorphize the API.

I agree. This extends a useful function and makes good code reuse.

[Wouter]

True also convert the lower to double to avoid the coersion dot.

[jgcode]

True also convert the lower to double to avoid the coersion dot.

FWIW, there's two conversion dots there.

[Phillip Brooks]

I've renamed the existing function to include DBL, created a polymorphic VI using the original function name and added the INT version. I also added the conversion to/from DBL to avoid the coersion. (see image).

numeric.llb.zip

[jgcode]

A) I definitely would not provide default values for those input terminals. Make them required.

B) What happens if High is less than Low? Perhaps an absolute value node should be added to the subVI?

On the topic of B) I use the Min/Max primitive as Ton suggested:

I would suggest to make the Upper limit required, and check for the min/max (use the native sort 2 number primitive).

E.g. when converting a Start/End Index to Index/Length for arrays, I do the precheck and also output a pass result (if ever of interest).

We could do something similar here however, I recommend we depreciate the original VI as this will cause a behavior change of the function. If we depreciate the VI, then IMO we should also do A) and make the inputs required for all new VIs.

[jgcode]

Ok, here is what I have so far:

Instead of depreciating the old function, which is still valid and will be used internally to the API, we make it private. Notes:

• A private setting cannot actually be enforced without .lvlib support (a good reason for it) however, the notion is still the same
  
• I have used a red border to show that the private function is different from the public calls of the API
  
• The documentation states the private function should not be called, and provides the alternative (i.e. how to upgrade existing code)
  
• This change in iconography for the private function (whatever it will be) should be standardised by the OpenG Board
  
• This implementation will not break existing code
  

Public Functions were created for Double and I32 which sets the inputs to required. Notes:

• Double does not need to precheck data given the way the original code is implemented, the order of High and Low is irrelevant
  
• I32 could call the private function directly (functionally equivalent) to optimize the code
  

----

----

----

Here is an example of what the new and old code:

Here are the settings for the Polymorphic VI:

The attached code also contains the I32 Evenly Distributed example from the OpenG Forums (linked to the new code).

Random Number Within Range.zip

Code is in LabVIEW 2009

[jgcode]

I have changed this review to pending. If no one has any further comments I will close the review in a few days.

This new VI and change can be tracked here: ID: 3419758