feat(examples): Add a useful set of high quality pseudo-random number generators

[wyhaines]

I ported a number of my pseudo-random number generator implementations from Ruby to gno while traveling to the retreat last weekend as an exercise in expanding my comfort level with gno code, and expanding my understanding of some of the code internals, while contributing code that others may find interesting or useful.

I added two xorshift generators, xorshift64* and xorshiftr128+. These are both many times faster than the PCG generator that is the gno default, and produce high quality randomness with great statistical qualities. In addition to these, I added both the 32-bit ISAAC implementation (with an added function to return 64 bit values), and the 64-bit ISAAC implementation. ISAAC is a stellar pseudo-random number generator. Both implementations are significantly faster than PCG (though not near so fast as the xorshift algorithms), while producing extremely high quality, cryptographically secure randomness that can not be differentiated from real randomness.

All of these were built to be compatible with the standard Rand() implementation. This means that any of these can be used as a drop-in replacement for the default PCG algorithm:

source = isaac.New()
prng := rand.New(source)

All of these leverage the gno.land/p/demo/entropy package to assist with seeding if no seed is provided. In the case of the ISAAC algorithms, they require 256 uint values for their seed, so they leverage a combination of entropy and xorshiftr128+ to generate any missing numbers in the provided seed.

I also added a function to entropy to return uint64, to facilitate using it for seeding.

I added tests to entropy, and wrote tests for the other generators, as well.

There are a few other things that ended up in this PR. In order to make some fact based assertions about the performance of these generators, I included some code that can be ran via gno run -expr. i.e. gno run -expr 'averageISAAC()' isaac.gno that can be used to get some benchmarks and some very simple self-statistical-analysis on the results, and when I did so, I discovered that the current ufmt.Sprintf implementation didn't support any of the float output flags.

I added float support to it's capabilities, which, in turn, required adding FormatFloat to the strconv.gno/strconv.go implementation in the standard library. I added a test to cover this.

I also noticed that there is a test in tm2/pkg/p2p that is failing on both master and my branch. Specifically, there is a call to sw.Logger.Error() that passes a message and an error, but not "err" before the error. Adding that seemed to clear up the build failure. This, specifically, is line 222 of switch.go.

Currently there is one failing test, which is the code coverage check on tm2, because it is non-obvious to me how to setup a test to properly exercise that one changed line.

Contributors' checklist...

• Added new tests, or not needed, or not feasible
• Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
• Updated the official documentation or not needed
• No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
• Added references to related issues and PRs

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 63.75%. Comparing base (60304df) to head (61c1391).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2868      +/-   ##
==========================================
- Coverage   63.76%   63.75%   -0.02%     
==========================================
  Files         548      548              
  Lines       78681    78681              
==========================================
- Hits        50171    50163       -8     
- Misses      25128    25135       +7     
- Partials     3382     3383       +1     

Flag	Coverage Δ
contribs/gnodev	60.54% <ø> (-0.63%)	⬇️
contribs/gnofaucet	15.77% <ø> (+0.94%)	⬆️
gno.land	73.62% <ø> (ø)
misc/genstd	79.72% <ø> (ø)
tm2	62.40% <ø> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[zivkovicmilos]

Hey @wyhaines, can you update the PR branch with the master branch? 🙏

[thehowl]

Just a couple of comments. I'm not particularly familiar with the algorithms involved here; I don't have the patience to check these against their source implementations and verify the claims there, so I kind of skimmed through the code without much of a critical eye on it.

I have two notes:

• First, maybe @n2p5 can take a look - this looks like the kind of thing up his sleeve.
• Second, maybe we can put this in a p/wyhaines namespace rather than a p/demo/math/rand namespace. I don't know what we want to do with p/demo long-term (keep it? move a lot of it to p/nt? ...), but for now I still consider it as a "semi-official" space, so I'd prefer your own namespace as a place where to have code that is not vetted by the core team ahead of time.

[thehowl]

Suggested change

	// Or use it as a drop-in replacement for the default PRNT in Rand:
	// Or use it as a drop-in replacement for the default PRNG in Rand:

[thehowl]

Suggested change

	// The default random number algorithm in gno was ported from Go's v2 rand implementatoon, which
	// The default random number algorithm in gno was ported from Go's v2 rand implementation, which

[n2p5]

Very cool work.

It would be valuable to decouple your uint64 and float64 work from the math/random work. The changes you introduce there are generally useful and it would give a cleaner path for merging a PR.

This way the larger discussion on where the isaac and isaac64 work should live can be done in isolation from this. I'm still learning about our namespacing conventions myself and @thehowl brings up valid points that maybe work like this should live in a personal namespace and maybe be considered for "promotion" to official namespaces over time.