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?

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?

Btw anyone any thoughts about the note in the OP?

The only use case I can think of might be related to unicode or multi-byte char sets, but that brings byte order into play, and I think this dark side community doc has some functions that can do this already...

https://decibel.ni.com/content/docs/DOC-10153

On my OpenG Comparison Tools palette, there is one item (Data Changed).

I would suggest that since there are no 'typical' nodes that we could standardize on a the larger 'Select' triangle along with a 5-3-3-5 pattern.

Rationale:

OpenG comparison functions will be extensions of existing functions and require additional inputs/outputs.

5-3-3-5 allows us more choices for the inputs and outputs.

The larger node provides additional room for text inside and differentiates the node from the native node.

Comparsion.vi

We could also make it an Express VI

Code is in LabVIEW 2009.

Personally, I don't think this looks 100% right where the argument is - what do you guys think?

Also, it would helpful if you guys could post code of this VI with the CP's you want.

It does look a bit odd.

Sorry, I'm on 8.6 with no time or resources to have 2009 around.

If I recall correctly, the code in the disabled structures is treated the same as a comment in text based langauges. It does not get included in the built executable.

LabVIEW does allow you to build a 'debug' exe. I don't know if the disabled code would be included or not...

I've got on (little) thing:

This shows that the primary input (the string) is not in the center of the Left hand Side of the Icon.

For programming style where this is in a wire, this gives odd layouts.

All of the basic LabVIEW =xxxx (ref, 0, >0, >=0, <0, <=0, NaN etc) the primary input is inline with the primary output.

The optional input (strict Character case) can be connected at te bottom or top (I prefer top).

I was going to suggest the same thing, but after years and years of working for managers who all have their own style (beauty is in the eye of the beholder) I was going to let it go. As a natural extension of functions, I think it should be consistent with the other comparison palette functions (in line).

I would suggest the Boolean 'strict' option be shown similar to other NI functions such as Array of Strings to Path and labeled 'strict case'.

It disables the Nagel algorithm in win 7. It seems to have improved things significantly.

If you look carefully at some of the LabVIEW posts regarding Nagle's Algorithm, you can find references to (or actual) VIs that you can use to toggle Nagling on a PER CONNECTION BASIS within your LabVIEW code. You certainly can make changes in Windows (via the registry) but this will affect all apps.

There must be a LabVIEW.ini key that let's you create these.

SuperSercretFunkyBlackWireThatDoesWhateverYouWant = TRUE[/CODE]

[/font]

I don't know, but there IS on on the OpenG Variant palette...

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-Variant-constant-to-the-Cluster-Class-amp-Variant-function/idi-p/1083987

I looked at some of the riffle posts on the dark side and noticed that riffle seems to be part of the FDS. Base folks wouldn't have this function to use.

The other thing is that the array to be riffled is modified and must by an array of DBL, CDB or I32. My example does not use the data array as an input, only the size and number of elements to select. It would work for an array of clusters etc...

Maybe an OpenG riffle function for base users and arrays of other types is useful?

My use case was for product sampling. We receive lots/batches of serialized products that we test for performance and prgramming. The sample size depends upon the previous lot/batch success rate. I perform the selection in Labview and update a database on pass/fail.

We also have a device that is characterized by a polynomial. A lookup table for every step setting was in excess of our storage capacity. We collect a series of points, perform a fit, and then randomly test a couple of points against the polynomial for accuracy.

Wouldn't this work like the Riffle function in LabVIEW (where your code takes the first n outputs)

Ton

When I took this random elements code (really badly done) and rewrote it, I remembered an NI forum post about randomizing a deck of cards and couldn't remember the name of the function. I guess riffle used with array subset would be the ' NI' way to do it.

Thanks for reminding me!

I was recently cleaning up some awful code and extracted this piece as a general purpose function.

I have problems with using VI Package manager at work and also still run LabVIEW 8.6.1, so I don't know if a recent OpenG function similar to this exists.

Select Random Array Indices.vi

I sort of agree with the question above, what is the use case for checking a string just looks like an MD5 string, it is either a correct valid md5 string for something or it is not. Maybe I am just not seeing the obvious here.

Danny

Lets say you have a very large file that you want to verify (the LabVIEW 2011 image )

Before extracting and installing, you might want to verify the file. The time to generate the MD5 from the downloaded file may be significant. If you are going to compare the results of a time consuming operation with an invalid string, you will be wasting time (by re-downloading a file that may be good).

It is not easy to visually read or count the characters of an MD5 checksum...

The RFC states that it must be lower case...

http://www.ietf.org/rfc/rfc2831.txt

There is a function in LabVIEW to generate a GUID. See this post.

Maybe an OpenG wrapper VI to call this function?

Since you are waiting for your hardware, this would be a good time to think about your environment and how to trigger.

Your environment sounds different than an automated assembly line with controlled lighting and a constant rate. The environment will define how you place your camera, your trigger(s) and possibly require lighting control (additional lighting or screening to prevent glare).

Just a quick observation. Does this design trade memory for speed?

If so, would this function ever be used in a memory constrained environment such as RT or FieldPoint?

It appears that two copies of the string data (as U8 arrays, one reversed) are created to iterate over. Is the LabVIEW compiler is smart enough to only use one buffer for the U8 array data? What does LabVIEW Profiler tell us about the buffer allocations?

I don't have 2009 installed, so I can't play with the examples.

If there are two buffer allocations for the U8 array data, would there any difference in performance if the 'end trim' loop were to use the same U8 array and simply index from the end of the array (N-i-1) until a hit was found?

Considering that my math skills are roughly those of a 5th grader, I wanted to know where it came from. This wikipedia entry has the history and some details...

http://en.wikipedia.org/wiki/Hearing_the_shape_of_a_drum

This begs the question, can I smell the color of a fruit?

Jim has a nice one;

http://lavag.org/topic/14745-lava-gets-an-upgrade/page__view__findpost__p__88542

More LAVA, less blabla

Here's a list if you don't want to watch the lengthy AE video:

http://www.ni.com/la...tsnew/features/

The 13 user suggested items seem quite nice.

It was still showing LV 2010 when I posted this morning. The pages must be slowly rolling over to 2011 versions.

Did I miss the announcement as to when this will happen and how to do a download?

You know, I used to get all excited when the latest version came out; but lately I feel more like "The new phonebook is here! The new phonebook is here!"

Its bigger, heavier and changed just enough that I can't find what I'm looking for.

Still using 8.6 here, and from some of my friend's experiences with LV and TS 2010; I think I'll stay where I'm at for now.

Guess I just got up on the wrong side of the bed today...