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

On Dec 30, 2007 12:40 PM, Chongkai Zhu <czhu at cs.utah.edu> wrote:

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

My bad on that one.  Sorry.  But, I still don't like compressing the
repeatable random space - there are collisions there.


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

I'm not sure what the 'right' answer is, I'm just trying to figure out the
best way to keep users from being confused.  [Noel is by no means a novice
user and he was confused.]  The best options seem to be at opposite ends of
the spectrum.  Either make them the same (and therefore there is nothing to
confuse) or make them so different that you lessen the confusion.

I would rather lean toward making them the same:

1) Make both random sources have the same 'type' - i.e.
make-pseudo-random-generator from PLT Scheme and make-random-source from
SRFI 27 should return objects that can be used in either context because
they are the same implementation.
2) Make PLT Scheme random routines (like random and random-seed) be able to
accept a random-source as an argument.  It seems wasteful to continually
parameterize current-pseudo-random-stream to fake passing random (or
random-seed) an argument, which is one of the main kludges I was referring
to.
3) Implement a SRFI 27 pseudo randomize in PLT Scheme (because it is more
robust than a single seed) and then implement random-seed in terms of it.
For example, we might define (random-seed s k) as being equivalent to
(random-source-pseudo-randomize! s k 0).

I think that would give us an interface in PLT Scheme that is compatible
with (but an extension of) the current implementation and give what is
needed to make the SRFI 27 implementation better.

I don't think there is a good way top reconcile the differences between the
default-random-source behavior of SRFI 27 and the
current-pseudo-random-generator in PLT Scheme.  SRFI 27 did not anticipate
as rich as environment - i.e., with parameters, threads, etc - as PLT
Scheme.  Leave them both in as they are - and avoid the temptation to make
default-random-stream be a parameter, it's just a global variable.  In
essence this is what I did in the science collection by adding a
current-random-source parameter.  [It is doing the same for SRFI 27 as
current-pseudo-random-generator does for PLT Scheme.]

The other extreme is to just put the old SRFI 27 implementation back and
just say they're different.

My personal opinion is that the current PLT Scheme random source interface
(not the underlying implementation) is inadequate for the work I want to use
it for - simulations, in my case.  But, it is more efficient than the old
SRFI 27 implementation.  The SRFI 27 interface is suitable for the work - in
particular, I can easily specify repeatable, independent random variables.
However, it's implementation was not as efficient as the PLT Scheme
implementation.  And, because the PLT Scheme implementation doesn't expose
enough of the underlying implementation to make a straightforward
implementation of SRFI 27 on top of it, I don't have the same confidence in
the interface code as I do in either the underlying PLT implementation or
the old SRFI implementation.  [For example, the procedure returned by
(random-source-make-integers n) may call the underlying PLT Scheme random
routine once or twice, depending on the value of n.  Some of those
manipulations seem innocuous, but can bias the macro-level behavior of the
random sources.]

In the short term, the best thing for the users of the science collection to
remember is that there is no inherent connection between the SRFI 27 random
routines (and the science collection distributions, etc) and the built in
PLT scheme ones.


> Chongkai
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20071230/c56bd73c/attachment.html>