Hi Chris and Alex,
Just for curiosity, here is the result from pilMCU and Picolisp:
pilMCU (under vvp emulator with removed ssd-to-RAM init to boot faster)
geo@geo-VirtualBox:~/pilMCU$ vvp -M. -mtty mcu
Loading ssd@... 125952 bytes
Loading ssdA... 4096 bytes
Clearing registers...
Set stack
On Tue, Apr 28, 2015 at 7:58 PM, Alexander Burger a...@software-lab.de wrote:
Hi Christophe,
Hi Alex.
Is it really so important that the random generators give the same
results?
Not so much important indeed, not crucial, but very interesting!
I had never intended that. The reason is that
On Tue, Apr 28, 2015 at 09:59:00PM +0200, Christophe Gragnic wrote:
Is it really so important that the random generators give the same
results?
Not so much important indeed, not crucial, but very interesting!
I had never intended that. The reason is that the random generator
should be
On Tue, Apr 28, 2015 at 8:38 AM, Alexander Burger a...@software-lab.de wrote:
Good, but this is not completely correct. It stores the reduced 32-bit
value in 'Seed'. I think 'Seed' must keep the full 64-bit value.
Indeed. I'm not used to read lines with interleaved affectations.
I changed it
Hi Christophe,
That the results are analog, but different. To obtain exactly the same
results that pil32,
I had to write:
seed ()
long n = (Seed = initSeed(ex.Cdr.Car.eval()) * 6364136223846793005L)
32;
return new Number(n%2==0 ? n/2 : -(n-1)/2);
Is it really so important that
Hi Christophe,
In seed, line 3310 of fun.src, I'd suggest a 32 bits shift then a cast
to an int for the result to conform to the docs:
http://www.software-lab.de/doc/refS.html#seed
n = (int)((initSeed(ex.Cdr.Car.eval()) * 6364136223846793005L) 32);
Good, but this is not completely
