Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #395879 > unrolled thread
| Started by | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| First post | 2025-12-22 08:48 +0000 |
| Last post | 2026-01-08 02:57 +0000 |
| Articles | 20 on this page of 185 — 25 participants |
Back to article view | Back to comp.lang.c
srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-22 08:48 +0000
Re: srand(0) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-22 06:44 -0500
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-22 13:18 +0100
Re: srand(0) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-22 12:13 -0500
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-22 18:41 +0100
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-22 20:45 +0200
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-22 21:16 +0000
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-22 22:19 +0100
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-22 22:57 +0100
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-23 11:18 +0200
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-23 10:54 +0100
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-23 13:50 +0200
Re: srand(0) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-23 18:29 -0500
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-23 16:30 -0800
Re: srand(0) antispam@fricas.org (Waldek Hebisch) - 2025-12-23 17:54 +0000
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-24 00:08 +0200
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-24 02:02 +0000
Re: srand(0) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-23 23:43 -0500
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-24 05:34 +0000
Re: srand(0) antispam@fricas.org (Waldek Hebisch) - 2025-12-24 09:00 +0000
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-24 12:12 +0200
Article of Melissa O'Nail (Was: srand(0)) Michael S <already5chosen@yahoo.com> - 2025-12-28 02:44 +0200
Re: Article of Melissa O'Nail antispam@fricas.org (Waldek Hebisch) - 2025-12-28 05:38 +0000
Re: Article of Melissa O'Nail Michael S <already5chosen@yahoo.com> - 2025-12-28 12:35 +0200
Re: Article of Melissa O'Nail Michael S <already5chosen@yahoo.com> - 2026-01-05 14:21 +0200
Re: Article of Melissa O'Nail antispam@fricas.org (Waldek Hebisch) - 2026-01-07 10:51 +0000
Re: Article of Melissa O'Nail Michael S <already5chosen@yahoo.com> - 2026-01-08 14:03 +0200
Re: Article of Melissa O'Nail Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-08 09:40 -0800
Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-08 09:26 -0800
Re: srand(0) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-24 13:48 -0800
Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 08:41 -0800
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-01-08 01:06 +0200
Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-03 05:26 -0800
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-02-03 16:37 +0200
Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-17 23:47 -0800
Re: srand(0) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-02-18 11:21 +0000
Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-19 10:01 +0100
Re: srand(0) James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-02-19 14:33 -0500
Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-19 20:47 +0100
Re: srand(0) James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-02-20 16:01 -0500
Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-21 11:09 +0100
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-19 14:39 -0800
Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-20 09:16 +0100
Re: srand(0) Paul <nospam@needed.invalid> - 2026-02-23 08:32 -0500
Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-23 16:05 +0100
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-02-23 19:59 +0200
Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-23 20:06 +0100
Re: srand(0) Paul <nospam@needed.invalid> - 2026-02-23 15:24 -0500
Re: srand(0) Axel Reichert <mail@axel-reichert.de> - 2026-02-24 07:08 +0100
Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-24 10:24 +0100
Re: srand(0) Axel Reichert <mail@axel-reichert.de> - 2026-02-26 19:13 +0100
Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-24 05:22 -0600
Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-24 23:09 -0600
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-25 09:51 +0100
Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-25 04:24 -0600
Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 07:50 -0800
Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 07:46 -0800
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-01-07 18:14 +0200
Re: srand(0) Kaz Kylheku <046-301-5902@kylheku.com> - 2025-12-22 19:16 +0000
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-22 22:35 +0100
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-23 07:24 +0000
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-23 09:59 +0100
Re: srand(0) Michael Bäuerle <michael.baeuerle@stz-e.de> - 2025-12-23 11:09 +0100
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-23 14:49 +0000
Re: srand(0) scott@slp53.sl.home (Scott Lurndal) - 2025-12-23 16:13 +0000
Re: srand(0) richard@cogsci.ed.ac.uk (Richard Tobin) - 2025-12-23 19:05 +0000
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-23 02:16 -0800
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-23 14:47 +0000
Re: srand(0) scott@slp53.sl.home (Scott Lurndal) - 2025-12-23 16:08 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-24 15:44 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-23 07:17 +0000
Re: srand(0) David Brown <david.brown@hesbynett.no> - 2025-12-23 08:25 +0100
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-23 14:45 +0000
Re: srand(0) David Brown <david.brown@hesbynett.no> - 2025-12-23 19:15 +0100
Re: srand(0) John McCue <jmclnx@gmail.com.invalid> - 2025-12-23 00:39 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-23 02:17 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-23 14:55 +0000
Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-24 23:35 -0600
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-26 08:23 +0000
Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-26 14:48 -0600
Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-26 15:12 -0600
Re: srand(0) Ike Naar <ike@sdf.org> - 2025-12-23 06:49 +0000
Re: srand(0) John McCue <jmclnx@gmail.com.invalid> - 2025-12-23 20:37 +0000
Re: srand(0) Ike Naar <ike@sdf.org> - 2025-12-24 15:22 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-23 07:25 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-24 06:16 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-24 15:21 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-24 19:00 +0000
Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-25 03:07 -0600
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-25 19:31 +0000
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-25 21:14 +0100
Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-25 15:29 -0600
Re: srand(0) Paul <nospam@needed.invalid> - 2025-12-25 23:25 -0500
Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-25 23:41 -0600
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-26 05:42 +0000
Re: srand(0) Paul <nospam@needed.invalid> - 2025-12-26 01:52 -0500
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-26 07:56 +0000
Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-26 04:48 -0600
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-24 10:51 +0200
Re: srand(0) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-24 00:59 -0800
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-24 15:28 +0000
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-24 17:44 +0200
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-24 16:17 +0000
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-24 17:53 +0100
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-24 17:27 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-24 17:33 +0000
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-24 20:16 +0200
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-25 02:01 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-25 03:17 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-26 08:13 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-25 04:30 +0000
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-25 09:10 +0100
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-26 08:08 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-30 06:07 +0000
Re: srand(0) scott@slp53.sl.home (Scott Lurndal) - 2025-12-30 18:42 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-31 02:01 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-31 03:10 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-31 03:28 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-31 09:37 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-01 07:32 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-01 19:02 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-01 19:20 +0000
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-01-01 21:53 +0200
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-01 23:50 +0000
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-01-02 14:32 +0200
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-01-02 16:18 +0200
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-02 20:52 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-02 20:46 +0000
Re: srand(0) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2026-01-03 04:08 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-03 04:39 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-03 14:24 +0000
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-01-03 20:38 +0200
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-30 19:37 -0800
Re: srand(0) scott@slp53.sl.home (Scott Lurndal) - 2025-12-31 17:24 +0000
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 15:17 -0800
Re: srand(0) Paul <nospam@needed.invalid> - 2025-12-31 12:30 -0500
Re: srand(0) bart <bc@freeuk.com> - 2025-12-31 18:42 +0000
Re: srand(0) Paul <nospam@needed.invalid> - 2025-12-31 15:07 -0500
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-31 22:18 +0200
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-31 20:55 +0000
Re: srand(0) bart <bc@freeuk.com> - 2025-12-31 22:57 +0000
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 16:00 -0800
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-01 01:03 +0000
Re: srand(0) bart <bc@freeuk.com> - 2026-01-01 14:05 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-01 19:03 +0000
Re: srand(0) bart <bc@freeuk.com> - 2026-01-01 20:28 +0000
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 15:29 -0800
Re: srand(0) highcrew <high.crew3868@fastmail.com> - 2026-01-01 00:31 +0100
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 16:05 -0800
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-31 15:29 +0200
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-31 20:52 +0000
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 15:14 -0800
Re: srand(0) Geoff <geoff@invalid.invalid> - 2026-01-05 20:00 -0800
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 15:03 -0800
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-30 19:35 -0800
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-31 04:51 +0000
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-31 15:15 +0200
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-31 20:51 +0000
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 15:00 -0800
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-01-01 01:45 +0200
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 16:34 -0800
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-01 07:23 +0000
Re: srand(0) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2026-01-01 02:01 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-01 02:29 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-30 06:34 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-30 14:05 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-28 05:51 +0000
Re: srand(0) scott@slp53.sl.home (Scott Lurndal) - 2025-12-24 17:08 +0000
Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 07:39 -0800
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-07 13:54 -0800
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-08 15:34 +0000
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-08 14:44 -0800
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-09 06:06 +0000
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-08 22:46 -0800
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-09 22:38 +0000
Re: srand(0) scott@slp53.sl.home (Scott Lurndal) - 2026-01-09 23:27 +0000
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-09 17:09 -0800
Re: srand(0) Kaz Kylheku <046-301-5902@kylheku.com> - 2026-01-10 19:44 +0000
Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-09 00:36 -0800
Re: srand(0) Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-23 11:04 +0100
Re: srand(0) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-23 21:44 -0800
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-24 15:41 +0000
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-24 18:04 +0100
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-25 05:41 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-08 02:57 +0000
Page 1 of 10 [1] 2 3 … 10 Next page →
| From | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| Date | 2025-12-22 08:48 +0000 |
| Subject | srand(0) |
| Message-ID | <10ib0ka$3cgil$1@dont-email.me> |
Is it incorrect to use 0 (zero) to seed srand()?
int seed = (argc >= 2 && strlen(argv[1]) == 9)
? atoi(argv[1])
: (int)(time(NULL) % 900000000 + 100000000);
srand(seed);
--
:wq
Mike Sanders
[toc] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-12-22 06:44 -0500 |
| Message-ID | <10ibava$2sora$1@dont-email.me> |
| In reply to | #395879 |
On 2025-12-22 03:48, Michael Sanders wrote: > Is it incorrect to use 0 (zero) to seed srand()? > > int seed = (argc >= 2 && strlen(argv[1]) == 9) > ? atoi(argv[1]) > : (int)(time(NULL) % 900000000 + 100000000); > > srand(seed); No, why whould you think so?
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-12-22 13:18 +0100 |
| Message-ID | <10ibcub$25ihi$2@dont-email.me> |
| In reply to | #395881 |
On 2025-12-22 12:44, James Kuyper wrote: > On 2025-12-22 03:48, Michael Sanders wrote: >> Is it incorrect to use 0 (zero) to seed srand()? >> >> int seed = (argc >= 2 && strlen(argv[1]) == 9) >> ? atoi(argv[1]) >> : (int)(time(NULL) % 900000000 + 100000000); >> >> srand(seed); > > No, why whould you think so? There's number sequence generators that produce 0 sequences if seeded with 0. And maybe the comment in 'man 3 rand', "If no seed value is provided, the rand() function is automatically seeded with a value of 1.", may have fostered his doubt. Janis
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-12-22 12:13 -0500 |
| Message-ID | <10ibu81$2sora$2@dont-email.me> |
| In reply to | #395882 |
On 2025-12-22 07:18, Janis Papanagnou wrote: > On 2025-12-22 12:44, James Kuyper wrote: >> On 2025-12-22 03:48, Michael Sanders wrote: >>> Is it incorrect to use 0 (zero) to seed srand()? >>> >>> int seed = (argc >= 2 && strlen(argv[1]) == 9) >>> ? atoi(argv[1]) >>> : (int)(time(NULL) % 900000000 + 100000000); >>> >>> srand(seed); >> >> No, why whould you think so? > > There's number sequence generators that produce 0 sequences if seeded > with 0. ... The details of how the seed affects the random number sequence are unspecified by the standard. I personally would consider a pseudo-random number generator to be quite defective if there were any seed that produced a constant output. > ... And maybe the comment in 'man 3 rand', "If no seed value is > provided, the rand() function is automatically seeded with a value > of 1.", may have fostered his doubt. The C standard explains that as follows: "If rand is called before any calls to srand have been made, the same sequence shall be generated as when srand is first called with a seed value of 1." (7.24.2.2p2).
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-12-22 18:41 +0100 |
| Message-ID | <10ibvrm$25ihh$2@dont-email.me> |
| In reply to | #395885 |
On 2025-12-22 18:13, James Kuyper wrote:
> On 2025-12-22 07:18, Janis Papanagnou wrote:
>> On 2025-12-22 12:44, James Kuyper wrote:
>>> On 2025-12-22 03:48, Michael Sanders wrote:
>>>> Is it incorrect to use 0 (zero) to seed srand()?
>>>>
>>>> int seed = (argc >= 2 && strlen(argv[1]) == 9)
>>>> ? atoi(argv[1])
>>>> : (int)(time(NULL) % 900000000 + 100000000);
>>>>
>>>> srand(seed);
>>>
>>> No, why whould you think so?
>>
>> There's number sequence generators that produce 0 sequences if seeded
>> with 0. ...
>
> The details of how the seed affects the random number sequence are
> unspecified by the standard. I personally would consider a pseudo-random
> number generator to be quite defective if there were any seed that
> produced a constant output.
I wouldn't have mentioned that if there weren't a whole class of
such functions that expose exactly that behavior by design. Have
a look for PN-(Pseudo Noise-)generators and LFSR (Linear Feedback
Shift Registers). These have been defined to produce random noise
(bit pattern with good statistical distribution). With sophisticated
generator polynomials they produce also sequences of maximum period;
say, for N=31 a non-repeating sequence of length 2^N - 1. The one
element that is missing from the sequence is the 0 (that reproduces
itself).
Technically you pick some bit-values from fixed positions (depending
on the generator polynomial) of the register and xor the bits to shift
the result into the register. Here's ad hoc an example...
#include <stdio.h>
#include <stdint.h>
int main ()
{
uint32_t init = 0x00000038;
uint32_t reg = init;
uint32_t new_bit;
int count = 0;
do {
new_bit = ((reg >> 2) + (reg >> 4) + (reg >> 6) + (reg >> 30))
& 0x1;
reg <<= 1;
reg |= new_bit;
reg &= 0x7fffffff;
count++;
} while (reg != init);
printf ("period: %d\n", count);
}
Janis
>> [...]
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-12-22 20:45 +0200 |
| Message-ID | <20251222204538.00003fc2@yahoo.com> |
| In reply to | #395886 |
On Mon, 22 Dec 2025 18:41:10 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 2025-12-22 18:13, James Kuyper wrote:
> > On 2025-12-22 07:18, Janis Papanagnou wrote:
> >> On 2025-12-22 12:44, James Kuyper wrote:
> >>> On 2025-12-22 03:48, Michael Sanders wrote:
> >>>> Is it incorrect to use 0 (zero) to seed srand()?
> >>>>
> >>>> int seed = (argc >= 2 && strlen(argv[1]) == 9)
> >>>> ? atoi(argv[1])
> >>>> : (int)(time(NULL) % 900000000 + 100000000);
> >>>>
> >>>> srand(seed);
> >>>
> >>> No, why whould you think so?
> >>
> >> There's number sequence generators that produce 0 sequences if
> >> seeded with 0. ...
> >
> > The details of how the seed affects the random number sequence are
> > unspecified by the standard. I personally would consider a
> > pseudo-random number generator to be quite defective if there were
> > any seed that produced a constant output.
>
> I wouldn't have mentioned that if there weren't a whole class of
> such functions that expose exactly that behavior by design. Have
> a look for PN-(Pseudo Noise-)generators and LFSR (Linear Feedback
> Shift Registers). These have been defined to produce random noise
> (bit pattern with good statistical distribution). With sophisticated
> generator polynomials they produce also sequences of maximum period;
> say, for N=31 a non-repeating sequence of length 2^N - 1. The one
> element that is missing from the sequence is the 0 (that reproduces
> itself).
>
> Technically you pick some bit-values from fixed positions (depending
> on the generator polynomial) of the register and xor the bits to shift
> the result into the register. Here's ad hoc an example...
>
> #include <stdio.h>
> #include <stdint.h>
>
> int main ()
> {
> uint32_t init = 0x00000038;
> uint32_t reg = init;
> uint32_t new_bit;
> int count = 0;
> do {
> new_bit = ((reg >> 2) + (reg >> 4) + (reg >> 6) + (reg >>
> 30)) & 0x1;
> reg <<= 1;
> reg |= new_bit;
> reg &= 0x7fffffff;
> count++;
> } while (reg != init);
> printf ("period: %d\n", count);
> }
>
>
> Janis
>
> >> [...]
>
Pay attention that C Standard only requires for the same seed to always
produces the same sequence. There is no requirement that different
seeds have to produce different sequences.
So, for generator in your example, implementation like below would be
fully legal. Personally, I wouldn't even consider it as particularly
poor quality:
void srand(unsigned seed ) { init = seed | 1;}
[O.T.]
In practice, using LFSR for rand() is not particularly bright idea for
different reason: LFSR is a reasonably good PRNG for a single bit, but
not when you want to generate a group of 31 pseudo-random bits. In
order to get 31 new bits, without predictable repetitions from the
previous value, you would have to do 31 steps. That's slow! The process
can be accelerate by generation of several bits at time via look up
tables, but in order to get decent speed the table has to be rater big
and using big tables in standard library is bad sportsmanship.
It seems that overwhelming majority C RTLs use Linear Congruential
Generators, probably because for Stanadard library compactness of both
code and data is considered more important than very high speed (not
that on modern HW LCGs are slow) or superior random properties of
Mersenne Twisters.
[/O.T]
IMHO, decent PRNG with decent thread-safe interface (not POSIX
imbecile rand_r() ) should have been part of the C Standard
library at least since C11. But somehow it did not happen until now.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-12-22 21:16 +0000 |
| Message-ID | <10iccg5$3qmn4$3@dont-email.me> |
| In reply to | #395887 |
On Mon, 22 Dec 2025 20:45:38 +0200, Michael S wrote: > ... (not POSIX imbecile rand_r() ) ... Obsoleted in newer POSIX, I see.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-12-22 22:19 +0100 |
| Message-ID | <10icclt$25ihh$3@dont-email.me> |
| In reply to | #395887 |
On 2025-12-22 19:45, Michael S wrote: > [...] > In practice, using LFSR for rand() is not particularly bright idea for > different reason: LFSR is a reasonably good PRNG for a single bit, but > not when you want to generate a group of 31 pseudo-random bits. [...] Please note that I've not suggested that. I had been merely answering your question concerning Michael's doubts... >> Is it incorrect to use 0 (zero) to seed srand()? > No, why whould you think so? There's number sequence generators that produce 0 sequences if seeded with 0. Janis
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-12-22 22:57 +0100 |
| Message-ID | <10ices7$25ihi$5@dont-email.me> |
| In reply to | #395887 |
On 2025-12-22 19:45, Michael S wrote: > [...] LFSR is a reasonably good PRNG for a single bit, but > not when you want to generate a group of 31 pseudo-random bits. In > order to get 31 new bits, without predictable repetitions from the > previous value, you would have to do 31 steps. That's slow! The process > can be accelerate by generation of several bits at time via look up > tables, but in order to get decent speed the table has to be rater big > and using big tables in standard library is bad sportsmanship. Yes. But mind that the speed is also depending on what quality you need. For example; I used the PN-generator to create bit-sequences (as you also suggest). For another application both, PN-LFSR and LCG (that you mention below), were inacceptable; we used a cipher to create the random data. (If you compare the speed of creating the cipher to a bit-shift-register the latter looks really fast.) > > It seems that overwhelming majority C RTLs use Linear Congruential > Generators, probably because for Stanadard library compactness of both > code and data is considered more important than very high speed (not > that on modern HW LCGs are slow) or superior random properties of > Mersenne Twisters. For "standard applications" I always used the simple LCGs; simple and fast. Or whatever the tools or library provided; which were mostly anyway LCGs. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-12-23 11:18 +0200 |
| Message-ID | <20251223111855.000035ba@yahoo.com> |
| In reply to | #395894 |
On Mon, 22 Dec 2025 22:57:27 +0100 Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > On 2025-12-22 19:45, Michael S wrote: > > [...] LFSR is a reasonably good PRNG for a single bit, but > > not when you want to generate a group of 31 pseudo-random bits. In > > order to get 31 new bits, without predictable repetitions from the > > previous value, you would have to do 31 steps. That's slow! The > > process can be accelerate by generation of several bits at time via > > look up tables, but in order to get decent speed the table has to > > be rater big and using big tables in standard library is bad > > sportsmanship. > > Yes. But mind that the speed is also depending on what quality you > need. For example; I used the PN-generator to create bit-sequences > (as you also suggest). For another application both, PN-LFSR and > LCG (that you mention below), were inacceptable; we used a cipher > to create the random data. (If you compare the speed of creating > the cipher to a bit-shift-register the latter looks really fast.) > > > > > It seems that overwhelming majority C RTLs use Linear Congruential > > Generators, probably because for Stanadard library compactness of > > both code and data is considered more important than very high > > speed (not that on modern HW LCGs are slow) or superior random > > properties of Mersenne Twisters. > > For "standard applications" I always used the simple LCGs; simple > and fast. Or whatever the tools or library provided; which were > mostly anyway LCGs. > > Janis > > > [...] > When I need PRNG then I am typically not deeply concerned about size of its internal state. On the other hand, I don't want to care about potentially insufficient randomness of the output (not in crypto sense). On the 3rd hand, vectors that I generate with PRNG tend to be big and I don't like to wait, so I do care somewhat about speed. Those 3 factors together plus availability long ago made MT19937-64 into my personal default PRNG of choice. MT19937-64 is available out of the box(*) in C++. But not in C, unfortunately. At higher theoretical level MT is a generalization of LFSR, but it is not obvious when one looks at implementation. --------- * - hidden behind unnecessary levels of abstraction that just make it harder to use, but that's another story.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-12-23 10:54 +0100 |
| Message-ID | <10idosf$25ihh$4@dont-email.me> |
| In reply to | #395903 |
On 2025-12-23 10:18, Michael S wrote:
>
> When I need PRNG then I am typically not deeply concerned about size of
> its internal state. On the other hand, I don't want to care about
> potentially insufficient randomness of the output (not in crypto
> sense). On the 3rd hand, vectors that I generate with PRNG tend to be
> big and I don't like to wait, so I do care somewhat about speed.
> Those 3 factors together plus availability long ago made MT19937-64
> into my personal default PRNG of choice.
I've never intensified my knowledge in direction of MT algorithms.
>
> MT19937-64 is available out of the box(*) in C++. But not in C,
> unfortunately.
This is really strange given that the name ("Mersenne Twister") is
that prominent.
Looking that up I find at least "C" code for MT19937 in Wikipedia
https://de.wikipedia.org/wiki/Mersenne-Twister
It's based on 32 bit logic it seems; interpreting your "MT19937-64"
I assume you're looking for a 64 bit based version?
>
> At higher theoretical level MT is a generalization of LFSR, but it is
> not obvious when one looks at implementation.
Well, at least there's the 'mod' operations all based on powers of 2
along with all the binary op's which suggests some (non-arithmetic)
bit-register type of algorithm, but the multiplication with 0x9908b0df
(5 * 513496723) - which I'd suppose be hard to realize as/with LFSR -
may suggest some other generator type.
Janis
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-12-23 13:50 +0200 |
| Message-ID | <20251223135031.000000b3@yahoo.com> |
| In reply to | #395904 |
On Tue, 23 Dec 2025 10:54:23 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 2025-12-23 10:18, Michael S wrote:
> >
> > When I need PRNG then I am typically not deeply concerned about
> > size of its internal state. On the other hand, I don't want to care
> > about potentially insufficient randomness of the output (not in
> > crypto sense). On the 3rd hand, vectors that I generate with PRNG
> > tend to be big and I don't like to wait, so I do care somewhat
> > about speed. Those 3 factors together plus availability long ago
> > made MT19937-64 into my personal default PRNG of choice.
>
> I've never intensified my knowledge in direction of MT algorithms.
>
> >
> > MT19937-64 is available out of the box(*) in C++. But not in C,
> > unfortunately.
>
> This is really strange given that the name ("Mersenne Twister") is
> that prominent.
>
> Looking that up I find at least "C" code for MT19937 in Wikipedia
> https://de.wikipedia.org/wiki/Mersenne-Twister
> It's based on 32 bit logic it seems; interpreting your "MT19937-64"
> I assume you're looking for a 64 bit based version?
>
"Available out of the box" in this sentence means "part of standard
library".
Of course, MT19937-64 is available as 'C' source. But that's one more
source+header to copy from project to project. Unlike in C++ where it's
always here.
> >
> > At higher theoretical level MT is a generalization of LFSR, but it
> > is not obvious when one looks at implementation.
>
> Well, at least there's the 'mod' operations all based on powers of 2
> along with all the binary op's which suggests some (non-arithmetic)
> bit-register type of algorithm, but the multiplication with 0x9908b0df
> (5 * 513496723) - which I'd suppose be hard to realize as/with LFSR -
> may suggest some other generator type.
>
> Janis
>
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-12-23 18:29 -0500 |
| Message-ID | <10if8lm$2sora$3@dont-email.me> |
| In reply to | #395908 |
On 2025-12-23 06:50, Michael S wrote:
> On Tue, 23 Dec 2025 10:54:23 +0100
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>
>> On 2025-12-23 10:18, Michael S wrote:
...
>>> MT19937-64 is available out of the box(*) in C++. But not in C,
>>> unfortunately.
>>
>> This is really strange given that the name ("Mersenne Twister") is
>> that prominent.
>>
>> Looking that up I find at least "C" code for MT19937 in Wikipedia
>> https://de.wikipedia.org/wiki/Mersenne-Twister
>> It's based on 32 bit logic it seems; interpreting your "MT19937-64"
>> I assume you're looking for a 64 bit based version?
>>
>
> "Available out of the box" in this sentence means "part of standard
> library".
Citation, please? I can find neither Mersenne nor "MT19937-64" anywhere
in n5001.pdf, the latest draft version of the C++ standard that I have
access to, which is dated 2024-12-17.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-23 16:30 -0800 |
| Message-ID | <87h5tg90x3.fsf@example.invalid> |
| In reply to | #395921 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 2025-12-23 06:50, Michael S wrote:
>> On Tue, 23 Dec 2025 10:54:23 +0100
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>
>>> On 2025-12-23 10:18, Michael S wrote:
> ...
>>>> MT19937-64 is available out of the box(*) in C++. But not in C,
>>>> unfortunately.
>>>
>>> This is really strange given that the name ("Mersenne Twister") is
>>> that prominent.
>>>
>>> Looking that up I find at least "C" code for MT19937 in Wikipedia
>>> https://de.wikipedia.org/wiki/Mersenne-Twister
>>> It's based on 32 bit logic it seems; interpreting your "MT19937-64"
>>> I assume you're looking for a 64 bit based version?
>>>
>>
>> "Available out of the box" in this sentence means "part of standard
>> library".
>
> Citation, please? I can find neither Mersenne nor "MT19937-64" anywhere
> in n5001.pdf, the latest draft version of the C++ standard that I have
> access to, which is dated 2024-12-17.
N5001 29.5.4.3 [rand.eng.mers] "Class template mersenne_twister_engine".
N5001 29.5.6 [rand.predef] "Engines and engine adaptors with predefined
parameters" defines "mt19937" and "mt19937_64".
Its description of the algorithm isn't very detailed, but it
does impose some very specific requirements. For mt19937:
"Required behavior: The 10000th consecutive invocation of a
default-constructed object of type mt19937 produces the value
4123659995.". For mt19937_64: "Required behavior: The 10000th
consecutive invocation of a default-constructed object of type
mt19937_64 produces the value 9981545732273789042."
If we're going to discuss this in any more detail (rather than
discussing random numbers in general), I suggest comp.lang.c++.
As already mentioned, there are implementations of mt19937 for C,
but unlike in C++ they aren't part of the standard library.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-12-23 17:54 +0000 |
| Message-ID | <10iekvr$pa8n$1@paganini.bofh.team> |
| In reply to | #395887 |
Michael S <already5chosen@yahoo.com> wrote:
> On Mon, 22 Dec 2025 18:41:10 +0100
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>
>> On 2025-12-22 18:13, James Kuyper wrote:
>> > On 2025-12-22 07:18, Janis Papanagnou wrote:
>> >> On 2025-12-22 12:44, James Kuyper wrote:
>> >>> On 2025-12-22 03:48, Michael Sanders wrote:
>> >>>> Is it incorrect to use 0 (zero) to seed srand()?
>> >>>>
>> >>>> int seed = (argc >= 2 && strlen(argv[1]) == 9)
>> >>>> ? atoi(argv[1])
>> >>>> : (int)(time(NULL) % 900000000 + 100000000);
>> >>>>
>> >>>> srand(seed);
>> >>>
>> >>> No, why whould you think so?
>> >>
>> >> There's number sequence generators that produce 0 sequences if
>> >> seeded with 0. ...
>> >
>> > The details of how the seed affects the random number sequence are
>> > unspecified by the standard. I personally would consider a
>> > pseudo-random number generator to be quite defective if there were
>> > any seed that produced a constant output.
>>
>> I wouldn't have mentioned that if there weren't a whole class of
>> such functions that expose exactly that behavior by design. Have
>> a look for PN-(Pseudo Noise-)generators and LFSR (Linear Feedback
>> Shift Registers). These have been defined to produce random noise
>> (bit pattern with good statistical distribution). With sophisticated
>> generator polynomials they produce also sequences of maximum period;
>> say, for N=31 a non-repeating sequence of length 2^N - 1. The one
>> element that is missing from the sequence is the 0 (that reproduces
>> itself).
>>
>> Technically you pick some bit-values from fixed positions (depending
>> on the generator polynomial) of the register and xor the bits to shift
>> the result into the register. Here's ad hoc an example...
>>
>> #include <stdio.h>
>> #include <stdint.h>
>>
>> int main ()
>> {
>> uint32_t init = 0x00000038;
>> uint32_t reg = init;
>> uint32_t new_bit;
>> int count = 0;
>> do {
>> new_bit = ((reg >> 2) + (reg >> 4) + (reg >> 6) + (reg >>
>> 30)) & 0x1;
>> reg <<= 1;
>> reg |= new_bit;
>> reg &= 0x7fffffff;
>> count++;
>> } while (reg != init);
>> printf ("period: %d\n", count);
>> }
>>
>>
>> Janis
>>
>> >> [...]
>>
>
> Pay attention that C Standard only requires for the same seed to always
> produces the same sequence. There is no requirement that different
> seeds have to produce different sequences.
> So, for generator in your example, implementation like below would be
> fully legal. Personally, I wouldn't even consider it as particularly
> poor quality:
>
> void srand(unsigned seed ) { init = seed | 1;}
>
> [O.T.]
> In practice, using LFSR for rand() is not particularly bright idea for
> different reason: LFSR is a reasonably good PRNG for a single bit, but
> not when you want to generate a group of 31 pseudo-random bits. In
> order to get 31 new bits, without predictable repetitions from the
> previous value, you would have to do 31 steps. That's slow! The process
> can be accelerate by generation of several bits at time via look up
> tables, but in order to get decent speed the table has to be rater big
> and using big tables in standard library is bad sportsmanship.
>
> It seems that overwhelming majority C RTLs use Linear Congruential
> Generators, probably because for Stanadard library compactness of both
> code and data is considered more important than very high speed (not
> that on modern HW LCGs are slow) or superior random properties of
> Mersenne Twisters.
There is a paper "PCG: A Family of Simple Fast Space-Efficient
Statistically Good Algorithms for Random Number Generation"
by M. O’Neill where she gives a family of algorithms and runs
several statistical tests against known algorithms. Mersenne
Twister does not look good in tests. If you have enough (128) bits
LCGs do pass tests. A bunch of generators with 64-bit state also
passes tests. So the only reason to prefer Mersenne Twister is
that it is implemented in available libraries. Otherwise it is
not so good, have large state and needs more execution time
than alternatives.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-12-24 00:08 +0200 |
| Message-ID | <20251224000824.00005ce7@yahoo.com> |
| In reply to | #395915 |
On Tue, 23 Dec 2025 17:54:05 -0000 (UTC)
antispam@fricas.org (Waldek Hebisch) wrote:
> Michael S <already5chosen@yahoo.com> wrote:
> > On Mon, 22 Dec 2025 18:41:10 +0100
> > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> >
> >> On 2025-12-22 18:13, James Kuyper wrote:
> >> > On 2025-12-22 07:18, Janis Papanagnou wrote:
> >> >> On 2025-12-22 12:44, James Kuyper wrote:
> >> >>> On 2025-12-22 03:48, Michael Sanders wrote:
> >> >>>> Is it incorrect to use 0 (zero) to seed srand()?
> >> >>>>
> >> >>>> int seed = (argc >= 2 && strlen(argv[1]) == 9)
> >> >>>> ? atoi(argv[1])
> >> >>>> : (int)(time(NULL) % 900000000 + 100000000);
> >> >>>>
> >> >>>> srand(seed);
> >> >>>
> >> >>> No, why whould you think so?
> >> >>
> >> >> There's number sequence generators that produce 0 sequences if
> >> >> seeded with 0. ...
> >> >
> >> > The details of how the seed affects the random number sequence
> >> > are unspecified by the standard. I personally would consider a
> >> > pseudo-random number generator to be quite defective if there
> >> > were any seed that produced a constant output.
> >>
> >> I wouldn't have mentioned that if there weren't a whole class of
> >> such functions that expose exactly that behavior by design. Have
> >> a look for PN-(Pseudo Noise-)generators and LFSR (Linear Feedback
> >> Shift Registers). These have been defined to produce random noise
> >> (bit pattern with good statistical distribution). With
> >> sophisticated generator polynomials they produce also sequences of
> >> maximum period; say, for N=31 a non-repeating sequence of length
> >> 2^N - 1. The one element that is missing from the sequence is the
> >> 0 (that reproduces itself).
> >>
> >> Technically you pick some bit-values from fixed positions
> >> (depending on the generator polynomial) of the register and xor
> >> the bits to shift the result into the register. Here's ad hoc an
> >> example...
> >>
> >> #include <stdio.h>
> >> #include <stdint.h>
> >>
> >> int main ()
> >> {
> >> uint32_t init = 0x00000038;
> >> uint32_t reg = init;
> >> uint32_t new_bit;
> >> int count = 0;
> >> do {
> >> new_bit = ((reg >> 2) + (reg >> 4) + (reg >> 6) + (reg >>
> >> 30)) & 0x1;
> >> reg <<= 1;
> >> reg |= new_bit;
> >> reg &= 0x7fffffff;
> >> count++;
> >> } while (reg != init);
> >> printf ("period: %d\n", count);
> >> }
> >>
> >>
> >> Janis
> >>
> >> >> [...]
> >>
> >
> > Pay attention that C Standard only requires for the same seed to
> > always produces the same sequence. There is no requirement that
> > different seeds have to produce different sequences.
> > So, for generator in your example, implementation like below would
> > be fully legal. Personally, I wouldn't even consider it as
> > particularly poor quality:
> >
> > void srand(unsigned seed ) { init = seed | 1;}
> >
> > [O.T.]
> > In practice, using LFSR for rand() is not particularly bright idea
> > for different reason: LFSR is a reasonably good PRNG for a single
> > bit, but not when you want to generate a group of 31 pseudo-random
> > bits. In order to get 31 new bits, without predictable repetitions
> > from the previous value, you would have to do 31 steps. That's
> > slow! The process can be accelerate by generation of several bits
> > at time via look up tables, but in order to get decent speed the
> > table has to be rater big and using big tables in standard library
> > is bad sportsmanship.
> >
> > It seems that overwhelming majority C RTLs use Linear Congruential
> > Generators, probably because for Stanadard library compactness of
> > both code and data is considered more important than very high
> > speed (not that on modern HW LCGs are slow) or superior random
> > properties of Mersenne Twisters.
>
> There is a paper "PCG: A Family of Simple Fast Space-Efficient
> Statistically Good Algorithms for Random Number Generation"
> by M. O’Neill where she gives a family of algorithms and runs
> several statistical tests against known algorithms. Mersenne
> Twister does not look good in tests. If you have enough (128) bits
> LCGs do pass tests. A bunch of generators with 64-bit state also
> passes tests. So the only reason to prefer Mersenne Twister is
> that it is implemented in available libraries. Otherwise it is
> not so good, have large state and needs more execution time
> than alternatives.
>
I don't know. Testing randomness is complicated matter.
How can I be sure that L’Ecuyer and Simard’s TestU01 suite tests things
that I personally care about and that it does not test things that are
of no interest for me? Especially, the latter.
Also, the TestU01 suit is made for generators with 32-bit output.
M. O’Neill used ad hoc technique to make it applicable to generators
with 64-bit output. Is this technique right? Or may be it put 64-bit
PRNG at unfair disadvantage?
Besides, I strongly disagree with at least one assertion made by
O’Neill: "While security-related applications should
use a secure generator, because we cannot always know the future
contexts in which our code will be used, it seems wise for all
applications to avoid generators that make discovering their entire
internal state completely trivial."
No, I know exactly what I am doing/ I know exactly that for my
application easy discovery of complete state of PRNG is not a defect.
Anyway, even if I am skeptical about her criticism of popular PRNGs,
intuitively I agree with the constructive part of the article -
medium-quality PRNG that feeds medium quality hash function can
potentially produce very good fast PRNG with rather small internal
state.
On related note, I think that even simple counter fed into high quality
hash function (not cryptographically high quality, far less than that)
can produce excellent PRNG with even smaller internal state. But not
very fast one. Although the speed depends on specifics of used
computer. I can imagine computer that has low-latency Rijndael128
instruction. On such computer, running counter through 3-4 rounds of
Rijndael ill produce very good PRNG that is only 2-3 times slower than,
for example, LCG 128/64.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-12-24 02:02 +0000 |
| Message-ID | <10ifhkj$n73o$2@dont-email.me> |
| In reply to | #395920 |
On Wed, 24 Dec 2025 00:08:24 +0200, Michael S wrote: > Testing randomness is complicated matter. Impossible, really, if you define “random” as “Nobody can know what comes next”.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-12-23 23:43 -0500 |
| Message-ID | <10ifr17$2sorc$1@dont-email.me> |
| In reply to | #395924 |
On 2025-12-23 21:02, Lawrence D’Oliveiro wrote: > On Wed, 24 Dec 2025 00:08:24 +0200, Michael S wrote: > >> Testing randomness is complicated matter. > > Impossible, really, if you define “random” as “Nobody can know what comes > next”. The quality of pseudo-random number generators can be measured, but you need to carefully define what you mean by "quality". The relevant measures can be different for different purposes. I've seen a randome number generator used in a context where the only relevant criteria was that the probability of each number occurring was equal. In that particular contest, a function that simply always returned the sequence 0, 1, 2, ... RAND_MAX, and then started over again at the beginning would have been good enough. Most applications have somewhat stronger requirements :-)
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-12-24 05:34 +0000 |
| Message-ID | <10ifu1g$q4e0$2@dont-email.me> |
| In reply to | #395926 |
On Tue, 23 Dec 2025 23:43:19 -0500, James Kuyper wrote: > On 2025-12-23 21:02, Lawrence D’Oliveiro wrote: >> >> On Wed, 24 Dec 2025 00:08:24 +0200, Michael S wrote: >> >>> Testing randomness is complicated matter. >> >> Impossible, really, if you define “random” as “Nobody can know what >> comes next”. > > The quality of pseudo-random number generators can be measured, but you > need to carefully define what you mean by "quality". That’s not exactly disagreeing with what I’m saying ...
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-12-24 09:00 +0000 |
| Message-ID | <10iga40$11ds6$1@paganini.bofh.team> |
| In reply to | #395920 |
Michael S <already5chosen@yahoo.com> wrote:
> On Tue, 23 Dec 2025 17:54:05 -0000 (UTC)
> antispam@fricas.org (Waldek Hebisch) wrote:
>
>> Michael S <already5chosen@yahoo.com> wrote:
>> > On Mon, 22 Dec 2025 18:41:10 +0100
>> > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> >
>> >> On 2025-12-22 18:13, James Kuyper wrote:
>> >> > On 2025-12-22 07:18, Janis Papanagnou wrote:
>> >> >> On 2025-12-22 12:44, James Kuyper wrote:
>> >> >>> On 2025-12-22 03:48, Michael Sanders wrote:
>> >> >>>> Is it incorrect to use 0 (zero) to seed srand()?
>> >> >>>>
>> >> >>>> int seed = (argc >= 2 && strlen(argv[1]) == 9)
>> >> >>>> ? atoi(argv[1])
>> >> >>>> : (int)(time(NULL) % 900000000 + 100000000);
>> >> >>>>
>> >> >>>> srand(seed);
>> >> >>>
>> >> >>> No, why whould you think so?
>> >> >>
>> >> >> There's number sequence generators that produce 0 sequences if
>> >> >> seeded with 0. ...
>> >> >
>> >> > The details of how the seed affects the random number sequence
>> >> > are unspecified by the standard. I personally would consider a
>> >> > pseudo-random number generator to be quite defective if there
>> >> > were any seed that produced a constant output.
>> >>
>> >> I wouldn't have mentioned that if there weren't a whole class of
>> >> such functions that expose exactly that behavior by design. Have
>> >> a look for PN-(Pseudo Noise-)generators and LFSR (Linear Feedback
>> >> Shift Registers). These have been defined to produce random noise
>> >> (bit pattern with good statistical distribution). With
>> >> sophisticated generator polynomials they produce also sequences of
>> >> maximum period; say, for N=31 a non-repeating sequence of length
>> >> 2^N - 1. The one element that is missing from the sequence is the
>> >> 0 (that reproduces itself).
>> >>
>> >> Technically you pick some bit-values from fixed positions
>> >> (depending on the generator polynomial) of the register and xor
>> >> the bits to shift the result into the register. Here's ad hoc an
>> >> example...
>> >>
>> >> #include <stdio.h>
>> >> #include <stdint.h>
>> >>
>> >> int main ()
>> >> {
>> >> uint32_t init = 0x00000038;
>> >> uint32_t reg = init;
>> >> uint32_t new_bit;
>> >> int count = 0;
>> >> do {
>> >> new_bit = ((reg >> 2) + (reg >> 4) + (reg >> 6) + (reg >>
>> >> 30)) & 0x1;
>> >> reg <<= 1;
>> >> reg |= new_bit;
>> >> reg &= 0x7fffffff;
>> >> count++;
>> >> } while (reg != init);
>> >> printf ("period: %d\n", count);
>> >> }
>> >>
>> >>
>> >> Janis
>> >>
>> >> >> [...]
>> >>
>> >
>> > Pay attention that C Standard only requires for the same seed to
>> > always produces the same sequence. There is no requirement that
>> > different seeds have to produce different sequences.
>> > So, for generator in your example, implementation like below would
>> > be fully legal. Personally, I wouldn't even consider it as
>> > particularly poor quality:
>> >
>> > void srand(unsigned seed ) { init = seed | 1;}
>> >
>> > [O.T.]
>> > In practice, using LFSR for rand() is not particularly bright idea
>> > for different reason: LFSR is a reasonably good PRNG for a single
>> > bit, but not when you want to generate a group of 31 pseudo-random
>> > bits. In order to get 31 new bits, without predictable repetitions
>> > from the previous value, you would have to do 31 steps. That's
>> > slow! The process can be accelerate by generation of several bits
>> > at time via look up tables, but in order to get decent speed the
>> > table has to be rater big and using big tables in standard library
>> > is bad sportsmanship.
>> >
>> > It seems that overwhelming majority C RTLs use Linear Congruential
>> > Generators, probably because for Stanadard library compactness of
>> > both code and data is considered more important than very high
>> > speed (not that on modern HW LCGs are slow) or superior random
>> > properties of Mersenne Twisters.
>>
>> There is a paper "PCG: A Family of Simple Fast Space-Efficient
>> Statistically Good Algorithms for Random Number Generation"
>> by M. O’Neill where she gives a family of algorithms and runs
>> several statistical tests against known algorithms. Mersenne
>> Twister does not look good in tests. If you have enough (128) bits
>> LCGs do pass tests. A bunch of generators with 64-bit state also
>> passes tests. So the only reason to prefer Mersenne Twister is
>> that it is implemented in available libraries. Otherwise it is
>> not so good, have large state and needs more execution time
>> than alternatives.
>>
>
> I don't know. Testing randomness is complicated matter.
> How can I be sure that L’Ecuyer and Simard’s TestU01 suite tests things
> that I personally care about and that it does not test things that are
> of no interest for me? Especially, the latter.
It is extremaly unlikely that TestU only tests things that are
important to you. However, IMO value of such test is that
generator which passes the test avoids several common traps.
If any of them is relevant for you, generator will avoid it.
Of course, you may have _very_ special situation with
extremaly uncommon problem, but this is unlikely and anyway
in such case you probably should extensively test generator
that you want to use.
> Also, the TestU01 suit is made for generators with 32-bit output.
> M. O’Neill used ad hoc technique to make it applicable to generators
> with 64-bit output. Is this technique right? Or may be it put 64-bit
> PRNG at unfair disadvantage?
My point of view is that generator can be used to generate long
bistream. Then you can cut the bitstream and get number of
desired size. Good tests should check that such usage leads
to reasonable properties. So, fact that one generator produces
32-bit pieces and other produces 64-bit pieces should be irrelevant
to the test.
> Besides, I strongly disagree with at least one assertion made by
> O’Neill: "While security-related applications should
> use a secure generator, because we cannot always know the future
> contexts in which our code will be used, it seems wise for all
> applications to avoid generators that make discovering their entire
> internal state completely trivial."
> No, I know exactly what I am doing/ I know exactly that for my
> application easy discovery of complete state of PRNG is not a defect.
O’Neill is not a prophet, ignore what she say it you think you
know better (which is probably the above).
> Anyway, even if I am skeptical about her criticism of popular PRNGs,
> intuitively I agree with the constructive part of the article -
> medium-quality PRNG that feeds medium quality hash function can
> potentially produce very good fast PRNG with rather small internal
> state.
She seem to care very much about having minimal possible state.
That is may be nice on embeded systems, but in general I would
happily accept slighty bigger state (say 256 bits). But if
we can get good properties with very small state, then why not?
After all looking at state and updating it takes code, so
small state helps with having fast generator.
Concerning Mersenne Twister, she is not the only one to
criticise it. My personal opinion is that given large
state and not so simple update Mersenne Twister would
have to be very very good to justify its use. But it
fails some tests, so does not look _better_ than other
generators.
> On related note, I think that even simple counter fed into high quality
> hash function (not cryptographically high quality, far less than that)
> can produce excellent PRNG with even smaller internal state. But not
> very fast one. Although the speed depends on specifics of used
> computer. I can imagine computer that has low-latency Rijndael128
> instruction. On such computer, running counter through 3-4 rounds of
> Rijndael ill produce very good PRNG that is only 2-3 times slower than,
> for example, LCG 128/64.
Maybe.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
Page 1 of 10 [1] 2 3 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web