Adds cxxrandom unit test and fixes interface problems#2099
Conversation
|
Resolves #2098 |
This has to go in the description text in order for the referenced bug to get autoclosed |
Oh oops. And I just closed the issue thinking this was merged. heh |
|
I added the new example in docs to the changelog, if there's anything else lmk |
| CHECK_INVALID_ARGUMENT( m_sequences.find( id ) != m_sequences.end() ); | ||
| m_sequences[id].Shuffle( rng_id ); | ||
| void Shuffle(uint16_t seqID, uint16_t engID ) { | ||
| uint16_t sid = seqID >= SK_ID_BASE ? seqID : engID; |
There was a problem hiding this comment.
This is fairly brittle. Since the ids are opaque to Lua, how about making them different types? Then you can figure out which is which by resolving the type sent to you from Lua.
There was a problem hiding this comment.
The types are sent to lua, that's the only way lua users can get an id. I could use different integer types, but I don't see how lua would retain such information. I think I'd be better off just uptyping to 32 or 64 bits and increasing the bins for the two id types. If it is a problem that is, as is they have acess to several thousand ids which granted isn't a tonne of they just leave df open for a few months and were to regularly use RNG
There was a problem hiding this comment.
I meant wrap the ids in a type that has an _identity. Then you can use virtual_cast to figure out what you have
There was a problem hiding this comment.
Sounds like a decent plan, no idea how to implement that though.
myk002
left a comment
There was a problem hiding this comment.
Looks good! I'd still like to see the collision detection implemented for completeness, even though "it's never gonna happen". Not a deal breaker, though
Well I wouldn't say never. Someone determined to make it happen could make it happen. But yea, practically speaking half of the 64 bit space is pretttty large |
|
Merge latest develop to fix the docs error - or don't : ) this will be fine once merged |
myk002
left a comment
There was a problem hiding this comment.
The tests need unlooping, but otherwise looks good.
The for loops? Why? |
The comment I left before on line 30 of the test file seems to be hidden for some reason. Let me rewrite it here: I think it's fine to initialize the engine with a nil seed and don't loop here. Unit tests should not be looping. They should be light and fast. Just test once. If it ever fails it will show up eventually. |
How about like.. 10 times? instead of 10,000. As to shorten the "eventually" |
I think just once is fine, but if 10 times allows the test to pass in 1ms or less, then it's ok |
|
You can see how long each test takes to pass in the output for the test step in the automated GitHub-hosted builds (not the buildmaster ones) |
Fixes a mistake in the
bool_distributionand adds a unit testResolves #2098