|
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: Special initialization behavior for the default determinized library (was: more comments)
Wolfgang Corcoran-Mathe
(18 May 2026 23:13 UTC)
|
|
Re: Special initialization behavior for the default determinized library (was: more comments)
John Cowan
(19 May 2026 01:00 UTC)
|
|
Re: Special initialization behavior for the default determinized library (was: more comments)
Wolfgang Corcoran-Mathe
(19 May 2026 17:46 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)
|
> After some thought, the only advantage I can see is that the bytevector interchange format for states allows us to seed random ports from other random ports. I don't think that the bytevector format is required for seeding random ports from other random ports. A random port is an (effectively) infinite source of bytes. A random source constructor takes some number of bytes from that random port and converts it into its own internal representation. The required structure of bytes is abstracted from the user, and so is the number of bytes (a random port constructor could even take a variable number of bytes: it doesn't matter, the source is infinite). Hence there is no requirement that ports be able to exchange byte*vectors* with eachother, just infinite bytes. The other things that can be passed to a random port constructor are implementation defined, except whatever datum comes out of the random-port-seed procedure. > draws an amount of data (the exact number of bytes is given by the length of the bytevector returned by 'random-port-state') from *initializer* With random port initializers the information about the length is unnecessary, because a finite amount can always be taken from an infinite source. Hence there is no need to specify this seeding with bytevectors, they can be lumped in with the other implementation-defined initialization objects. __________________________________ I will give a concrete example. The xoshiro256++ generator uses a 64*4 bit seed. Notably, the seed must not be everywhere zero, so an arbitrary bytevector of that length will not work. This information can be abstracted away from the user though: given a random binary input port, it can pull bytes until it gets a combination that is not everywhere zero (which is technically possible, even if extremely unlikely). There is no need for a bytevector interface in this scenario. The port could be implemented with u64vectors as the state representation, which the port would trust on initialization as the fast-path (no u64vector it will ever return from `random-port-state` will be all zeros, because it rejects those in random generation). -- Peter McGoron