SeedableRng::Seed and from_hashable #62
Conversation
Also removed SeedableRng impl for IsaacWordRng: it's not reproducible across platforms
These changes make it possible to sample from closed ranges, not only from open. Included is a small optimisation for the modulus operator, and an optimisation for the types i8/u8 and i16/u16.
The license declaration in the README is non-specific. I think this is a hold-over from extraction from the Rust repo. The Rust repo has a file that details the other licenses involved. I scanned through this code and most of it has a rust standard mit/apache header. Some files have no header, and could be under BSD, but if that's the case, that specific license text needs to be added somewhere to this repo.
Update README.md license section
fuchsia: magenta was renamed zircon
Bump to 0.3.17
Allow sampling from a closed integer range
No reseeding
This makes documentation work correctly with the new pulldown-cmark Markdown parser (rust-lang/rust#44229).
Fix formatting warnings with commonmark enabled
I have implemented it as a function instead of a trait, as that makes it easy to add it to every RNG ont at a time. I split the `init` function in two instead of the current version that uses a bool to select between two paths. This makes it more clear how the seed is used. The current `mix` macro has to be defined in the function, and would have to be duplicated. Therefore I converted it to a seperate function. I precalculated the values a...h, but am not sure this is a good idea. It makes the resulting code smaller, and gives a small performance win. Because it are 'magic' values anyway, I thought why not?
Also moved the `impl_uint_from_fill` macro from `os.rs` to `randcore`. I had to modify its error handling anyway, and it is shared with `OsRng`.
|
I found a way to move |
Add HC-128 RNG
And a little cleanup around the init functions
Replace `convert_slice_{32,64}` with `read_u{32,64}_into`
Restrict the seed type to a few more array sizes
Make u128 range use widening multiply
Also minor doc fix
|
Updated: rebased and squashed. I still have the old history locally, but don't see much value. |
|
High time to get this merged 😄. Moving How confident are you in the custom finalizers? And is there anything specific I should look at? I would like it if the RNG tests would only depend on things in |
|
Actually, I think I will replace SeaHash with MetroHash; it's better known and reviewed and has similar performance, as well as native 128-bit output and 256-bits of state (IIRC), and a permutation function which should make it relatively easy to output any amount of state. But I didn't get that done yet. |
|
If we go with 128-bit hashes, there is a lot more choice. MetroHash, CityHash, FarmHash, MurmurHash, SpookyHash, maybe more. This repro contains a list of hashes with benchmarks: https://github.com/rurban/smhasher 128-bit MetroHash and MurmurHash3 seem about evenly matched for small inputs. I wonder what their performance on x86 is. |
|
That repo benchmarks hash functions by throughput on reasonably large data sizes. We don't care much about that. It also doesn't say much about security (other than some stuff about hash tables which I don't even think is correct). I agree that simplicity is fairly important; it seems most hash functions innards aren't that complex, but the input/output functions can get complex to handle multiple input sizes, optimise special cases, and some other functionality. Hmm, this conversation is split between two threads? |
If you click on the name of the hash, there are also the results for hashing 1, 2, 3, 4, etc. bytes. And the last column is useful for us, because that shows if it is statistically ok. We don't really have security considerations here, right?
Sorry 😄 Seemed to fit there. Link for others that may read this: #18 (comment) |
Edit: PR no longer shows the code thanks to our rebasing of Rand history, but the commit is still available here.
Implement seeding via hash function, as discussed in #18.
This is a very rough implementation.
To discuss, regarding the hash function:
from_hashablebehind a feature gate (hashorseahash) until we're more comfortable with the idea — that allows stabilisingrand-corewithout this feature, in theory. But hopefully we don't need to do this.AsBytesFixedimpls are needed, e.g. foru64AsBytesFixedis the best way of going about this. I'm considering moving the hashing into the trait implementation withtrait Hash<H> { fn hash(state: &mut H, val: Self); }or similar. This allows specialised implementations of SeaHash.from_hashableshould be more general, e.g. consume a SeaHash struct.)Regarding
SeedableRng:Seedan associated type is a compromise;SeedSizeassociated constant doesn't appear to work; we do however restrictSeedto types supported byFinalizeSeedau64array instead ofu8array is certainly more convenient for us; any reason we shouldn't do this?SeedableRng::from_seedimpls for Isaac aren't 100% backwards compatible (old version allowed much larger seeds).Lots to discuss, but I think this is moving forward. (@ticki if you get the time, I'd love your thoughts.)