more comments Peter McGoron (17 May 2026 04:39 UTC)
Re: more comments Wolfgang Corcoran-Mathe (17 May 2026 20:33 UTC)
Re: more comments Peter McGoron (17 May 2026 21:21 UTC)
Re: more comments Wolfgang Corcoran-Mathe (18 May 2026 00:54 UTC)
Re: more comments Shiro Kawai (18 May 2026 11:52 UTC)
Re: more comments John Cowan (18 May 2026 13:46 UTC)
Re: more comments Shiro Kawai (18 May 2026 17:21 UTC)
Re: more comments Wolfgang Corcoran-Mathe (18 May 2026 18:03 UTC)
Re: more comments Peter McGoron (18 May 2026 15:33 UTC)
Re: more comments Vincent Manis (he/him) (18 May 2026 16:41 UTC)
Special initialization behavior for the default determinized library (was: more comments) Peter McGoron (18 May 2026 21:38 UTC)
Re: more comments Shiro Kawai (18 May 2026 17:13 UTC)
Re: more comments Peter McGoron (18 May 2026 18:28 UTC)
Re: more comments Shiro Kawai (18 May 2026 18:42 UTC)
Re: more comments Peter McGoron (19 May 2026 02:12 UTC)
Re: more comments Shiro Kawai (19 May 2026 03:16 UTC)
Re: more comments Wolfgang Corcoran-Mathe (18 May 2026 16:59 UTC)
Re: more comments Shiro Kawai (18 May 2026 17:08 UTC)
Re: more comments John Cowan (18 May 2026 06:17 UTC)
Re: more comments Peter McGoron (18 May 2026 11:30 UTC)
Re: more comments John Cowan (18 May 2026 13:21 UTC)
Re: more comments Wolfgang Corcoran-Mathe (18 May 2026 17:19 UTC)

Special initialization behavior for the default determinized library (was: more comments) Peter McGoron 18 May 2026 21:37 UTC

On 5/18/26 12:41, Vincent Manis (he/him) wrote:
> I'm still coming at this from a teaching viewpoint. The #t suggestion is
> great, but if I were teaching with this, I'd want to show that different
> seeds produce different random sequences. So I'd like to extend this
> slightly so that any integer can be used (as well as #t), with the
> requirement that each integer leads to an initial state (presumably
> different, but that's not guaranteed). -- vincent

I like that, however, it might be too much of a requirement to give all
random ports.

I instead think that the *default* random port constructor from `(srfi
271 determinized)` should be initializable from an arbitrary exact
integer, which it converts into a state in some implementation-dependent
way. (For example, if the RNG does not allow for a state to be zero,
then passing `0` and passing `1` may give the same sequence.)

That would solve this issue, and also the issue with getting multiple
arbitrary-yet-consistent states from other random number generators
without having to store unwieldy large datum values.

-- Peter McGoron