[armedbear-devel] Fixing PRINT.RANDOM-STATE.1
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 The problem shown by the test is that our RANDOM-STATEs are not printable. From the perspective of ABCL, that's logical: Java's Random objects are serializable, but as everywhere in Java, it's serialization is internal to the implementation. The Random object is initialized using a 'seed' long value, but 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: 1. build our own pseudo random number generator with its own random state 2. 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. 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. Any ideas?? Bye, Erik.
I think all you need to serialize is a structure that contains the long seed for java.until.Random. Or am I missing something? Sent from my iPad On Jul 15, 2011, at 6:59 PM, 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 The problem shown by the test is that our RANDOM-STATEs are not printable. From the perspective of ABCL, that's logical: Java's Random objects are serializable, but as everywhere in Java, it's serialization is internal to the implementation. The Random object is initialized using a 'seed' long value, but 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:
1. build our own pseudo random number generator with its own random state 2. 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.
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.
Any ideas??
Bye,
Erik. _______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Hi Mark, On Fri, Jul 15, 2011 at 9:41 PM, Mark Evenson <evenson@panix.com> wrote:
I think all you need to serialize is a structure that contains the long seed for java.until.Random. Or am I missing something?
Well, the problem I'm having with that approach is that I don't seem to have any means to extract the seed from the Random object: it has a method setSeed(), but not a getSeed(). Do you have any idea how? Bye, Erik.
Sent from my iPad
On Jul 15, 2011, at 6:59 PM, 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 The
problem shown by the test is that our RANDOM-STATEs are not printable. From the perspective of ABCL, that's logical: Java's Random objects are serializable, but as everywhere in Java, it's serialization is internal to the implementation. The Random object is initialized using a 'seed' long value, but 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:
1. build our own pseudo random number generator with its own random state 2. 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.
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.
Any ideas??
Bye,
Erik. _______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Doh! Yes, Java is missing a getSeed() here. Then I would verify that the java.ip.Serialazable contract does what one would expect, and use that. For a possible optimization, one might use some variant of SecureRandom here, which presumably has greater entropy. Tersely written from my iPhone On 15.07.2011, at 21:45, Erik Huelsmann <ehuels@gmail.com> wrote:
Hi Mark,
On Fri, Jul 15, 2011 at 9:41 PM, Mark Evenson <evenson@panix.com> wrote: I think all you need to serialize is a structure that contains the long seed for java.until.Random. Or am I missing something?
Well, the problem I'm having with that approach is that I don't seem to have any means to extract the seed from the Random object: it has a method setSeed(), but not a getSeed(). Do you have any idea how?
Bye,
Erik.
Sent from my iPad
On Jul 15, 2011, at 6:59 PM, 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 The problem shown by the test is that our RANDOM-STATEs are not printable. From the perspective of ABCL, that's logical: Java's Random objects are serializable, but as everywhere in Java, it's serialization is internal to the implementation. The Random object is initialized using a 'seed' long value, but 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:
1. build our own pseudo random number generator with its own random state 2. 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.
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.
Any ideas??
Bye,
Erik. _______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
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:
1. build our own pseudo random number generator with its own random state 2. 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? 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... Yong.
Hi Theam, On Sat, Jul 16, 2011 at 3:58 AM, Theam Yong Chew <senatorzergling@gmail.com>wrote:
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:
1. build our own pseudo random number generator with its own random state 2. 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.
Hi, On Sat, Jul 16, 2011 at 11:09, Erik Huelsmann <ehuels@gmail.com> wrote:
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.
The algorithm implemented in SBCL is the Mersenne Twister (http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html) and it is a fast and very good random number generator. The implementation in SBCL is a good one and provides readable random states. I believe having a similar implementation in ABCL would be very nice since the generator that comes with Java is a low-quality one (it's a Linear Congruential Generator). SBCL also provides a specific feature to set a seed with a number: sb-ext:seed-random-state. It's a useful addition. As a side note, not long ago I've used the MT in SBCL as a starting point for a small portable library of random number generators. Unfortunately I still was not able to put it in a decent state for release... Best, Jorge -- http://jorgetavares.com
participants (4)
-
Erik Huelsmann -
Jorge Tavares -
Mark Evenson -
Theam Yong Chew