lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


The manual does state that "No guarantees can be given for its
statistical properties." I'm no maths expert, but this seems
especially true if rand can indeed return values greater than
RAND_MAX, as is claimed for SunOS (unless its range is exactly a
multiple of RAND_MAX).

When I looked at the relevant code in lmathlib.c, though, something
else occured to me. For reference, here is that code:

---------->8----------
static int math_random (lua_State *L) {
  /* the `%' avoids the (rare) case of r==1, and is needed also because on
     some systems (SunOS!) `rand()' may return a value larger than RAND_MAX */
  lua_Number r = (lua_Number)(rand()%RAND_MAX) / (lua_Number)RAND_MAX;
  switch (lua_gettop(L)) {  /* check number of arguments */
    case 0: {  /* no arguments */
      lua_pushnumber(L, r);  /* Number between 0 and 1 */
      break;
    }
    case 1: {  /* only upper limit */
      int u = luaL_checkint(L, 1);
      luaL_argcheck(L, 1<=u, 1, "interval is empty");
      lua_pushnumber(L, floor(r*u)+1);  /* int between 1 and `u' */
      break;
    }
    case 2: {  /* lower and upper limits */
      int l = luaL_checkint(L, 1);
      int u = luaL_checkint(L, 2);
      luaL_argcheck(L, l<=u, 2, "interval is empty");
      lua_pushnumber(L, floor(r*(u-l+1))+l);  /* int between `l' and `u' */
      break;
    }
    default: return luaL_error(L, "wrong number of arguments");
  }
  return 1;
}
----------8<----------

Firstly, the range returned by math.random() is stated in the manual
to be in the range [0,1) which (I believe) means  the 1 is exclusive
(i.e. it should never actually return 1). I think in the range from C
rand() the RAND_MAX is inclusive. So, the (original) scaling
calculation done in lmathlib.c tells me math.random() can actually
return 1. OP's patch prevents this, although I don't believe that
patch is an improvement to the statistical properties of the returned
value. I believe the original calculation preserves the statistical
properties of whatever is returned by rand(), except for the SunOS
issue. But again, I'm no maths expert.

Secondly, when arguments are passed to math.random to indicate a
desired range, according to the manual, the returned value is
inclusive of both the min and max value of that range. But due to the
first issue, the returned value could potentially exceed the requested
maximum value, by 1 (i.e. in case 1, if r==1 and u==1 then
floor(1*1)+1 == 2). This is fixed if the range of 'r' is made to be
exclusive of 1. Although, to improve it's statistical properties, the
calculation should rather be "floor(r*u+.5)", I think.

Cheers


2008/9/18 Atry <pop.atry@gmail.com>:
> In math_random(), whether rand() returns 0 or RAND_MAX, the result of
> math_random() would be 0. It should modulo RAND_MAX + 1 instead of
> modulo RAND_MAX.
>
> --- lua-5.1.4/src/lmathlib.c
> +++ lua-5.1.4/src/lmathlib.c
> @@ -181,7 +181,7 @@ static int math_max (lua_State *L) {
>  static int math_random (lua_State *L) {
>   /* the `%' avoids the (rare) case of r==1, and is needed also because on
>      some systems (SunOS!) `rand()' may return a value larger than RAND_MAX */
> -  lua_Number r = (lua_Number)(rand()%RAND_MAX) / (lua_Number)RAND_MAX;
> +  lua_Number r = (lua_Number)(rand()%(RAND_MAX + 1)) /
> (lua_Number)(RAND_MAX + 1);
>   switch (lua_gettop(L)) {  /* check number of arguments */
>     case 0: {  /* no arguments */
>       lua_pushnumber(L, r);  /* Number between 0 and 1 */
>