how can i make a textbox generate a random number bettween 1-100 when i click a button?
Printable View
how can i make a textbox generate a random number bettween 1-100 when i click a button?
If you're talking *truly* random numbers (numbers from rnd() aren't truly random, they follow a random-looking set path) it is a bit more difficult...but here's my way. You need "text1" and "command1" on a form before copying this into your source
VB Code:
Notice the word "Randomize"...this ensures that the results are truly random. Try commenting it out (add a ' before the word) and see the results...run it twice and note the numbers both times, they'll be the same ones
The reason I told you that numbers from rnd() aren't random is simple...rnd() is a PRNG (pseudo-random number generator) and is useful in many functions people write. You can *also* add a number after the word "Randomize" as a seed for the random numbers it generates...this is very useful as well :-)
Tyvm! :)
and Randomize should only be called once in application (in Form_Load or Sub Main) otherwise the numbers will be even less random than their current not-so-random randomness :)
Not totally true, Bush...from what I gather, randomize uses the ticks since windows was started, so in actual fact it is still just as random if you call randomize again but it's a different sort of random unless you actually provide the seed number yourself :-)
bushmobile was totally correct, see here for a full explanation:
http://www.vbforums.com/showthread.php?t=369993
as always ;)Quote:
Originally Posted by si_the_geek
:lol:
also, this might be an interesting read: An Examination of Visual Basic's Random Number Generation
Still not totally true. rnd() does not generate random numbers, there's no such thing as a random number in Visual Basic. In much the same way that you can go from point A to point B (as in navigating roads) by going left right left right rather than right left right left, using randomize again would just add another branch to the route you take. Chaos theory (I think it's chaos theory...not sure) itself states that it's just as likely that you'd never ever ever get the number 1000 in 500 million calls to RND as you are to get 1 every single time if it's truly random, and the graph at that link simply shows that the test proved that randomness doesn't exist. For most purposes, it is a requirement that every number be used at least once so with regards to programming it is useful to follow that rule, but using Randomize again does NOT make it any less random than before...only less *uniformly* random (as in random but fairly shared around in the long term)
I refer you to:
http://en.wikipedia.org/wiki/PRNG
and specifically the second section near the top which says "Most pseudo-random generator algorithms produce sequences which are uniformly distributed by any of several tests."
i think you're confusing yourself a bit - if something is random then after 500 million calls you would expect to see a uniform linear distribution - it's impossible for computers to be truely random so they have to emulate it, so the PRNGs create algorithms which "produce sequences which are uniformly distributed"
as Moeur demonstrates multiple calls to Randomize reduce the uniformity of distribution and hence the pseudo-randomness.
Again not quite true. After 500 million calls, you wouldn't expect any one thing over another...any one number could be greatly higher or lower than another.
However, I do have something to add...there's a reason why VB's rnd() feature returns a uniform result...the way it's written, PRNGs generally have a shelflife with regards to their randomness...to ask a PRNG to generate 15m (or 500m) random numbers without repeating the starting sequence at any time is asking too much...some PRNGs have the ability to do this 500m or more times, but all will eventually loop back to the start and repeat again...it's likely that VB's rnd() actually has looped many times in moer's test which showed the uniform number distribution and this is why all values are uniform :-)
No, that's wrong. After X (where X is large) calls i would expect there to be no statistically significant difference between the lowest and highest frequencies - as X tends to infinity all frequencies should be even (i.e. a straight line)Quote:
Originally Posted by smUX
More discussion (#5 through #8)
This also helped me, when I wanted to randomize a number i'd enter them all in a listbox then use some code on a timer, it was irritating to do, makes my game much easier with the dice rolls ^_^
If you bring infinity into it, anything is possible...yes, all frequencies *could* be even at some point, but if it were truly random they could just as easily slope up or down or be totally *random*...that's what the word random means :-P
VB's PRNG generates a *uniform* random range.
BTW, I am running my own tests at the moment with this...generating a few million numbers and calculating how many times each one comes up :-)
it's not a case of it *could* happen - if it didn't happen (as X approached infinity) then then whatever was randomly generating the numbers could not be considered random.Quote:
Originally Posted by smUX
you're missing the point of what random means.
if it's random then there is an equal chance of any number being chosen - therefore the most likely frequency of a number is:
(total number of reps) / (number of outcomes)
as the number of reps increases so the actual freq will approach the theoretical freq.
you can see that deviations from this theoretical freq are less likely than adherence to it - as in the chance of just one number coming up each time same infintely less likely than all the freq. roughly being the same amount
When it reaches infinity, yes...however, on the path to infinity (technically impossible but let's ignore that) it's possible that anything can happen...it could theoretically still never every generate a number 1 until the last few generations before infinity.
You're forgetting what "infinity" means :-P
A truly random distribution of integers 1-10 would show an almost flat line for 500 million calls (or even for 500,000). If it didn't it's not truly random. (Unless you redefine "random" to mean something other than its mathematical definition.)
If there's user intervention in the program, a random number is the lower n bits of the system time, manipulated any way you need. (The old Z-80 R register made a nice RNG.)
I wrote this to test randomness and include the important stat called VARIANCE. It shows the highest and lowest number of instances of each number and the difference between these (called the variance). The higher the variance, the less uniform the PRNG is :-)
After clicking stop, it updates the graph and stats, clicking start again continues from where it left off...reset before using a different method (I could have forced that to happen when you switch...too lazy :-))
For simplicity, mine also does numbers between 1 and 1000
Edit: Minor bug messed with the stats...fixed in this update
After running 5.1m random numbers, here's the results without randomizing each time:
Min: 4934 Max: 5329 Variance: 395
With randomizing each time:
Min: 4927 Max: 5337 Variance: 410
Interestingly there's not much difference there. Weirdly, at the start the one with randomize was gaining fast on the first test but it stopped gaining :-)
ok
firstly i said 'tend to infinity' which just means as the numbers get larger.
secondly that's not the variance, that's just the highest minus the lowest - see here
thirdly i don't know why your code is weird, but modify this sub:run it with the Randomize commented and run it without it commented and see the difference.VB Code:
fourthly, if you still don't get it then i can't be bothered to argue anymore - this in't conjecture. You seem to have complete misundertanding about what the distribution should be like and how probability works...
And I quote: "In probability theory and statistics, the variance of a random variable (or equivalently a probability distribution) is a measure of its statistical dispersion, indicating how its possible values are spread around the expected value."
The variance, in this case, is the difference between the min and the max and varies around the "expected value" which is the total number of loops done divided by 1000...so if 5.1m is the total loops, 5100 is the expected value and the variance is the difference between that and the lowest/highest...I think that variance should really be +/- but it points out what I am trying to say. I might be thinking Deviation, but Variance is pretty much the same thing.
Tell me one thing...if you rolled a dice 1000 times, is it possible for it to roll a 6 every time (even if it's not loaded :-))...statistically improbable, but is it impossible? I don't think it is impossible :-P
In much the same way, even distribution is statistically probable but not clear-cut every time...if it was, it wouldn't be random :-P
Variance (and deviation) is a measure of spread. Variance is calculated as the average squared deviation from the expected mean. What you're doing (Max - Min) is not a measure of spread, consider the following outcomes:Quote:
Originally Posted by smUX
500 randomly generated numbers between 1 and 10now tell me which is the more spread out data...Code:Number: 1 2 3 4 5 6 7 8 9 10
Try 1: 50 50 75 50 50 50 25 50 50 50
Try 2: 60 40 35 55 72 30 43 29 66 70
with that statement you've managed to confirm that you have no understanding of probability and distribution, thanks.Quote:
Originally Posted by smUX
I agree with Bush...
The VB random number generator is not the best pseudo-random number generator you could use but works well enough for games and Monte Carlo type simulations as long as you don't exceed the period of the algorithm.
The period of the VB rnd statement is 16.77M invocations. Another problem with the VB method is the randomize statement. It takes a single datatype as input but truncates that value internally so that only two bytes are used of the original seed. This means that even though you think you are using many different seeds to start the generator you are limited to only 65535 unique values.
For encryption tasks VB's rnd function's periodicity is too low. That Wikipedia article mentions some methods that are good enough for encryption, but these are still not truly random.
If you really want to generate true random numbers then you cannot do this in software and would have to rely on an external hardware device such as a noise generator.
agreed?
I have to agree with Bush too. I've run tests on Randomize myself, and had results very similar to moeur's. What is making the distribution random has nothing to do with the seed, it has everything to do with the sequence. Logical pseudo-random sequences depend on the previously generated number to be put back into the algorithm. If you call Randomize every time, it gets re-seeded with an external number. You would be essentially ignoring the random number generator entirely and relying exclusively on a sequence of initial seeds. If your initial seed is the tick count, and you have random numbers being generated in a loop that takes 10ms to execute, all of your seeds will be evenly spaced. Addressing some specific points:
Variance involves squaring the deviation, so it can never be negative...Quote:
Originally Posted by smUX
Ummmm.... This is just wrong. The more "random" a distribution, the more even it will become over successive iterations.Quote:
Originally Posted by smUX
What you describe isn't truely the variation. The "expected value" is the mean, and has nothing to do with the amount of iterations you perform. If your max value is 100 and the minimum value is -100, the expected value is 0. With the Rnd() function the expected value would be ~.5, as it returns a number between 0 and 1. The variance is the average distance of all data points from the mean, so a truely random sequence would have a variance that approached zero.Quote:
Originally Posted by smUX