[plt-scheme] A curious evaluation order (?) bug

From: Chongkai Zhu (czhu at cs.utah.edu)
Date: Sun Dec 30 14:40:10 EST 2007


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
>
>


Posted on the users mailing list.