Re: In ersatz, seed is not returning a "small" number
On Wed, Apr 29, 2015 at 7:38 AM, Alexander Burger wrote: > > The problem is that you focus too much on pil32. I regard pil32 as > obsolete! The "standard" system for reference is pil64. Ouch. I thought about asking you this question concerning pil32, but maybe I didn't want to hear the answer I already guessed. > And for small systems, miniPicoLisp makes a lot of sense. > > There are, and will always be, a lot of differences between those > systems. OK (surrendering). Thanks for your patience, and sorry for the fuss. I'll try to implement something like MINSTD, where a*(m-1)<2^53. >> And pilMCU ? Ha ha, I'm just curious ! > > That's identical to pil64 in this regard :) Maybe I should look into emu64 now. On Wed, Apr 29, 2015 at 8:43 AM, George Orais wrote: > Hi Chris and Alex, > > Just for curiosity, here is the result from pilMCU and Picolisp: > > […] > > And Alex is right, it is all identical to pil64 ;) Thanks for taking the time to report this. chri -- http://profgra.org/lycee/ (site pro) http://delicious.com/profgraorg (liens, favoris) https://twitter.com/profgraorg http://microalg.info -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: In ersatz, seed is not returning a "small" number
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 pointer... Finding separator... Loading data's to heap... Init DBFiles... Starting pil... : (rand 0 1000) -> 0 : (rand 0 1000) -> 648 : (rand 0 1000) -> 723 : ** VVP Stop(0) ** ** Flushing output streams. ** Current simulation time is 592598 ticks. > finish ** Continue ** geo@geo-VirtualBox:~/pilMCU$ vvp -M. -mtty mcu Loading ssd@... 125952 bytes Loading ssdA... 4096 bytes Clearing registers... Set stack pointer... Finding separator... Loading data's to heap... Init DBFiles... Starting pil... : (rand 1 1000) -> 1 : (rand 1 1000) -> 934 : (rand 1 1000) -> 248 : ** VVP Stop(0) ** ** Flushing output streams. ** Current simulation time is 592526 ticks. > finish ** Continue ** geo@geo-VirtualBox:~/pilMCU$ Picolisp (3.1.7.17): geo@geo-VirtualBox:~/pilMCU$ pil + : (rand 0 1000) -> 0 : (rand 0 1000) -> 648 : (rand 0 1000) -> 723 : (bye) geo@geo-VirtualBox:~/pilMCU$ pil + : (rand 1 1000) -> 1 : (rand 1 1000) -> 934 : (rand 1 1000) -> 248 : (bye) geo@geo-VirtualBox:~/pilMCU$ And Alex is right, it is all identical to pil64 ;) BR, geo On Wednesday, April 29, 2015 1:43 PM, Alexander Burger wrote: 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 as simple (fast) as possible, > > Let's sum up what we have now concerning pil32 and ersatz: The problem is that you focus too much on pil32. I regard pil32 as obsolete! The "standard" system for reference is pil64. And for small systems, miniPicoLisp makes a lot of sense. There are, and will always be, a lot of differences between those systems. > And pilMCU ? Ha ha, I'm just curious ! That's identical to pil64 in this regard :) ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: In ersatz, seed is not returning a "small" number
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 as simple (fast) as possible, > > Let's sum up what we have now concerning pil32 and ersatz: The problem is that you focus too much on pil32. I regard pil32 as obsolete! The "standard" system for reference is pil64. And for small systems, miniPicoLisp makes a lot of sense. There are, and will always be, a lot of differences between those systems. > And pilMCU ? Ha ha, I'm just curious ! That's identical to pil64 in this regard :) ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: In ersatz, seed is not returning a "small" number
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 generator > should be as simple (fast) as possible, Let's sum up what we have now concerning pil32 and ersatz: (rand T) was already OK. (rand x y) is now ok since the suppression of the (int) cast and the use of 32 instead of 33. (rand) is not OK, but I don't use it for the project which needs reproducibility. (seed) is not OK, and I'd like the results to match. I'd like my users to be able to initialize the generator the same way across implementations. Now what could support my request is the fact that seed doesn't need to be so efficient since it should not be called more than once. What do you think ? > and all four implementations represent numbers differently: > > 1. pil32 […] > Each bignum cell can hold 32 bits, where the sign > bit is in bit 0 (no two's complement!). Therefore, the value is > multiplied by 2, and the sign bit is added. So this explains the ( n%2==0 ? n/2 : -(n-1)/2 ) trick. Great. I wonder if this formula really works in all cases. I tested a lot of cases, but not proved it. Maybe I should take a pencil and some paper for better chances to convince you. Or maybe you have a clear vision on this ? > 2. pil64 […] > > 3. miniPicoLisp has only short numbers (in two's complement, either 30 >bit on 32-bit machines, or 62 bits on 64-bit machines including the >sign). Mmmh. I was not aware of this 30 bit thing. This will be quite embarrassing when I'll embed in small chips, but not crucial. > 4. Ersatz […] And pilMCU ? Ha ha, I'm just curious ! > So there is no "natural" way to get completely equal results. Indeed, but for my purpose, I only need: * pil32 (mainly for my dev machine, but not restricted to) * java (desktop, but not restricted to of course) * js (I have a better control on this one!) So let's forget about (rand). I'm just asking for the n%2==0 ? n/2 : -(n-1)/2 trick for seed in the stock version of Ersatz. And I won't insist and bother you if you refuse since: 1) you're the boss, 2) I could ship a modified version of Ersatz with MicroAlg (but I'd prefer the stock one), or implement a generator in PicoLisp (even if it would be slow). chri -- http://profgra.org/lycee/ (site pro) http://delicious.com/profgraorg (liens, favoris) https://twitter.com/profgraorg http://microalg.info -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: In ersatz, seed is not returning a "small" number
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 the random generators give the same results? I had never intended that. The reason is that the random generator should be as simple (fast) as possible, and all four implementations represent numbers differently: 1. pil32 has only bignums, where the random generator restricts itself to a single cell. Each bignum cell can hold 32 bits, where the sign bit is in bit 0 (no two's complement!). Therefore, the value is multiplied by 2, and the sign bit is added. 2. pil64 has bignums with 64 bits in each cell, and short numbers with 60 bits plus a sign bit in bit 3 (bits 0 - 2 are tag bits). Random numbers are placed into short numbers. 3. miniPicoLisp has only short numbers (in two's complement, either 30 bit on 32-bit machines, or 62 bits on 64-bit machines including the sign). 4. Ersatz uses BigIntegers for bignums, and 'int's for short numbers. Thus, a random number is a two's complement 32-bit integer. So there is no "natural" way to get completely equal results. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: In ersatz, seed is not returning a "small" number
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 new Number((int)((Seed = initSeed(ex.Cdr.Car.eval()) * > 6364136223846793005L) >>> 32)); > > which is also more analog to pil32. What do you think? 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); This is the same trick than the one I used to mimic (rand). See below what I wrote on april the 26th in the other thread: ««« 2)b) I got stuck when trying to mimic the (rand) of pil32. In doRand, at this line in big.c: https://code.google.com/p/picolisp/source/browse/src/big.c#1213 return box(hi(Seed)); In Ersatz in rand (x n) at this line: https://code.google.com/p/picolisp/source/browse/ersatz/fun.src#3325 return new Number((int)Seed); This seemed so similar that I banged my head on the screen showing the discrepancies between the results of pil32 and Ersatz that I couldn't make disappear. Then, I noticed a pattern, that leaded to reversing the sign bit trick you just explained in initSeed: n>=0? n*2 : -n*2+1; One the one hand, Ersatz takes the lower 32 bits of the seed, then returns them as a signed integer. But on the other hand, pil32 takes the higher 32 bits as n (unsigned integer) and returns n%2==0 ? n/2 : -(n-1)/2. Correct ? A question: why did you choose different implementations ? Is it for a better efficiency in Ersatz ? »»» > Again, thanks for the input! Again, this is really nice to have someone who really takes the time to listen. Thank you Alex. chri -- http://profgra.org/lycee/ (site pro) http://delicious.com/profgraorg (liens, favoris) https://twitter.com/profgraorg http://microalg.info -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: In ersatz, seed is not returning a "small" number
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 correct. It stores the reduced 32-bit value in 'Seed'. I think 'Seed' must keep the full 64-bit value. I changed it to return new Number((int)((Seed = initSeed(ex.Cdr.Car.eval()) * 6364136223846793005L) >>> 32)); which is also more analog to pil32. What do you think? It is also in the new release. Can you test a little more? Again, thanks for the input! ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
