Jump to content

Random Number - Integer (Numeric Package)


Recommended Posts

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.

post-949-0-95464700-1317206977.jpg

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 by jgcode
  • Like 2
Link to post
Share on other sites

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.

Link to post
Share on other sites

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:

post-1093-1208815324.png

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:

post-1093-1208814294.png

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:

post-1093-1208814928.png

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

post-1093-1208815163.png

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 by Phillip Brooks
  • Like 1
Link to post
Share on other sites

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?

  • Like 2
Link to post
Share on other sites

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

  • Like 2
Link to post
Share on other sites

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 :P)

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. :wacko:

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

Links:

Edited by Phillip Brooks
Link to post
Share on other sites
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) :)

  • Like 1
Link to post
Share on other sites

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).

post-10325-0-22910700-1317899121.png

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.

Link to post
Share on other sites

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

post-10325-0-72125100-1317923204_thumb.p

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

----

post-10325-0-10401300-1317922992_thumb.p

----

post-10325-0-06056900-1317922994_thumb.p

----

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

post-10325-0-08826300-1317922993_thumb.p

Here are the settings for the Polymorphic VI:

post-10325-0-24665600-1317922996.png

post-10325-0-11228400-1317922995.png

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

Link to post
Share on other sites
Guest
This topic is now closed to further replies.
  • Similar Content

    • By Taylorh140
      So I have a serious question. Does LabVIEW have a way (built in or library) of calculating the next larger or next smaller floating point value.
      C standard library "math.h" has two functions:
      nextafter, and nexttowards.
      I have put together a c function: that seems to do the trick nicely for single floats (well only for stepup):
      #include <math.h> #include <stdint.h> uint32_t nextUpFloat(uint32_t v){ uint32_t sign; = v&0x80000000; if (v==0x80000000||v==0){ //For zero and neg zero return 1; } if ((v>=0x7F800000 && v<0x80000000)||(v>0xff800000)){ //Check for Inf and NAN return v; //no higher value in these cases. } sign = v&0x80000000; //Get sign bit v&=0x7FFFFFFF; //strip sign bit if(sign==0){ v++; }else{ v--; } v=v|sign; //re merge sign return v; } I could put this in labVIEW, but these things are tricky and there are some unexpected cases. So its always better to use a reference. 
       
    • By Axelwlt
      When the cursor in the numeric field of a numeric control is for example after the 10s/100s digit, the increment/decrement buttons have a step of 10/100. How can I prevent that? I always want a step of 1.
      I tried setting the Data Entry Increment property to 1 but that did not change this behaviour..
    • By drjdpowell
      This OpenG Review is closed. See Summary Post here. Please start a new thread to discuss new changes to this VI.
      Read this post for start of review.
      I’d like to suggest these three VIs (or similar) as possible LVOOP-object additions to the OpenG Toolkit:

      “Get Class Name” is a modification of “Get Name of Class of Object” posted by AQ. Here it just returns the basic class name (which I use often in custom probes and the like).
      "Get Default Object” is inspired by this discussion and uses AQ’s zero-iteration loop method. This is a very simple VI, but using it instead of the raw code is much clearer to the reader.
      “Same or child class” just uses “Preserve Runtime Class” as a tester. Again, the advantage here is code readability (or it will be, as soon as someone comes up with a good icon for it).
      Thoughts?
      — James
      OpenG Suggestions.zip
    • By Wouter
      This OpenG Review is closed. See Summary Post here. Please start a new thread to discuss new changes to this VI.
      VI Name:
      Supress error
      Total VIs:
      2
      Description:
      This VI has a integer (array), error code, as input and when the error code matches the error code on the error wire it supresses the error.
      Note:
      -
      Blockdiagram:
      Scalar:

      Array:

      Code:
      Supress Error.zip
      What are you thoughts on this VI?
      Would you like to see such a function in OpenG?
      Can you optimize the code?
      In which package should it be included?
      Should it be rejected?

    • By jgcode
      This package will be available for download through VIPM in a few days and covers some new VIs.
      [MOD] 3419758 - Create new Random Number Within Range - I32 VI
      [NEW] 3422921 - Add Timestamp Constant


      Kind regards
      Jonathon Green
      OpenG Manager
      I would also like to thank Ed Dickens for reviewing this package for release.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.