Random Number Generators
The fair way to do this is to take 3 random bits, make sure they're not 6 or 7, and then use the value as a die roll. Do this twice and you have your roll of two dice.
He gave you the technical answer to how a random number generator works - to pick ONE number. In there, he slipped in how to pick two dice.
The simple answer is this: You have the RNG generate a number from 1 to 6 - twice.
algorithm = a formula [pretty much]. It's a formula that generates a number that, for the next number, doesnt have a recognizable pattern. However, if you discover the formula, you would be able to predict the next number it seems.
Let's say your algo. generate numbers 0-999. Now divide 1000 by 6 and you get 166.67. So zero to that number can be '1' on the die. If the algo. generates 167 to 333 you simulate a roll of '2', etc
you can see that you can have round off errors, therefore 0-999,999 is probably better, and so on for that too.
you got an answer from a non-mathemetician, let's see if that gets criticized!
Is my thinking flawed?
Quote: wrragsdaleBut wouldn't it be fair to say that a RNG has no effect on dice probabilities because it's only choosing numbers at random. It has no knowledge that on six-sided dice there are more combinations to arrive at 7 than there are combinations to arrive at...let's say 2? More combinations to arrive at a 5 than at 12 etc...
Is my thinking flawed?
the dice don't know either, there is an equal chance that 1-6 comes up on one die, then on the second die that die thoughtlessly deals out 1-6 equally as well. It's just that there are 6 ways to get a 7, one way to get boxcars, etc
Your thinking is flawed if you think the RNG picks ONE number from 2 to 12. It actually picks a number from 1 to 6. The program that is using the RNG does that twice, then adds the two random numbers to come up with the two dice total. It also compares them for Hard Ways, etc.Quote: wrragsdaleBut wouldn't it be fair to say that a RNG has no effect on dice probabilities because it's only choosing numbers at random. It has no knowledge that on six-sided dice there are more combinations to arrive at 7 than there are combinations to arrive at...let's say 2? More combinations to arrive at a 5 than at 12 etc...
Is my thinking flawed?
The RNG that I use simply delivers a number from zero up to but not including one with precision to 15 decimal places. It's up to me, as the programmer, to make that random number do what I want. In your example of a coin flip, I would take the number issued by the RNG and multiply it by 2. I would then truncate the remaining decimals leaving me with either a zero or a one with equal probability. I would then assign the word "heads" to zero and "tails" to the numner one.Quote: wrragsdaleBut wouldn't it be fair to say that a RNG has no effect on dice probabilities because it's only choosing numbers at random. It has no knowledge that on six-sided dice there are more combinations to arrive at 7 than there are combinations to arrive at...let's say 2? More combinations to arrive at a 5 than at 12 etc...
Is my thinking flawed?
In the case of the dice roll, you are talking about two seperate events with equal chances of being an integer from one to six. So it's up to me, the programmer, to grab two numbers from the RNG and assign them to two different variables from one to six. I then add up the two variables to properly simulate what happens in reality.
For a deck of cards, it gets complicated so what I do is let the RNG assign a value from zero up to but not including one to each "card" in my virtual deck. I then sort the cards by the number assigned and turn those numbers into Integers from one to 52 ( or 53 with a joker ) because integers are conceptually easier to work with. In the case of a tie, the database decides the order based on the primary key so the Two of Clubs will always come before the Ace of Spades. But with granularity into the trillions, that's a risk I'm willing to accept.
Is the tie breaking done before or after the conversion to integers?Quote: s2dbakerI then sort the cards by the number assigned and turn those numbers into Integers from one to 52 ( or 53 with a joker ) because integers are conceptually easier to work with. In the case of a tie, the database decides the order based on the primary key so the Two of Clubs will always come before the Ace of Spades.
During. Here's the geekery:Quote: kpIs the tie breaking done before or after the conversion to integers?
Update shuffle
Set sortorder = x.sortorder
From ( Select shuffle_num,
c_index,
row_number() over(order by sortorder) sortorder
From shuffle
Where shuffle_num = @l_shuffle_num ) x
Inner Join shuffle y
On x.shuffle_num = y.shuffle_num
And x.c_index = y.c_index
Out of curiosity, what language is that?Quote: s2dbakerHere's the geekery:
Quote: s2dbakerFor a deck of cards, it gets complicated so what I do is let the RNG assign a value from zero up to but not including one to each "card" in my virtual deck. I then sort the cards by the number assigned and turn those numbers into Integers from one to 52 ( or 53 with a joker ) because integers are conceptually easier to work with. In the case of a tie, the database decides the order based on the primary key so the Two of Clubs will always come before the Ace of Spades. But with granularity into the trillions, that's a risk I'm willing to accept.
Why are you using integer conversions for the RNG values? With this shuffle algorithm, I don't think you need to convert at all. If you have a table with two columns, A for cards and B for floats, then you just randomly assign the float values in column B, sort on it, and A is now your shuffled deck. On initialization you need to assign 0..51 to column A, but only once (not each time). The only thing you need to do for a new shuffle is re-enter floats for column B and re-sort. Then just use a DB cursor to deal the cards.
Microsoft T-SQLQuote: DJTeddyBearOut of curiosity, what language is that?
Notice too that I have a shuffle number. I can debug if I choose to save the shuffles which comes in handy early in the process. Also, I can have three processors hitting the same table and get 750 hands per second. If you know Microsoft T-SQL, you know that cursors = slow. Avoid at all costs! Once I have the order converted to Integers, I can select directly from the "deck" the card in the 23rd position should I choose to. It leaves me with lots of flexibility.Quote: MathExtremistWhy are you using integer conversions for the RNG values? With this shuffle algorithm, I don't think you need to convert at all. If you have a table with two columns, A for cards and B for floats, then you just randomly assign the float values in column B, sort on it, and A is now your shuffled deck. On initialization you need to assign 0..51 to column A, but only once (not each time). The only thing you need to do for a new shuffle is re-enter floats for column B and re-sort. Then just use a DB cursor to deal the cards.
Quote: MathExtremist200,000 shuffles per second using C#
That's what I'm thinking. SQL is too slow for this type of thing.
But my original quandary was satisfied by using the floats for the sort and then using the rowid for the integer conversion.
Quote: s2dbakerWow, no love here for the the SQL! I find it to be very flexible. I can make changes to stored procs while processes that use them are running and do a whole lot of programming no-nos in the interest of reduced development time. It's worth the trade-off just so that I don't have to compile :)
What, are you compiling by hand? :)
Seriously, my code is maybe 500 lines long - compiling takes less than a second. Also, the 32-bit version of the Microsoft debugger has an edit-and-continue function where you can change running code without recompiling. Either way, I think you'll find that with a 200x improvement in runtime, it's faster to stop, edit, recompile, and re-run than it is to churn through a sim using random functions in SQL. And that's assuming the RNG built into your database is worth using for Monte Carlo analyses...
The SQL RNG seems to be just fine. I tweeked it a little. I dropped an index from the shuffle table, stopped deleting and just did updates and it's twice as fast as it was before. still not 200,000 per second but I'm making progress ;)Quote: MathExtremistEither way, I think you'll find that with a 200x improvement in runtime, it's faster to stop, edit, recompile, and re-run than it is to churn through a sim using random functions in SQL. And that's assuming the RNG built into your database is worth using for Monte Carlo analyses...
