The random problem is still there in 7.7.133 from CVS:
| > random(100000000000000); | (2) Result: 2680839155 | > random(100000000000000); | (3) Result: 3417185356 | > random(100000000000000); | (4) Result: 1128133174 | > random(100000000000000); | (5) Result: 385923916
Mirar @ Pike developers forum wrote:
The random problem is still there in 7.7.133 from CVS:
| > random(100000000000000); | (2) Result: 2680839155 | > random(100000000000000); | (3) Result: 3417185356 | > random(100000000000000); | (4) Result: 1128133174 | > random(100000000000000); | (5) Result: 385923916
Technically this doesn't prove that this random problem is in fact not a random problem, but a deterministic one ;-). But I concur that it doesn't look good.
Have people been counting on the random generator of Pike to be generating reproducible sequences? If not, then we might overhaul the generator to simply use as much bits per call as is needed to generate up to the maximum requested.
Technically this doesn't prove that this random problem is in fact not a random problem, but a deterministic one ;-). But I concur that it doesn't look good.
Yes. It makes it a bit hard writing a test case... :)
Have people been counting on the random generator of Pike to be generating reproducible sequences?
Yes, but not that one, I think. There are other methods under Crypto that are used when it's supposed to be real or semi-real random.
If not, then we might overhaul the generator to simply use as much bits per call as is needed to generate up to the maximum requested.
Or just kick in the bignum generator for >INT32 for now, but I'm not sure what the problem is.
there most be something on your machine, i don't get these with the latest pikefarm. what is your OS/distribution/cpu type/kernel version, don't know what else is interesting.
btw: that gives me the idea that it would be nice if there was a command for pike that would spit out all sorts of debug info. (compile options and detaild about the machine as far as they can be determined (detecting a linux distribution is hard))
greetings, martin.
Intel core2duo running Ubuntu Hardy. No specific config options, so 64-bit int and float:
| system information: | system.... Linux 2.6.24.3 | uname..... Linux iris 2.6.24.3 #1 SMP Mon Mar 10 15:51:14 CET 2008 x86_64 GNU/Linux ... | build information: | source path..... /home/mirar/pike/src | build path...... /home/mirar/pike/build/linux-2.6.24.3-x86_64 | ABI............. 64 | cpp............. gcc -E | cc.............. /home/mirar/pike/bin/smartlink gcc | ld.............. $(CC) $(CFLAGS) | cc shared....... -fPIC -DDYNAMIC_MODULE | ld shared....... -rdynamic | pike............ | install......... /usr/bin/install -c | shared object... .so | libs............ -ldl -lrt -lnsl -lm -lpthread -lcrypt | cross-compiled.. no | building lib.... no | CPPFLAGS........ -I/home/mirar/pike/build/linux-2.6.24.3-x86_64/bundles/include -I/usr/local/include | CFLAGS (opt).... -O3 -pipe | CFLAGS (warn)... -W -Wall -Wno-unused -Wcomment -Wformat -Wimplicit-function-declaration -Wmultichar -Wswitch -Wuninitialized -Wpointer-arith -Wchar-subscripts -Wno-long-long -Wdeclaration-after-statement | CFLAGS (misc)... -g -ggdb3 -m64 | LDFLAGS......... -L/home/mirar/pike/build/linux-2.6.24.3-x86_64/bundles/lib64 -L/home/mirar/pike/build/linux-2.6.24.3-x86_64/bundles/lib/64 -L/home/mirar/pike/build/linux-2.6.24.3-x86_64/bundles/lib/. -L/usr/lib/gcc/x86_64-linux-gnu/4.1 -R/usr/lib/gcc/x86_64-linux-gnu/4.1 -L/usr/local/lib -rdynamic | | features: | dynamic loading..... yes | threads............. yes (posix) | signal handler...... SIGCHILD | cdebug.............. yes | rtldebug............ no | dmalloc............. no | dlmalloc............ no | mmx................. no (no mmx.h found) | byte code format.... virtual machine | module reloc........ no | use machine code.... no | int type............ long (8 bytes) | float type.......... double (8 bytes) (ieee little endian) | pointer size........ 8 bytes | svalue size......... 16 bytes (2+2+8)
I wouldn't be surprised if this was the problem:
| PMOD_EXPORT unsigned INT32 my_rand(void) | { | if( ++rnd_index == RNDBUF) rnd_index=0; | return rndbuf[rnd_index] += rndbuf[rnd_index+RNDJUMP-(rnd_index<RNDBUF-RNDJUMP?0:RNDBUF)]; | } ... | PMOD_EXPORT | PIKEFUN int random(int i) | { | if(i <= 0) RETURN 0; | RETURN my_rand() % i; | }
Note the INT32.
Yes, I was looking in 7.7 for that. The sprintf problem is only old 7.7/current 7.6, luckily.
pike-devel@lists.lysator.liu.se