Proposed solution to the "predetermined states" problem Wolfgang Corcoran-Mathe (22 May 2026 23:18 UTC)
Re: Proposed solution to the "predetermined states" problem Wolfgang Corcoran-Mathe (22 May 2026 23:26 UTC)
Re: Proposed solution to the "predetermined states" problem Peter McGoron (23 May 2026 00:02 UTC)
Re: Proposed solution to the "predetermined states" problem Peter McGoron (23 May 2026 01:18 UTC)
Re: Proposed solution to the "predetermined states" problem Peter McGoron (23 May 2026 13:44 UTC)
Re: Proposed solution to the "predetermined states" problem Wolfgang Corcoran-Mathe (23 May 2026 15:15 UTC)
Re: Proposed solution to the "predetermined states" problem Wolfgang Corcoran-Mathe (23 May 2026 16:28 UTC)
Re: Proposed solution to the "predetermined states" problem Peter McGoron (23 May 2026 17:00 UTC)
Re: Proposed solution to the "predetermined states" problem Peter McGoron (23 May 2026 17:02 UTC)
Re: Proposed solution to the "predetermined states" problem Wolfgang Corcoran-Mathe (24 May 2026 17:15 UTC)

Re: Proposed solution to the "predetermined states" problem Peter McGoron 23 May 2026 00:01 UTC

On 5/22/26 19:18, Wolfgang Corcoran-Mathe wrote:
> As I noted, these "infinite constant ports" are unusual; I don't think
> there's a way to construct one in standard Scheme.[2]  But they are,
> in a sense, degenerate random ports, and so a system that provides
> SRFI 271 could certainly provide an "all Ns" port.  The constructor
> for such a port would be quite simple:
>
> (make-constant-port byte) → binary-input-port
>
> You could hardcode some of these ports into your testing harness:
>
>      (define seeding-port (make-constant-port 4))
>
> What do you think of this approach?  I doubt constant ports belong
> in SRFI 271, but they are conceptually simple and could be easily
> specified in a small related SRFI.

The simplest solution would be, given a known good seed for a random
port, to just generate more values out of it:

     (let* ((port (make-random-port sample-seed))
            (port1 (make-random-port port))
            (port2 (make-random-port port))
            (port3 (make-random-port port)))
       (values port1 port2 port3))

This can cause some predictable behavior[1], but seeds made out of
repetitive bit patterns might also have the same issue. However,
randomized testing is probably not sensitive to those issues.

[1]: https://dl.acm.org/doi/10.1145/1276927.1276928

-- Peter McGoron