search for: srand

I am building a package that makes a simple visualization. A part of the code is in C++, and utilizes the functions srand() and rand() for purposes not related to statistics (introducing random noise in the visualization). The package compiles without problems on my workstation(s), but when I submitted it to the winbuilder service, I got the following weird message: * checking compiled code ... NOTE File 'tagclou...

...y if we look closer at the assembly file (obtained by *arm-none-eabi-objdump*): the user code (written by me) is in Thumb mode, for example: 1420 00008fd2 <*main*>: 1421 8fd2: b580 push {r7, lr} 1422 8fd4: 466f mov r7, sp *1423 8fd6: f7ff fd83 bl 91d8 <srand>* 1424 8fda: 2000 movs r0, #0 1425 8fdc: bd80 pop {r7, pc} But libc code is in ARM mode: 1563 000091d8 <*srand*>: 1564 91d8: e3a02000 mov r2, #0 1565 91dc: e59f300c ldr r3, [pc, #12] ; 91f0 <srand+0x18> 1566 91e0: e5933000 l...

...f ${LD_LIBRARY_PATH},:${LD_LIBRARY_PATH},} \ # LIBGUESTFS_PATH=$(top_builddir)/appliance \ # TMPDIR=$(top_builddir) diff --git a/cat/Makefile.am b/cat/Makefile.am index 3180b26..2a42954 100644 --- a/cat/Makefile.am +++ b/cat/Makefile.am @@ -132,7 +132,7 @@ random_val := $(shell awk 'BEGIN{srand(); print 1+int(255*rand())}' < /dev/null) TESTS_ENVIRONMENT = \ MALLOC_PERTURB_=$(random_val) \ - LD_LIBRARY_PATH=$(top_builddir)/src/.libs \ + LD_LIBRARY_PATH=$(top_builddir)/src/.libs${if ${LD_LIBRARY_PATH},:${LD_LIBRARY_PATH},} \ LIBGUESTFS_PATH=$(top_builddir)/appliance \ TMPDIR...

Erik, I was thinking of doing this: export MALLOC_PERTURB_=$(awk 'BEGIN { srand(); print int(rand() * 32767 % 255 + 1) }') Or would you prefer using 'date'? On Tue, Mar 19, 2013 at 10:22 PM, Erik de Castro Lopo <mle+la at mega-nerd.com>wrote: > Jesse Weinstein wrote: > > > The subject line mostly says it all, but for reference, having #!/bin/s...

Hi, Has anyone encountered the problem of rgamma function in C? The following simplified program always dies for me, and I wonder if anyone can tell me the reason. #include <Rmath.h> #include <time.h> #include <Rinternals.h> SEXP generateGamma () { srand(time(NULL)); return (rgamma(5000,1)); } Has anyone encountered a similar problem before? Is there another way of generating Gamma random variable in C? P.S. I have no problem compiling and loading this function in R. Thanks for suggestions in advance! --Chandler

Here are some of the patches that I have maintained in the patch queue of my packages that I maintain within the Debian distribution (http://packages.qa.debian.org/libg/libguestfs.html). All of them address FTBFS (fail to build from source) errors that happened with the particular configuration that is used for building the Debian package. Cheers, -Hilko

...umber generator -- a C++ class MTRand // Based on code by Makoto Matsumoto, Takuji Nishimura, and Shawn Cokus // Richard J. Wagner v1.0 15 May 2003 rjwagner at writeme.com the random seed for the Mersenne-Twister is provided by our R-function which gives an (random) integer to the C++ function srand() which in turn sets the seed in the code. Using the set.seed in R makes now the results reproducible, but the results differ between windows and linux. Does anyone know what the problem there is? Our suspicion is that the reason is that some libraries are different implemented on linux and wind...

These calls are in ExternalCalls.cpp, they are platform dependent calls, so maybe llvm should consider including it's own implementation of a random number generator? For the time being I just replaced with calls to srand and rand like Paolo also did, but it needs to be fixed... m.

...tter for many cases, but not for all. Implementing > RNG that is good enough for the tests' purposes, fast enough not to steal > the benchmarks' hot spots and does not use target/library-specific code is > not trivial. > This is not true, all one needs to do is replace existing srand(), rand() with some specific platforms version (and those are usually very simple RNGs). If the code is already using srand()/rand() then there is no reason to assume somehow the benchmark is worse if it always used the FreeBSD one, say, as opposed to a platform specific one. - Daniel I think th...

...2013 14:24, Tim Northover <t.p.northover at gmail.com> wrote: > Could be worth a try. But if that thing really is generating random > numbers I'm not sure replacing one genuine cast-iron random number > with another is the best solution long-term. > The test is initializing srand(1), so in theory, it shouldn't be different between compilers, since Clang is using the same libraries. Also, if the "native" result is generated by GCC, than all problems go away, since the result will be target dependent (or rather, library dependent). Is there a way to turn on the...

Dear all, Am new on this list but need help: I have a fortran code which I compile into a dynamic library (on Solaris). My probem is that when I call this code soon after starting R, it runs ok. But it doesn't for the second time without exiting R first. In this code I have to generate some random numbers. The problem is not about setting the seed. Anyone with an idea what might be going

...mber generator on the given platform. I'll make a note of this and tuck it away for future implementation. Reid. Chris Lattner wrote: > On Tue, 28 Sep 2004, Paolo Invernizzi wrote: > > >>The next major problem is that VC has only >> >>int rand(void) >>void srand( int seed ) >> >>So I donno how to compile the >>ExecutionEngine/Interpreter/ExternalFunctions.cpp that refers to the >>drand48 srand48 lrand48 etc series... >>For now I hacked them, like >> >>double drand48(void) { return (float) rand() / (float) RAND_MAX...

Here I am again... I missed that in the previous diff, they are the usual missing <algorithm> and the std:: namespace missing in sort, find, make_pair. Alkis can you please give them an eye when you have time? The next major problem is that VC has only int rand(void) void srand( int seed ) So I donno how to compile the ExecutionEngine/Interpreter/ExternalFunctions.cpp that refers to the drand48 srand48 lrand48 etc series... For now I hacked them, like double drand48(void) { return (float) rand() / (float) RAND_MAX and so... Is it -------------- next part -----------...

...cation. Taking in account that many client applications developers may be not aware of this at all [and just complain to us, that our compiler is bad because their program is now wrong], we propose switching to self- state maintaining rand() on LLVM side. Attached patch simply replaces the calls to srand() and rand() with a call to rand_r(), which uses static unsigned x value to keep its state locally. Best, - D. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121201/ffc5d28b/attachment.html> ------------...

...ect on my machine where I generate two sets of values in parallel using rand() and am running into infinite loops of values, and couldn't figure out why, so I wrote a test program: #include <iostream> #include <cstdlib> #include <ctime> int main() { int a, b; srand((unsigned)time(0)); for (int i=0 ; i < 50 ; i++) cout << rand() % 32 << " " << rand() % 4 << endl; return 0; } No matter how many times I run this it seems to alternate between generating two different but non-unique sets of...

Hi Renato, > The test is initializing srand(1), so in theory, it shouldn't be different > between compilers, since Clang is using the same libraries. If Clang and GCC disagree on the same source, same machine and with the same libraries, that certainly is odd. But it doesn't make checking against the output of a particular libc...

On 12 March 2013 16:48, Daniel Dunbar <daniel at zuster.org> wrote: > The former mode is historically what the test suite did, the latter mode > is substantially faster (and independent of bugs in the native CC). > Yes, I agree this is better for many cases, but not for all. Implementing RNG that is good enough for the tests' purposes, fast enough not to steal the

Jaren Stangret wrote: > Erik, > > I was thinking of doing this: > export MALLOC_PERTURB_=$(awk 'BEGIN { srand(); print int(rand() * 32767 % > 255 + 1) }') > > Or would you prefer using 'date'? Your's is probably better and this is probably an improvement: awk 'BEGIN { srand(); print int(rand() * 255 + 1) }' Awk's rand seems to be seeded by the current epoch seco...

...123/ogg123.c Thu Dec 7 13:13:36 2000 @@ -324,12 +324,20 @@ if (param.shuffle) { - int i=optind, j=0; - for (i = optind; i < argc; i++) + int i; + int nb = argc - optind; + int *p = alloca(sizeof(int) * nb); + for (i = 0; i < nb; i++) p[i] = i; + + srand (time (NULL)); + for (i = 1; i < nb; i++) { - srand (time (NULL)); - j = (int) ((float) (argc - optind) * rand () / (RAND_MAX + 1.0)); - param.read_file = argv[j+optind]; + int j = i * ((float) rand() / RAND_MAX); + int temp = p[j]; p[j] = p[i]; p[i] = temp; + } + f...

On Tue, 28 Sep 2004, Paolo Invernizzi wrote: > The next major problem is that VC has only > > int rand(void) > void srand( int seed ) > > So I donno how to compile the > ExecutionEngine/Interpreter/ExternalFunctions.cpp that refers to the > drand48 srand48 lrand48 etc series... > For now I hacked them, like > > double drand48(void) { return (float) rand() / (float) RAND_MAX For these, just ifdef...