ociaw / randn Goto Github PK

Hi,

I get the following exception from time to time, now sure what is the root cause.

this is how i intantiate my _rng instance:
var rng = ChaCha.GetChaCha8Factory().Create(ThreadLocalRng.Instance);
I call the following method:
rng.NextUInt32()

Stack trace:
Exception has occurred: CLR/System.IndexOutOfRangeException
Exception thrown: 'System.IndexOutOfRangeException' in RandN.Core.dll: 'Index was outside the bounds of the array.'
at RandN.Implementation.BlockBuffer32`2.NextUInt32()
at RandN.Rngs.ChaCha.NextUInt32()

Since seeds are able to be reused at any time, they need to be serializable so they can be persisted to the file system, sent across a network, etc.

Pcg32 can likely be easily vectorized for an increase in throughput. It may be desired to keep a non-vectorized implementation available, however, since the vectorized implementation may use more memory for buffering.

C# and .NET do not guarantee the implementation of floating point operations - this causes the distribution to sample different numbers on different platforms. For example, on x86, the .NET Framework uses the 80-bit x87 FPU, but uses 64-bit SSE2 instructions on x64.

Where possible (.NET Core 3.1+), we will explicitly use SSE2 instructions. Otherwise, we will do the following: On application start, perform floating point tests to determine if the underlying hardware uses 64-bit or 80-bit floating point operations. If the former, we can use those directly. If the latter, we fallback to a software implementation (based on SoftFloat).

We also want to keep current floating point implementations, but move them into a separate package (such as "UnstableDists" or similar). This lets users use the faster non-software implementation if they can guarantee the platform they are running on or don't care about reproducibility.

Distributions are rather messy at the moment - they're swamped by various implementations of the Uniform distribution. This namespace should be cleaned up - possibilities:

1. Make individual implementations inner classes of Uniform
2. Move individual implementations to a sub-namespace, RandN.Distributions.Uniforms
3. Implement each type on Uniform through IDistribution
4. Provide type-specific generics for supported numeric types ala System.Numerics.Vector

XorShift and MersenneTwister should be moved to separate packages since they aren't an essential part of RandN.
ChaCha contains a significant amount of platform specific code for SIMD support, and is better suited in a separate project to isolate tests.
The above also applies to Pcg32, as it may be vectorized in the future as well.

The Rand package will end up depending on Rand.ChaCha and Rand.Pcg32.

We need to add wrapper RNGs with easy to understand names, so people don't have to trawl through the Rngs namespace and figure out the difference between ChaCha and Mersenne Twister. None of these need to be reproducible, since in that case the user will have to figure out which algorithm they want anyway.

Rand provides 4 different RNGs,

• OsRng is an interface to the operating system's random number source.
• ThreadRng is a handle to a thread-local CSPRNG with periodic seeding from OsRng.
• StdRng is a CSPRNG chosen for good performance and trust of security.
• SmallRng is an insecure PRNG designed to be fast, simple, require little memory, and have good output quality.

We'll treat CryptoServiceProvider as similar enough OsRng, so there's no need to reimplement it. ChaCha is a good fit for StdRng, just need to decide how many rounds. ThreadLocal can be used to create an equivalent of ThreadRng through StdRng. PCG32 is a good candidate for SmallRng, though some statistical quality issues have been found recently.

Type names are TBD - SmallRng/FastRng/InsecureRng, StdRng/StandardRng/Rng, ThreadRng/ThreadLocalRng?

Investigate ensuring that the built NuGet packages are reproducible.

These types have been introduced in .NET 7 and need implementations.

https://devblogs.microsoft.com/dotnet/welcome-to-csharp-10/

File-scoped namespaces in particular will save precious whitespace.
Dependent on whether the desired features will continue to work in .NET Framework 4.8.

https://devblogs.microsoft.com/dotnet/announcing-net-6/

The new BitConverter methods could be useful, and new Vector APIs could make it feasible to implement vectorized ChaCha in a instruction set agnostic manner.

The docsite fails to build on the build server, but not locally on my computer.
https://builds.sr.ht/~ociaw/job/316214

    Executing pipeline "Resources" (20/24) with 1 child module(s)
            Error while copying file /home/build/RandN/docs/input/assets/css/override.css: The process cannot access the file '/home/build/RandN/docs/output/assets/css/override.css' because it is being used by another process.
            Error while executing module CopyFiles
        Error while executing pipeline Resources
Exception during execution: System.AggregateException: One or more errors occurred. (One or more errors occurred. (The process cannot access the file '/home/build/RandN/docs/output/assets/css/override.css' because it is being used by another process.)) (The process cannot access the file '/home/build/RandN/docs/output/assets/css/override.css' because it is being used by another process.) ---> System.IO.IOException: The process cannot access the file '/home/build/RandN/docs/output/assets/css/override.css' because it is being used by another process.
   at System.IO.FileStream.Init(FileMode mode, FileShare share)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
   at System.IO.FileSystem.CopyFile(String sourceFullPath, String destFullPath, Boolean overwrite)
   at System.IO.FileInfo.CopyTo(String destFileName, Boolean overwrite)
   at Wyam.Core.IO.FileProviders.Local.RetryHelper.Retry[T](Func`1 func) in C:\Code\Wyam\Wyam\src\core\Wyam.Core\IO\FileProviders\Local\RetryHelper.cs:line 22
   at Wyam.Core.IO.FileProviders.Local.LocalFile.CopyTo(IFile destination, Boolean overwrite, Boolean createDirectory) in C:\Code\Wyam\Wyam\src\core\Wyam.Core\IO\FileProviders\Local\LocalFile.cs:line 67
   at Wyam.Core.Modules.IO.CopyFiles.<>c__DisplayClass10_0.<Execute>b__1(IFile file) in C:\Code\Wyam\Wyam\src\core\Wyam.Core\Modules\IO\CopyFiles.cs:line 147
   at System.Linq.Parallel.SelectQueryOperator`2.SelectQueryOperatorEnumerator`1.MoveNext(TOutput& currentElement, TKey& currentKey)
   at System.Linq.Parallel.WhereQueryOperator`1.WhereQueryOperatorEnumerator`1.MoveNext(TInputOutput& currentElement, TKey& currentKey)
   at System.Linq.Parallel.PipelineSpoolingTask`2.SpoolingWork()
   at System.Linq.Parallel.SpoolingTaskBase.Work()
   at System.Linq.Parallel.QueryTask.BaseWork(Object unused)
   at System.Linq.Parallel.QueryTask.<>c.<.cctor>b__10_0(Object o)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)

Right now we rely on C# 8's nullable reference types to keep nulls out. This isn't perfect, and doesn't work at all if the consumer doesn't have them enabled as well. Instead, we can use NullGuard to add null checks on public methods automatically.

XorShift has no tests to verify it works as expected.

1. Figure out expected output for some seed.
2. Verify that the XorShift's output matches the expected output.

3 floating point distribution tests fail when run on specifically x86 .NET Framework. I believe this is caused by x86 using extended (80-bit) precision FP math, while x64 and .NET Core uses standard (64-bit) precision through SSE2.

As correcting this will change the behavior of a distribution, it can be included in 0.2 at the earliest.

The IDistribution<T> interface forms a monad. Is there scope for adding implementations of unit, map and bind to RandN? Or perhaps to add Select and SelectMany extension methods so that it could be used with query syntax.

Currently we just have UniformDouble, which needs more unit tests for thorough testing.

In addition, we want specialized distributions for the interval 0-1.

• Closed-Open [0, 1)
• Open-Closed (0, 1]
• Open-Open (0, 1)

We'll need three implementations for each distribution, Single, Double, and Decimal. Extensive tests are needed, including value-stability testing.

We have ociaw.com/randn, but the website should be independent, and in the RandN repository.
We need to generate documentation from the doc comments, as well as use the existing documentation.

RNGCryptoServiceProvider is obsolete as of .NET 6, hence we need to move to RandomNumberGenerator.Create() instead. The issue is naming - perhaps SystemCryptoRng would work?