• Nathan S. (54/58) Dec 21 2017 Release 0.3.0

Nathan S. <no.public.email example.com> writes:

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