So say I want to randomize between 0-10. Well, the addition numbers would be 1, 2, 4, and 3. With these numbers to be added, you can land on 7 two different ways: 1 + 2 + 4; 3 + 4. The odds aren't even because the last number to be added in the countoff does not satisfy the aforementioned equation.
I thought this map could randomize between 1 and 10 with nearly equal odds.
Now you're saying it can't though?
None.
So say I want to randomize between 0-10. Well, the addition numbers would be 1, 2, 4, and 3. With these numbers to be added, you can land on 7 two different ways: 1 + 2 + 4; 3 + 4. The odds aren't even because the last number to be added in the countoff does not satisfy the aforementioned equation.
I thought this map could randomize between 1 and 10 with nearly equal odds.
Now you're saying it can't though?
It is nearly equal odds. If you want it perfect, your last addition amount needs to be a result from inputting an integer into that equation. And 3 isn't.
None.
Couldn't you just do 2^4 and re-randomize values of 11-16 until you achieve a number between 1-10?
None.
Then couldn't you just randomize 2^3 + 2^1 + 2^0 in one cycle and it would be equally random (as far as Starcraft is concerned).
None.
2^0 = 1.
And the equation is actually 2^(x-1) guys, because the first number in the sequence needs to be 1, which is done with a starting number of 1 as x, because 1-1 = 0, and anything to the 0th power = 1. The second number in the sequence is 2 for x, which results as 2 for the DC and a 1 for x. And so on, and so forth.
None.
How would it, for instance, randomly generate a number from 1 to 3? Anyone care to walk me through this map?
How many cycles would it take to do this?
This particular map is not designed to do that. It can, however, be modified to fit your needs. In fact, I think I'll do that if I get the time and energy. If it would be modified in such a way, it would still take 1 trigger loop only.
Guys, remember: this map gives you either a 'true' or 'false' result with the probability of it being 'true' specified by you.
From a PM I sent:
You want a yes/no random outcome with the probability of it being a YES of 'a' ('a' goes from 1 to 99). First, we generate a random number between 0 and 32767 using one switch (if you don't know how to randomize a number using one switch, look it up in the wiki). Now, we have a random number. Leave the random number you just got alone for a second and switch your mind to the probability of 'success' - 'a'. Let us calculate the value X=a*32767, which is a number between 1 and 32767 (because 0<a<1). Now imagine the real number line with 0 and 32767 in it. Now draw a thick red line between 0 and X. The red line represents the probability of success. We have a random number that lands randomly between 0 and 32767, so the longer the red line is, the higher the chance the random number will fall on the red line. Detect which number is bigger - X or the random number. If X is bigger, it is on the red line, if the random number is bigger, X is off the red line. When the number X is on the red line, we call it a 'YES', when it is off the red line, we call it a 'NO'.
Post has been edited 1 time(s), last time on Dec 14 2009, 6:41 pm by JaFF.
None.
UPDATE
Some people asked about producing a random number within some range. Behold, the
Uniform Randomizer! It gives you a value between 0 and 999 each trigger loop. Uses up only 3 deathcounters and 1 switch. The amount of triggers can be lowered for practical purposes by about... 160. This is just I something I made in 30 minutes to demonstrate one of the possible ways to do it (and, probably the easiest one). If you run the map, you'll see that it gives you a kind of histogram - a set of points on the xy plane. Each point moving up represents a hit on a value within 10 units (0 to 9, 10 to 19, etc.).
This allows you to make quite accurate distributions with 0.05% accuracy. Anyone tempted to make a 'horse race' map where you have to bet depending on the conditions?
The first post has been updated with the same info.
None.
This allows you to make quite accurate distributions with 0.05% accuracy.
What did you use to calculate that?
Oh, and if you're willing to accept small distribution errors, a simpler way is to generate a value (0 to 2^n-1) for sufficiently large n, and then reduce modulo 1000 - via binary countoffs, like, define A = (2^a)*1000, where a is the largest integer value such that the resulting A is <= 2^n-1. Then just have triggers to subtract A, then A/2, A/4....all the way down to 1000. And the result is your (nearly) uniform distribution. It has the benefit over the method in your map in that you dont have to calculate "ranges" of values to map to a certain result.
The small inaccuracy comes from the distribution of 2^n values over 1000 "boxes", which, since 1000 never divides 2^n, is going to result in some "boxes" modulo 1000 to have one more (0 to 2^n) value mapped to them. But by increasing n by 1, regardless of what n is, you'll cut down on the inaccuracy by a factor of 2. For example in n = 16, you've got a range of 2^16, or 65536 values. 536 of the 1000 "boxes" are going to have 66 rand values mapped to them, as opposed to 65 for the rest. It should be straightforward to see how increasing your n value improves the uniformity.
None.
This allows you to make quite accurate distributions with 0.05% accuracy.
What did you use to calculate that?
Oh, and if you're willing to accept small distribution errors, a simpler way is to generate a value (0 to 2^n-1) for sufficiently large n, and then reduce modulo 1000 - via binary countoffs, like, define A = (2^a)*1000, where a is the largest integer value such that the resulting A is <= 2^n-1. Then just have triggers to subtract A, then A/2, A/4....all the way down to 1000. And the result is your (nearly) uniform distribution. It has the benefit over the method in your map in that you dont have to calculate "ranges" of values to map to a certain result.
The maximum error is the smallest increment divided by two. Smallest increment is 0.1%, so maximum error is 0.05%. This is, of course, under the assumptions that SC has unbiased randomization and all my calculations performed did not introduce any bias (we know they did, but it is too small to be take into account).
And yes, the method you describe is also possible. I just didn't feel like doing binary countoffs.
If you look closer, the method I'm using gives a slightly higher probability to the values 0 and 9, too. But it's so small (9/209715, I think) that you can just ignore it.
Edit:
HOW IT WORKSIt is done in 3 stages, called 'stage 100', 'stage 10' and 'stage 1'. They are almost identical. One stage consists of this: get a random number between 0 and (2^21) - 1 = 2097151. In stage 100, if the random number is between 0 and 209715, we add nothing, if it is between 209716 and 419430, we add 100, and so on. Basically, we split the range of the random number into 10 approximately equal segments and add a 100, 200, 300, etc. when it hits the corresponding segment. This gives us one of the following numbers: 0, 100, 200 ... 900. Then, in stage 10, we add 0, 10, 20 i nthe same way. Then comes stage 1, when we add 0, 1, 2, etc.
That's basically it.
Post has been edited 2 time(s), last time on Dec 23 2009, 1:23 pm by JaFF.
None.
I do stuff and thingies... Try widening and reducing the number of small nooks and crannies to correct the problem.
Excellent. I understood it by just opening ~12 triggers in the map before reading this.
When I first clicked on this thread I was like, "Why don't they just use binary?" Then I looked at the map and was like, "Oh, it does use binary."
'bout time.
None.
When I first clicked on this thread I was like, "Why don't they just use binary?" Then I looked at the map and was like, "Oh, it does use binary."
'bout time.
Binary has been used in mapping since forever.
None.
I happen to live under a rock
None.
I happen to live under a rock
It's ok I used to at one point in time as well..
None.
I assume you mean 1-2-4-8-16-32, etc...
It's more efficient to double them than to go up by one. You'll note that you can get any number with any combination of numbers which aren't repeated (7 = 1+2+4, 13 = 1+4+8). Basically what's going on is you convert the decimal into binary, then back into decimal. The user can't see the binary, he just has to know it's there. Also, lookup binary countoffs in the wiki.
"Parliamentary inquiry, Mr. Chairman - do we have to call the Gentleman a gentleman if he's not one?"