Re: Functions to return random numbers in a given range - Mailing list pgsql-hackers

From Aleksander Alekseev
Subject Re: Functions to return random numbers in a given range
Date
Msg-id CAJ7c6TP6bgP5q1NRS0byLas01N6xe49zYyv9+aM8V4eXc-DuKQ@mail.gmail.com
Whole thread Raw
In response to Re: Functions to return random numbers in a given range  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: Functions to return random numbers in a given range
List pgsql-hackers
Hi,

> Interestingly, the cfbot didn't pick up on the fact that it needed
> rebasing. Anyway, the copyright years in the new file's header comment
> needed updating, so here is a rebase doing that.

Maybe I'm missing something but I'm not sure if I understand what this
test tests particularly:

```
-- There should be no triple duplicates in 1000 full-range 32-bit random()
-- values.  (Each of the C(1000, 3) choices of triplets from the 1000 values
-- has a probability of 1/(2^32)^2 of being a triple duplicate, so the
-- average number of triple duplicates is 1000 * 999 * 998 / 6 / 2^64, which
-- is roughly 9e-12.)
SELECT r, count(*)
FROM (SELECT random(-2147483648, 2147483647) r
      FROM generate_series(1, 1000)) ss
GROUP BY r HAVING count(*) > 2;
```

The intent seems to be to check the fact that random numbers are
distributed evenly. If this is the case I think the test is wrong. The
sequence of numbers 100, 100, 100, 100, 100 is as random as 99, 8, 4,
12, 45 and every particular sequence has low probability. All in all
personally I would argue that this is a meaningless test that just
fails with a low probability. Same for the tests that follow below.

The proper way of testing PRNG would be to call setseed() and compare
return values with expected ones. I don't mind testing the proposed
invariants but they should do this after calling setseed(). Currently
the patch places the tests right before the call.

-- 
Best regards,
Aleksander Alekseev



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Rename setup_cancel_handler in pg_dump
Next
From: Pavel Stehule
Date:
Subject: Re: Bytea PL/Perl transform