refs randbool

refs randbool

refs randbool

randbool

spaces, ++i

spaces, ++i

refs randbool

refs randbool

refs randbool

refs randbool

refs randbool

randbool

k, refs randbool

randbool

refs randbool

refs randbool

fine, could be > 1 too, whatever

not sure why this isnt a >= 2 as well, dont care

✓

spaces, newlines

same

bergh ✓

✓

✓

✓

✓ spaces

✓ spaces

0, 1

refs randbool

refs randbool

refs randbool

☑ spaces unneeded parenthesis, ++i

randbool

randbool

good

As there is some stuff going on with lakeAreaLen below, cant nuke that var on first sight

✓ :-X

✓

✓

✓ spaces, above too

✓ spaces

✓

good! 0.80 -> 0.8

✓ spaces, 0.8, 0

✓ spaces

✓

✓, spaces 0.80, .0.0

0.80 ✓

0, 1

unneeded parenthesis, ✓

0.80, ✓

randbool

✓

Here is for example documentation of analog functions in scilab:

uniform (unf)

Y=grand(m,n,'unf',Low,High) generates random reals uniformly distributed in [Low, High).

uniform (uin)

Y=grand(m,n,'uin',Low,High) generates random integers uniformly distributed between Low and High (included). High and Low must be integers such that (High-Low+1) < 2,147,483,561.

You can also look at numpy.random.randint and numpy.random.random_integers.

Or to other such functions.

(else using Math.random() everytime works too as in this case we know what we get ;-))

randIntInclusive(+this.template.FeedTimeMin, +this.template.FeedTimeMax) seems more readable though than

Math.floor(+this.template.FeedTimeMin + Math.random(+this.template.FeedTimeMax - +this.template.FeedTimeMin + 1))
in particular if we have hundreds of occurances of such things.

Also using Math.round here still doesn't mean that we don't have that non-uniform distribution issue, right? It would just be moved to each occurance, unless we'd add 3 more rounds afaics.

The function of the documentation you have quoted here avoid that issue by enforcing integer arguments. So if we take this as a serious problem, then we could add those rounds here, but not convinced it is.

I expect (but that's subjective) that randIntInclusive(1.6, 5.2) and randintExclusive(1.6, 5.2) return the same thing (if we want to use that kind of stuff) ie random integers numbers uniformly distributed in {2, 3, 4, 5}.

rly, foo[foo.length] does not exists afaiks, ([a,b][2]...) and foodEntities.length - 1 was included right

If elevation var allows Floats, we should use randFloat instead of randInt*.

the sin/cos are multiplied, don't you see the 0* sin/cos and 1*sin/cos?

whoop whoop

isn't randbool here, since 1/3 chance of true and 2/3 of false

Because of cases

@mimo do you have an opinion on this issue?

Does the "Random numbers is a function which should be as fast as possible" argument from http://trac.wildfiregames.com/ticket/4326#comment:11 apply here?

I kind of share that view with that regards.
If a uniform distribution is important (which doesn't seem to be the case with random map scripts or the nr of garrisoned arrows being shot in the current round), then people should lookup the function they use to ensure that, no?

If not, we could change the function to return Math.floor(min) + Math.floor(Math.random() * (Math.floor(max) + 1 - Math.floor(min)));, or the equivalent with Math.round.

It happened after staging about 700 hunks in maps/random/ x.x

I've no strong opinions: i would expect that it is rather the caller which should replace randIntInclusive(x1,x2) by randIntInclusive(Math.floor(x1), Math.floor(x2)) so that he controls what he will get.

But i'm fine with the latest version you wrote, possibly with an intermediate variable for Math.floor(min).

JSdoc comment

We keep it as is for now, added an example and removed the "Math.random library" comment.
We can still change it in a follow up commit in a separate proposal which is likely read by more people as this proposal is really crowded.

Was changed to (-1,1) * factor to be inline with UnitAI jitter thing

Notice our JS Math.random function comes from ScriptInterface.cpp and is defined from ReplaceNondeterministicRNG.
The function using that uses http://en.cppreference.com/w/cpp/numeric/random/uniform_real_distribution whose seed was initialized in rP18604.

Not sure how this should be unified, likely not.

Some places that are not synced like GameSetup.cpp (for autostarted games) use std::rand(). Unifying not worthy.

In case someone finds something worthy do change in C++ -> other proposal

RandomInt was exclusive, so this changes simstate, but the change is legitimate.
Those are the only 2 occurances of the old randomInt function!