Leaderboard

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?

Well references and error wires could default to shift register terminals when wired into the loop? Much like arrays default to auto-indexing. This would also be useful for counteracting the auto-indexing of references and errors when exiting the loop.

It was the while loop around the event structure that finished execution. The event structure is put inside the while loop so that we can give it a chance to handle more events that might have occurred since its last execution. By not returning control to it, we took its ability to handle the events away. I see your point too! It probably should have locked down the front panel once it started handling the event and then should have unlocked it, once it was done. But I'm not sure if this is the behavior we really want. Let's say the loop is busy handling one event and you click a button, which is supposed to lock down the FP. If the FP is not locked down right away, you could generate many other events before the button click event case gets a chance to execute. To avoid this, you could enable locking down FP for the current event. But then, where do you stop? This strategy would have to cascade through all the events, because you won't know when a user might throw in a couple of clicks. Ideally, this shouldn't even be an issue because your event handler should receive all FP events and then send them for processing elsewhere. The event loop should finish only when the VI is "on its way out" and at that time, the FP should be not be expected to let you interact with it.

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

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?

'Cause you hit the button again. Stopping the loop doesn't stop the event queue inherent to the event structure. It locks the front panel, as instructed, until the event is handled. That it will never be handled because the loop is stopped is immaterial.

Turn off "Lock front panel..." for the Done Calibrating:value change event and this will be fixed. When you hit Done Calibrating once, it shuts down the event handling loop. When you click it again, it locks the FP until "this event case completes", but the event never gets a chance to handle this event again and the FP never gets unlocked. That's why you can't click on Stopped? 2.

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.

Yes, it was not a big deal to implement the multi-character functionality (that is what I meant). I did it similar to this when I coded it, but I like the above better. This is the part that will generate some discussion on how to handle it. I have gone ahead and created a separate thread for a Chunking VI so please continue this discussion there (I also posted some code to get the above mentioned functionality). I am going to go ahead and close this review in a couple of days. OpenG will be using the original String To Character Array function (note the name change) as below:

I would like to see both allowed actually. Why not?. Allow top level categories and palettes within the correct programming sub-palette. People access functions in different ways. A different long-term solution would allow me (as a user) to quickly switch the palette into different views depending on what I'm interested in. I would like to see a Company view for example.

Idea-ified

Well I never learned that leason so being the fool that I am I went off and started pushing evnts down into the sub-VI that handle each of the modes the app runs in. I will not multiply words but I will invite you to examine the images I uploaded to the Dark-side that can be found here. This approach lets me develop sub-VI that are clean and focused on only the events that apply to the current operating mode as shown here. If you really want to rad more about this approach see this thread on the Dark-side. Ben

You can wire control references into a Register For Events node to create a dynamic event refnum that can be passed into a subVI. Once in the subVI, perform the registration for your dynamic event refnum. In general, though, it's best to leave a UI-related event structure in the VI it responds to.

Personally, I would like to see this happen, for reasons listed in the OP (namely scope and namespacing) - but this is more from an OpenG Developer POV. Additionally, I think it is inline with the way LabVIEW libraries are heading (or have been heading) too. On a side note, I like the fact the VIs are just VIs for some of the ways I do building (tools etc...), but regardless I think .lvlibs are a positive move forward. What are some of the End User benefits (or downfalls) of such a migration? Please discuss - as I would like to see this topic advance.

Howdy! I am trialing a new model of review for OpenG VIs. I want to enlist the help of the entire LAVA community. If the VI under review is one that you use in your projects, interests you, or you just have a moment free whilst hanging out on LAVA (I mean, where else would you rather be, right?), then please check it out and leave your feedback. The aim is - to steal a line from Christina - to get more eyes on the VIs I am hoping this will lessen the load on individual reviewers whilst increasing the quality of the changes (or proposed changes). This model is based on the assumption that there are a lot of Community folk who would like to contribute to OpenG but don't have the time to commit on a regular basis. The reviews posted may be in the form of specs or actual VIs etc... Feel free to leave your feedback in the form of comments, documents, code (changes, tests) or whatever makes sense! You can get started by checking out the newly proposed Trim Whitespace VI code. The LabVIEW community appreciates your time. Kind regards Jonathon Green OpenG Developer PS - Of course, if you are interested in contributing more to OpenG, please PM me!