Hi Theam,
On Sat, Jul 16, 2011 at 3:58 AM, Theam Yong Chew senatorzergling@gmail.comwrote:
On 16-Jul-2011 5:00 AM, "Erik Huelsmann" ehuels@gmail.com wrote:
Today I was looking at fixing some of our PRINT.* failures in the ansi
test suite.
Hoping to get an easy start, I started looking PRINT.RANDOM-STATE.1
...
there's no way to extract a 'seed' value from the object to be used to initialize an object into the same state.
So, I'm now pondering what action to take. I'm seeing several options:
- build our own pseudo random number generator with its own random state
- serialize the Random object to a byte array and use that array as
some sort of printed representation (sure, we'll definitely need to look into ways to load)
The advantage of (1) is that we can create it all in Lisp, however, it's pure additional code, since we won't be leveraging what's already there.
You are talking about leveraging Java, but what about leveraging Lisp?
Sure. When we have to code things ourselves, I prefer Lisp too. However, in case the Java libraries provide required functionality and we can implement simple wrappers, we can benefit from the maintenance effort that's being put into Java without spending any effort ourselves: fixes to java will automatically propagate to our lisp.
I'm not sure about speed, but this is often cited on the web/newsgroups,
http://www.ccs.neu.edu/home/dorai/notes/mrg32k3a.lisp
and there're the ones from SBCL too.
The advantage of (2) is that we can use what Java maintains for us and even better: we can use the random number generator shared between Lisp and Java code. I imagine the disadvantage of this solution is that the serialization of the random state can differ between Java versions and implementations.
I would tend to favour Lisp solutions, but yeah...
It looks - also given Mark's reaction - like we may need to implement this in Lisp to achieve the behaviour we need: readable random states. Possibly, we can also offer a (non-printable) wrapper around the java Random object...
Thanks for your feedback! I'll save the link to see if that solution or the algorithms in SBCL can help us out here.
Bye,
Erik.