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 poi
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
> >
On Tue, Apr 28, 2015 at 7:58 PM, Alexander Burger 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 the random generat
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 impo
On Tue, Apr 28, 2015 at 8:38 AM, Alexander Burger 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 to
>
>return
On Tue, Apr 28, 2015 at 8:35 AM, Alexander Burger wrote:
> Hi Christophe,
> […]
>n = (Seed >>> 32) % n;
>
> should it be OK?
Yes. It works. Great.
> Thanks for the input!
Thank you for considering it !
The 2)b) of my big email (april, 26th) of this thread was not answered but
I'll copy pas
