[plt-scheme] A curious evaluation order (?) bug
Doug Williams wrote:
> And while we're on the subject, there is another problem with the new
> SRFI 27 implementation I've noticed. The randomization of
> (random-source-pseudo-randomize! s i j) and
> (random-source-pseudo-randomize! s j i) will always be the same. The
> code uses equal-hash-code of i and j to come up with a seed and that
> function is symmetric wrt i and j.
>
DrScheme, version 372-svn12nov2007 [3m]
(equal-hash-code (list 1 2))
(equal-hash-code (list 2 1))
(equal-hash-code (list 1 0))
(equal-hash-code (list 0 1))
=>
94564159
95385186
94562141
93284415
> I think we still need to do some thinking on the implementation. I
> think we need to either expose the SRFI 27 interface from PLT Scheme
> (and implement the old interface on top of that) or separate them
> completely and go back to the old SRFI 27 implementation. [There
> would also be some middle ground. But, I don't think there is
> currently enough of the internal implementation exposed to adequately
> implement SRFI 27 - there are too many kludges in that code now.]
>
The current SRFI 27 implement does the following:
1. to meet SRFI 27;
2. to be as efficient as possible (i.e., using PLT's random procedures
as much as possible).
I did once tried to connect SRFI 27's default-random-source and PLT's
current-pseudo-random-generator, but that doesn't goes very well, so it
comes the current implement: they are not connected at all. In that
sense, SRFI 27 and PLT's random procedures are completely separated. I
can't see what you are suggestion here.
Chongkai
> Doug
>
> On Dec 30, 2007 10:12 AM, Doug Williams <m.douglas.williams at gmail.com
> <mailto:m.douglas.williams at gmail.com>> wrote:
>
> I sent an answer to Noel directly, but will post an answer for
> everyone here, too. I believe Noel expected the code sequence
> '(random-seed 1234) (random-discrete discrete)' to always return
> the same value - because the random source state should be the
> same. Unfortunately, it isn't because the science collection uses
> a different default random source than the PLT Scheme one.
>
> The science collection random source and distribution routines are
> built on top of SRFI 27. At the time the science collection was
> implemented, the PLT Scheme random source routines were very naive
> and, therefore, the SRFI 27 implementation was used. Because of
> restrictions within SRFI 27 (including "Note that an assignment to
> default-random-source does not change random or random-real; it is
> also strongly recommended not to assign a new value."), a
> parameter, current-random-source, was created (in the science
> collection) to mirror the current-pseudo-random-generator in PLT
> Scheme.
>
> So, back to the '(random-seed 1234) (random-discrete discrete)'
> sequence. The (random-seed 1234) call sets the seed in the PLT
> Scheme default random stream (i.e.,
> current-pseudo-random-generator). The (random-discrete discrete)
> call is using the current-random-source parameter (from the
> science collection). So, they are using completely different
> random sources.
>
> Another problem is the difference in philosophy between the PLT
> Scheme random source interface and that of SRFI 27. For 'seeding'
> a random source, the PLT Scheme philosophy has a single random
> seed (set by random-seed) [and maps directly to the original
> internal naive implenentation] and SRFI uses a 2-dimensional
> random-source-randomize! described as "Changes the state of the
> random source s into the initial state of the (i, j)-th
> independent random source, where i and j are non-negative
> integers. This procedure provides a mechanism to obtain a large
> number of independent random sources (usually all derived from the
> same backbone generator), indexed by two integers. In contrast to
> random-source-randomize!, this procedure is entirely deterministic."
>
> In the 371 -> 372 transition (I believe at 371.1), the PLT Scheme
> random source routine was changed to use the same algorithm as
> SRFI 27 and SRFI 27 itself was reimplemented in terms of the new
> PLT Scheme implementation. There was some breakage to the science
> collection during that transition, but I think it's all been
> fixed. [You can look at the change log on PLaneT for details.]
> However, the random sources are different struct types internally
> and cannot be used interchangeably. So, we still have the same
> general problem of two different random source implementations -
> the science collection happens to use and extend the SRFI 27 one.
>
> I'm not sure of the best way to eliminate that confusion in the
> long term (other than through documentation), but am open to
> suggestions.
>
> Doug
>
>