Mir Random v0.3.0 release

Nathan S. no.public.email at example.com
Fri Dec 22 00:43:07 UTC 2017


About package
--------------
>Mir-Random [1] is a random number generator library that covers 
>C++ STL [2]. It is compatible with mir.ndslice, std.algorithm, 
>and std.range. In the same time mir.random has its own API, 
>which is more secure and safe compared with std.random.

Release 0.3.0
--------------
You may find the release notes with hyperlinks more useful: 
https://github.com/libmir/mir-random/releases/tag/v0.3.0

Performance Increases
--------------
We now use Daniel Lemire's fast alternative to modulo reduction. 
Compiling with LDC 1.6.0 for x86-64, Mt19937_64 randIndex 
throughput increased 40% for uint and 136% for ulong. 
Xoroshiro128Plus randIndex throughput increased 73% for uint and 
325% for ulong.

The required mir-algorithm version has increased to v0.7.0 
because extMul is necessary for the ulong version.

New since v0.2.8
--------------
- New engine: SplitMix64 / Splittable64
- Convenience functions related to thread-local randoms: rne 
(like std.random rndGen); threadLocal!Engine for arbitrary 
engine; & ways of mucking about with the bookkeeping state that 
most people won't need but a few have requested in the past.
- Made some engines compatible with APIs that expect 
std.random-style UniformRNG. Compatible as-is: Xoroshiro128Plus; 
all predefined PCG engines; and the new SplitMix64/Splittable64 
engines. For any others there is an adaptor. Copy-constructors 
are disabled so they will only work with functions that "do the 
right thing" and take PRNGs by reference and don't make implicit 
copies of them.

Fixed since v0.2.8
--------------
- Changed many parts of the library to be @safe.
- Linux GETRANDOM in unpredictableSeed now works on 
non-x86/x86-64 architectures.
- Removed endian-dependency when producing 64-bit values from a 
native-32-bit PRNG.

Changed APIs
--------------
- The versions of genRandomBlocking/genRandomNonBlocking that 
take a pointer and a length are no longer @trusted. Instead there 
are trusted overloads for both that take a ubyte[].
- mir.random.algorithm has been changed in the interest of memory 
safety. You can still write unsafe code but now if you try to 
write @safe code the library will let you. Instead of taking 
engines by reference and storing their addresses (which could 
result in the stored address outliving the engine), now the 
various functions require arguments to be either objects or 
pointers to structs. For local-scoped engines there are templates 
with alias parameters. This is a major API change so 
feedback/criticism is welcome.

Links
--------------
[1] https://github.com/libmir/mir-random
[2] http://en.cppreference.com/w/cpp/numeric/random


More information about the Digitalmars-d-announce mailing list