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.

Couldn't you just do 2^4 and re-randomize values of 11-16 until you achieve a number between 1-10?

That could take forever.

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

What

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.

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:


Post has been edited 1 time(s), last time on Dec 14 2009, 6:41 pm by JaFF.

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.

I made that back in '05.

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.

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 WORKS
It 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.

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.

Binary has been used in mapping since forever.

I happen to live under a rock

It's ok I used to at one point in time as well..

Why is it necessary to double the death count? Why couldn't you just go up by values of 1?

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.

Nevermind. devilesk and ultimoo helped me out on this one.

Post has been edited 3 time(s), last time on Dec 28 2009, 6:53 am by Ryan.