Implementations of SFC32/SFC64 chaotic RNGs #65

tertu-m · 2025-06-20T21:26:59Z

This adds an implementation of the SFC32 and SFC64 chaotic RNGs.

There's some work left to be done regarding docs and formatting but they should work; I would like feedback on that.

EDIT: I'm also not even sure if this would be useful. One advantage it does have, perhaps, is that it does not require multiplication at all.

dhardy

At a glance, this seems like something we could add. But should we?

I'd like some justification of why this is useful to people.
Would you be willing to maintain this in case of future bug reports / requests?

dhardy · 2025-06-21T08:22:02Z

rand_sfc/src/lib.rs

@@ -0,0 +1,39 @@
+// Copyright 2025 XXX.


Unfinished?

I'll update that to mention the project now.

tertu-m · 2025-06-21T17:07:10Z

I would be willing to maintain this in the future.

My reasons for suggesting they are included that they are simple, fast generators (in my experience and based on what I could find on the internet they are slightly faster than Xoshiro and faster than PCG), they are high quality, they are reasonably well known as far as I am aware, and they are structurally different from the existing generators present in rand.

Additionally, in principle, stream support could be added as I mentioned in the comments, and this has been done by some people, but I don't think that functionality is very well studied. It is known that correlations exist early in two streams with different increments if the initial values provided for a, b, and c are the same.

EDIT: I guess you knew all that already; I read the comments later where that was mentioned. Anyway I guess it had been talked about in the past and the thought was maybe one more choice would be nice? This implementation doesn't have the counter panic issue, anyway.

dhardy

I'll accept that argument.

I started a review, but didn't get as far as the actual RNG code yet.

rand_sfc/Cargo.toml

dhardy · 2025-06-23T06:58:23Z

rand_sfc/Cargo.toml

+[features]
+serde1 = ["serde"]


Please use serde = ["dep:serde"]

dhardy · 2025-06-23T08:00:22Z

rand_sfc/src/sfc32.rs

+// PracRand uses different mixing step counts for different types of seeds.
+// Here, just use one of the larger values always.
+const SEED_MIXING_STEPS: u32 = 16;


PracRand uses 8 for seed_fast(u64), 12 for seed(u64) or 15 for seed(u32, u32, u32). Perhaps we should use the latter?

I will do that.

rand_sfc/src/sfc32.rs

dhardy · 2025-06-23T08:20:19Z

rand_sfc/src/sfc32.rs

+    fn reference() {
+        // These values were produced with the reference implementation:
+        // https://pracrand.sourceforge.net/
+        let mut rng = Sfc32::from_seed([0, 0, 0, 0, 2, 0, 0, 0, 1, 0, 0, 0]);
+        let expected: [u32; 16] = [
+            0xA87DBC7E,
+            0x1787178C,


Instructions to reproduce would be nice. My hack is something like:

Tweak the number of mixing steps to match (sfc.cpp:92)

Compile: for s in $(find src -name *.cpp); do g++ -I include -c $s; done

g++ -I include -c tools/RNG_output.cpp

g++ *.o -o RNG_output

./RNG_output sfc32 8 0x100000002 | hexdump
hexdump is clearly not the right tool here; we want to read 32-bit LE values not 16-bit LE.

I'll put together a procedure, in all honesty I just spit the values into a file that I then opened in a hex editor and copied in...

Okay so the procedure I came up with is basically:

Compile PractRand as specified in https://pracrand.sourceforge.net/installation.txt.

For Sfc32 run ./RNG_output sfc32 76 0000000100000002 | od -j 12 -t x4 -v (skipping 12 bytes to account for the extra 3 mixing steps). For Sfc64 it's ./RNG_output sfc64 176 0000000000000001 | od -j 48 -t x8 -v.

Your link is wrong (it points at github).

Ah, I didn't know od.

* add PractRand-style seed_from_u64 implementations * Cargo.toml changes * TODO: seed_from_u64 tests, readme?

The readme links are partially dead for now, as the repo isn't part of upstream

dhardy · 2025-07-01T06:44:14Z

rand_sfc/src/common.rs

+// A decent-quality 64 bit linear congruential generator used to extend seeds.
+// Parameters from M. E. O'Neill.
+pub fn seed_extender_lcg (state: u64) -> u64 {
+    let multiplier: u64 = 9199940308585234877;
+
+    state.wrapping_mul(multiplier).wrapping_add(multiplier)
+}


Your code here is essentially a 64-bit LCG with no output permutation or truncation; it appears to have been copied from https://www.pcg-random.org/posts/does-it-beat-the-minimal-standard.html but misses the output function (right shift).

If I recall correctly, the output size being smaller than the LCG state is a key part of ensuring good statistical performance of LCGs — though this may be less important here where only a few output values are used; I don't know enough to say for sure.

However, I still don't understand why you don't want to use the default seed_from_u64 implementation which uses PCG32 — essentially a 64-bit LCG with 32-bit permuted output?

I think I probably took the "we are committing to stability of its output" comment a little more seriously than I should have. If you think that using the default implementation is OK, then we can do that, and I agree that would be better.

As for the LCG:
Yes, that's where I got that LCG from, I would have put the link but I figured that mentioning the author's name was enough (as it's a bog-standard LCG, just with uncommon parameters), but I can add the link if you need. My motivation for just using an LCG was principally it needing fewer lines of code than a PCG.

The reason I skipped the output function (and only for Sfc64, Sfc32 effectively does use it) was that based on the testing that I did the quality of the generator was basically irrelevant, it just had to be something. So I figured using all the bits from an LCG would be good enough, as it would get run through the Sfc64 mixer anyway.

I think I probably took the "we are committing to stability of its output" comment a little more seriously than I should have.

Sorry for not being clearer. No, I just wanted to make a note of this.

I would have put the link but ...

I just searched for the constant. Easy.

dhardy

LGTM except:

run cargo fmt
Move the serde imports from lib.rs to sfc*.rs and test with serde
Rebase or merge master once #66 is merged

tertu-m added 3 commits June 20, 2025 16:20

Initial implementation of sfc crate

159e31f

Remove try_fill_bytes (it can never fail)

9ccac28

Rename uses of "gen" to "rng"

e46c322

dhardy reviewed Jun 21, 2025

View reviewed changes

Update copyright info

cc0478f

dhardy reviewed Jun 23, 2025

View reviewed changes

tertu-m added 4 commits June 25, 2025 09:01

Updates per review

f5c4b54

* add PractRand-style seed_from_u64 implementations * Cargo.toml changes * TODO: seed_from_u64 tests, readme?

Fix embarrassing typo

7a84070

Add a seed scrambling LCG

c147035

Readme, better LCG params, tests for u64 seeding

c06bcc6

The readme links are partially dead for now, as the repo isn't part of upstream

dhardy reviewed Jul 1, 2025

View reviewed changes

tertu-m added 2 commits July 1, 2025 17:19

Benches, go back to rand_core's u64 seeding

d292ecd

Oops, forgot the init benches...

dac5e84

dhardy reviewed Jul 7, 2025

View reviewed changes

		[features]
		serde1 = ["serde"]

Uh oh!

Implementations of SFC32/SFC64 chaotic RNGs #65

Are you sure you want to change the base?

Implementations of SFC32/SFC64 chaotic RNGs #65

Uh oh!

Conversation

tertu-m commented Jun 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dhardy left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tertu-m Jun 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tertu-m commented Jun 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dhardy left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tertu-m Jun 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tertu-m Jul 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dhardy left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tertu-m commented Jun 20, 2025 •

edited

Loading

tertu-m Jun 21, 2025 •

edited

Loading

tertu-m commented Jun 21, 2025 •

edited

Loading

tertu-m Jun 25, 2025 •

edited

Loading

tertu-m Jul 1, 2025 •

edited

Loading