imneme / pcg-c Goto Github PK
View Code? Open in Web Editor NEWPCG — C Implementation
License: Apache License 2.0
PCG — C Implementation
License: Apache License 2.0
When a function such as pcg_setseq_64_xsh_rr_32_boundedrand_r is called with a bound of 0 and bound is the denominator of a modulus operation, the result is undefined behavior -- possibly a division by zero error.
Such functions should check for and return zero in such cases to avoid undefined behavior.
This popped up on my radar due to a build failure on NetBSD/powerpc. This platform
does not have native support for 128-bit integer operations.
gcc -O2 -D_FORTIFY_SOURCE=2 -O3 -std=c99 -I../include -c -o pcg-global-32.o pcg-global-32.c
In file included from pcg-global-32.c:33:
../include/pcg_variants.h:2178:33: error: 'PCG_STATE_SETSEQ_64_INITIALIZER' undeclared here (not in a function)
2178 | #define PCG32_INITIALIZER PCG_STATE_SETSEQ_64_INITIALIZER
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pcg-global-32.c:35:38: note: in expansion of macro 'PCG32_INITIALIZER'
35 | static pcg32_random_t pcg32_global = PCG32_INITIALIZER;
| ^~~~~~~~~~~~~~~~~
gmake[1]: *** [<builtin>: pcg-global-32.o] Error 1
Inspecting include/pcg_variants.h
reveals that PCG_HAS_128BIT_OPS
ends up
as undefined on this platform, due to lack of __SIZEOF_INT128__
being defined, and
hence PCG_STATE_SETSEQ_64_INITIALIZER
also ends up being undefined, as it's
only defined if PCG_HAS_128BIT_OPS
is defined.
Apologies for the cross-post. I would really like to see PCG appear in NumPy. It is both high performance and easy to use in complex applications. We have the code ready and have also written the extension that allows it to run on systems without __uint128
, e.g., Windows.
The main PR is close to being merged in numpy/numpy#13163 . NumPy is BSD licensed but has a strict requirement for GPL compatibility. Unfortunately, this means the Apache 2.0 cannot be included.
Is there any chance that you could consider dual-licensing?
Current master fails to compile on Mac OS X 10.10 when compiling for i386 (32-bit).
$ CFLAGS=-m32 LDFLAGS=-m32 make
cd src; /Applications/Xcode.app/Contents/Developer/usr/bin/make
cc -m32 -O3 -std=c99 -I../include -c -o pcg-advance-8.o pcg-advance-8.c
cc -m32 -O3 -std=c99 -I../include -c -o pcg-advance-16.o pcg-advance-16.c
cc -m32 -O3 -std=c99 -I../include -c -o pcg-advance-32.o pcg-advance-32.c
cc -m32 -O3 -std=c99 -I../include -c -o pcg-advance-64.o pcg-advance-64.c
cc -m32 -O3 -std=c99 -I../include -c -o pcg-advance-128.o pcg-advance-128.c
cc -m32 -O3 -std=c99 -I../include -c -o pcg-output-8.o pcg-output-8.c
cc -m32 -O3 -std=c99 -I../include -c -o pcg-output-16.o pcg-output-16.c
cc -m32 -O3 -std=c99 -I../include -c -o pcg-output-32.o pcg-output-32.c
cc -m32 -O3 -std=c99 -I../include -c -o pcg-output-64.o pcg-output-64.c
cc -m32 -O3 -std=c99 -I../include -c -o pcg-output-128.o pcg-output-128.c
cc -m32 -O3 -std=c99 -I../include -c -o pcg-rngs-8.o pcg-rngs-8.c
cc -m32 -O3 -std=c99 -I../include -c -o pcg-rngs-16.o pcg-rngs-16.c
cc -m32 -O3 -std=c99 -I../include -c -o pcg-rngs-32.o pcg-rngs-32.c
cc -m32 -O3 -std=c99 -I../include -c -o pcg-rngs-64.o pcg-rngs-64.c
cc -m32 -O3 -std=c99 -I../include -c -o pcg-rngs-128.o pcg-rngs-128.c
cc -m32 -O3 -std=c99 -I../include -c -o pcg-global-32.o pcg-global-32.c
cc -m32 -O3 -std=c99 -I../include -c -o pcg-global-64.o pcg-global-64.c
pcg-global-32.c:35:38: error: use of undeclared identifier 'PCG_STATE_SETSEQ_64_INITIALIZER'
static pcg32_random_t pcg32_global = PCG32_INITIALIZER;
^
../include/pcg_variants.h:2178:33: note: expanded from macro 'PCG32_INITIALIZER'
#define PCG32_INITIALIZER PCG_STATE_SETSEQ_64_INITIALIZER
^
1 error generated.
make[1]: *** [pcg-global-32.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2
Digging a little more, seems to be related to the absence of 128-bit ops (PCG_HAS_128BIT_OPS is undefined). Any ideas?
Thanks!
Not an issue per-se; just a usage query.
My existing RNG is based on grabbing bits from a SHA2 stream. It passes tests very well; but it is computationally expensive. However, as a by-product of doing it this way, when I need another 512 bits of entropy, I call a callback that adds data to the sequence; if nothing additional is added it uses the previous output as the input, if additional data is provided, the previous output plus the additional data is used as the input the SHA2 generator...
https://github.com/d3x0r/-/blob/master/org.d3x0r.common/salty_random_generator.js#L3
Other than the initial seed, I would like to retain that sort of ability... I was planning on using a RNG something like this instead, grabbing 4 or 8 128 bit values at a time... (maybe a configurable length) and then having the ability to modify the seed...
--
Edit: I do plan on using this for procedural generators; (like perlin noise) so reproducability is key; Also for building sectors of voxels using 3d perlin noise to describee like ore content; so I can use the x,y,z of the sector as a seed for the noise generated for that sector...
We should probably use git to tag a release, and then provide 2 links on the website: (1) zipball for the tagged release (something like https://help.github.com/articles/linking-to-releases/) and (2) zipball for master.
(2) is easy to do right away because it already exists: https://github.com/imneme/pcg-c/zipball/master.
(1) requires creating a tagged commit, then pushing it here, and then linking it using the 'zipball' syntax somehow.
I just think it's better to do this as it is more automated and also offloads the storage/bandwidth (however trivial) from pcg-random.org to github.
to properly create the lib and include directory and copy the files over, the Makefile needs to be fixed
PREFIX needs to be in brackets and directory need to be made if non existing.
here is the fix:
install: all
@mkdir -p $(PREFIX)
@mkdir -p $(PREFIX)/lib
@mkdir -p $(PREFIX)/include
install src/libpcg_random.a $(PREFIX)/lib/.
install -m 0644 include/pcg_variants.h $(PREFIX)/include/.
pcg_variants.h:158:49: warning: implicit conversion loses integer precision: 'unsigned long long' to 'uint32_t' (aka 'unsigned int') [-Wshorten-64-to-32]
return pcg_rotr_32(((state >> 18u) ^ state) >> 27u, state >> 59u);
pcg-c/extras/entropy.c:76:36: warning: comparison of integers of different signs: 'ssize_t' (aka 'long') and 'size_t' (aka 'unsigned long') [-Wsign-compare]
return (close(fd) == 0) && (sz == size);
A lot of projects are using CMake now for portability and other reasons. For pcg-cpp
, an issue with further rationale and pull request exists here: imneme/pcg-cpp#43
I would love to see CMake support for pcg-c
as well, since it would make it very easy to drop into projects using CMake.
I noticed that the CPP version (line 1617 in pcg_random.hpp) of this library has extended generation schemes allowing arbitrary periods (section 7.1 in the paper). Could we add this to this C version as well?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.