528 karma · joined June 29, 2015
It's still not clear to me if there are some types of glass that do allow vitamin D synthesis or not.
https://github.com/dotnet/corefx/issues/23298
The redzen library contains RNGs that address all of the known issues, e.g. see:
https://github.com/colgreen/Redzen/blob/master/Redzen/Random...
https://github.com/colgreen/Redzen/blob/master/Redzen/Random...
That Xoshiro256StarStarRandom source has also been merged into Math.Net.
https://github.com/colgreen/Redzen/blob/master/Redzen/Random...
There's an explanation in the comments, and a link to the original fuller explanation and source, here:
https://mumble.net/~campbell/tmp/random_real.c
I.e. I'm pretty sure your approach gives a non uniform distribution, but happy to discuss in more detail if you want.
https://github.com/dotnet/corefx/issues/23298
I wrote some replacement classes that address all of the known issues, here:
https://github.com/colgreen/Redzen/tree/master/Redzen/Random
https://www.nuget.org/packages/Redzen/
Source code here (there are three variants):
https://github.com/colgreen/Redzen/tree/master/Redzen/Sortin...
None of the standard framework sort methods perform a stable sort so it's handy for that, as well as being a lot faster for some data, i.e. with pre-sorted runs. Otherwise the framework now uses introsort which is pretty good, so you should definitely performance test with both. I use both sorts depending on the context and I usually end up using the built in introsort, with timsort used for a few special cases.
I figure it works best if you over allocate slots, so that on average you only have to do very few hops on each linked list walk (or no walk at all).
Aside: This is the method employed by .NET's Dictionary<K,V> class.
Further - it's generally faster to use structure of arrays rather than array of structures, thus in the above scheme the dictionary items/payloads and the linked list pointers could be in separate arrays.
To summarise...
Xoroshiro256+ is slightly faster but fails some linearity tests in the low order bits, however when generating 64 bit floats only 53 bits are used, thus if you take the most significant 53 bits then Xoroshiro256+ is perfectly fine. It's also probably fine for generating the full 64 bits for the vast majority of cases, unless you have some very specific requirements. But for peace of mind there is the option to take the 15% slower version for a PRNG that is still sub-nanosecond (per 64 bits generated, on contemporary superscalar CPUs) and that passes all tests that the authors were aware of.
I.e. your quote relates to xoshiro256+, not Xoshiro256* *.
On this basis another way of approaching the problem is to loop over the whole array and return the result at the end, but this of course would take N/2 loops on average, whereas the nested if can exit early. A compromise might be to loop over short sub-spans of the array, and do an exit early test at the end of each sub-span.
A good sub-span length for scalar code might be around 16, for one because we hit the law of diminishing returns for longer spans.
Also I think is_sorted_asc() or is_sorted_ascending() might be a better name if this were for a function in a general purpose library.
Yes I agree, it's not a bug in the sense of a silly mistake that slipped through development and testing. It's a flaw / attack-vector that no-one thought of... until now.