card dealer

[markotaht]

from random import *
from math import floor


kaarte_alles = 52
kaart_tõmmatud = [False for i in range(52)]


mast = ["ärtu", "ruutu", "poti", "risti"]
aste = ["äss", "kaks", "kolm", "neli","viis", "kuus", \
"seitse", "kaheksa", "üheksa", "kümme", "soldat",\
"emand", "kuningas"]

def tõmba_kaart():
global kaarte_alles
if kaarte_alles == 0:
print("Segan pakki")
kaarte_alles = 52
for i in range(52):
kaart_tõmmatud = False
kaarte_alles -= 1
n = random(kaarte_alles)
kaart = vali_järgmine_vaba(n)
m = kaart % 13
a = kaart / 13
print(mast[int(a)] + " " + aste[int(m)])

def vali_järgmine_vaba(n):
i = -1

while(n > 0):
n -= 1
i = i + 1
while kaart_tõmmatud:
i = i + 1
kaart_tõmmatud = True
return i

def random(n):
return randint(0, n)

while True:
n = int(input("Mitu kaarti tõmmata(0 et väljuda): "))
if(n==0):
break

for i in range(n):
tõmba_kaart()


HI im trying to make a card dealer, but this code doesent work correctly. It deasl cards, but the cards to repeat. when i type in 52 ten i might get 3the same cards. This is a translation from my c++ code. In c++ it works correctly.

 

[Dave Angel]

from random import *
from math import floor

kaarte_alles = 52
kaart_tõmmatud = [False for i in range(52)]


mast = ["ärtu", "ruutu", "poti", "risti"]
aste = ["äss", "kaks", "kolm", "neli","viis", "kuus", \
"seitse", "kaheksa", "üheksa", "kümme", "soldat",\
"emand", "kuningas"]

def tõmba_kaart():
global kaarte_alles
if kaarte_alles == 0:
print("Segan pakki")
kaarte_alles = 52
for i in range(52):
kaart_tõmmatud = False
kaarte_alles -= 1
n = random(kaarte_alles)
kaart = vali_järgmine_vaba(n)
m = kaart % 13
a = kaart / 13
print(mast[int(a)] + " " + aste[int(m)])

def vali_järgmine_vaba(n):
i = -1

while(n > 0):
n -= 1
i = i + 1
while kaart_tõmmatud:
i = i + 1
kaart_tõmmatud = True
return i

def random(n):
return randint(0, n)

while True:
n = int(input("Mitu kaarti tõmmata(0 et väljuda): "))
if(n==0):
break

for i in range(n):
tõmba_kaart()


HI im trying to make a card dealer, but this code doesent work correctly. It deasl cards, but the cards to repeat. when i type in 52 ten i might get 3 the same cards. This is a translation from my c++ code. In c++ it works correctly.

If you had created your global list containing list(range(52)), then you
could do nearly your entire program with one call to random.sample.

http://docs.python.org/3.3/library/random.html#random.sample

 

[MRAB]

from random import *
from math import floor


kaarte_alles = 52
kaart_tõmmatud = [False for i in range(52)]


mast = ["ärtu", "ruutu", "poti", "risti"]
aste = ["äss", "kaks", "kolm", "neli","viis", "kuus", \
"seitse", "kaheksa", "üheksa", "kümme", "soldat",\
"emand", "kuningas"]

def tõmba_kaart():
global kaarte_alles
if kaarte_alles == 0:
print("Segan pakki")
kaarte_alles = 52
for i in range(52):
kaart_tõmmatud = False
kaarte_alles -= 1
n = random(kaarte_alles)
kaart = vali_järgmine_vaba(n)
m = kaart % 13
a = kaart / 13
print(mast[int(a)] + " " + aste[int(m)])

def vali_järgmine_vaba(n):
i = -1

while(n > 0):
n -= 1
i = i + 1
while kaart_tõmmatud:
i = i + 1
kaart_tõmmatud = True
return i

def random(n):
return randint(0, n)

while True:
n = int(input("Mitu kaarti tõmmata(0 et väljuda): "))
if(n==0):
break

for i in range(n):
tõmba_kaart()


HI im trying to make a card dealer, but this code doesent work correctly. It deasl cards, but the cards to repeat. when i type in 52 ten i might get 3 the same cards. This is a translation from my c++ code. In c++ it works correctly.

Suppose random(...) returns 0.

In 'vali_järgmine_vaba', n == 0, so it won't run anything in the
'while' loop, therefore i == -1, therefore:

kaart_tõmmatud[-1] = True

(which sets the last item in the list).

If random(...) returns 0 again (which is possible),
'vali_järgmine_vaba' will do exactly the same thing.

 

[Dave Angel]

On 27/9/2013 06:24, (e-mail address removed) wrote:

I sent the previous message long before I had finished.

If you had created your global list containing list(range(52)), then you
could do nearly your entire program with one call to random.sample.

http://docs.python.org/3.3/library/random.html#random.sample

What is your goal? Are you trying to make the logic match your C++
code? Are you just trying to solve the problem, or are you trying to
figure out where the bug is in your present code.

If it were my problem, I'd build a deck as a list, shuffle it with
random.shuffle(), then deal the cards out in order. I might also use
list.pop() to take items off, so I wouldn't need any separate counter.

If i were trying to figure out why the existing code fails, I'd start
with an assert right before setting the flags.

assert(not kaart_tõmmatud)
kaart_tõmmatud = True

Once you do that, and it fires, you know explicitly that you have a bug.

i believe the code may be fixed by changing the function
vali_järgmine_vaba() to begin as follows:

def vali_järgmine_vaba(n):
i = 0
while kaart_tõmmatud:
i = i + 1

while(n > 0):

But I would point out that this is a horribly unreadable way to do it.
It's possibly appropriate for C, which is mostly unreadable anyway. But
even there, there are much better approaches. For example, i recall
writing a shuffle function in C decades ago, which took an array of (52)
unique items and put them in random order. For an array of size 52, it
did it with exactly 51 swaps, without any searching like you're doing in
the above function.

 

[Denis McMahon]

i recall
writing a shuffle function in C decades ago, which took an array of (52)
unique items and put them in random order.

Whenever I tried to write shuffles I came up against a fairly fundamental
limit:

52! > prng states

Granted prngs seem to be better on the importing entropy from elsewhere
front these days.

 

[Dave Angel]

Whenever I tried to write shuffles I came up against a fairly fundamental
limit:

52! > prng states

Granted prngs seem to be better on the importing entropy from elsewhere
front these days.

in 1978, I implemented a random number generator that the OS sequenced
through between scheduling processes, so that any individual process
would be relatively safe from that phenomenon. Of course I was limited
to the precision of the math package - 10**13

 

[Ned Batchelder]

Whenever I tried to write shuffles I came up against a fairly fundamental
limit:

52! > prng states

Granted prngs seem to be better on the importing entropy from elsewhere
front these days.

Python's PRNG holds plenty of state to handle card shuffling. Python's
random number generator has a period of 2**19337-1, so it has that many
states. That is much larger than 52!, about 10**5933 times larger.
(Unless I've botched the math...)

The other variable is how many states the initial seed can have. If
os.urandom is available, then it seeds with 16 bytes of OS-supplied
randomness. But 52! is about 2**226, so the 128 bits of seed isn't
enough to make all shuffles possible.

You could seed a Random yourself with more bits if you really wanted to.

--Ned.

 

[Steven D'Aprano]

Python's PRNG holds plenty of state to handle card shuffling. Python's
random number generator has a period of 2**19337-1, so it has that many
states. That is much larger than 52!, about 10**5933 times larger.
(Unless I've botched the math...)

There's a warning about that in the docs:

http://docs.python.org/3/library/random.html#random.shuffle

Note that for even rather small len(x), the total number of permutations
of x is larger than the period of most random number generators; this
implies that most permutations of a long sequence can never be generated.
[end quote]

If I've done that maths right, it turns out that 2025 is the largest
number of items that a list can have for Python's default PRNG to
generate every possible shuffle. But does it really matter? For most
purposes, I'd say No. Even if you generated one trillion shuffles per
second, you would have to keep shuffling for more than a trillion years
before repeating yourself.

To be pedantic: a *lot* more than a trillion years. Approximately
10**5789 trillion years. That's about a:

trillion trillion trillion trillion trillion trillion trillion trillion
trillion trillion trillion trillion trillion trillion trillion trillion
trillion trillion trillion trillion trillion trillion trillion trillion
.... and so on for 57 more lines ... years.


So in practice it's not really relevant that some shuffles won't be
generated. They'll be randomly distributed throughout the space of all
possible shuffles, which is so large that you really won't notice the
missing ones.

 

[Ned Batchelder]

Python's PRNG holds plenty of state to handle card shuffling. Python's
random number generator has a period of 2**19337-1, so it has that many
states. That is much larger than 52!, about 10**5933 times larger.
(Unless I've botched the math...)

There's a warning about that in the docs:

http://docs.python.org/3/library/random.html#random.shuffle

Note that for even rather small len(x), the total number of permutations
of x is larger than the period of most random number generators; this
implies that most permutations of a long sequence can never be generated.
[end quote]

If I've done that maths right, it turns out that 2025 is the largest
number of items that a list can have for Python's default PRNG to
generate every possible shuffle. But does it really matter? For most
purposes, I'd say No. Even if you generated one trillion shuffles per
second, you would have to keep shuffling for more than a trillion years
before repeating yourself.

To be pedantic: a *lot* more than a trillion years. Approximately
10**5789 trillion years. That's about a:

trillion trillion trillion trillion trillion trillion trillion trillion
trillion trillion trillion trillion trillion trillion trillion trillion
trillion trillion trillion trillion trillion trillion trillion trillion
... and so on for 57 more lines ... years.


So in practice it's not really relevant that some shuffles won't be
generated. They'll be randomly distributed throughout the space of all
possible shuffles, which is so large that you really won't notice the
missing ones.

I've thought that way about it too: there are so many shuffles any way,
it won't be a problem. But think about it like this: if you shuffle a
deck of 52 cards with a default Python random object, then once you have
dealt out only 28 cards, the entire rest of the deck is completely
determined. That is, given the sequence of the first 28 cards, there's
only one choice for how the remaining 24 will be dealt. Depending on
what you need from your deck of cards, that could be a complete disaster.

Is it a problem for a card game simulation? No. Is it a problem for a
program that analyze correlations between the start of the deck and the
end of the deck? Maybe.

--Ned.

 

[Dave Angel]

On 28/9/2013 06:31, Ned Batchelder wrote:

I've thought that way about it too: there are so many shuffles any way,
it won't be a problem. But think about it like this: if you shuffle a
deck of 52 cards with a default Python random object, then once you have
dealt out only 28 cards, the entire rest of the deck is completely
determined. That is, given the sequence of the first 28 cards, there's
only one choice for how the remaining 24 will be dealt. Depending on
what you need from your deck of cards, that could be a complete disaster.

Is it a problem for a card game simulation? No. Is it a problem for a
program that analyze correlations between the start of the deck and the
end of the deck? Maybe.

Only if there is some correlation between the random number algorithm
and whatever properties you're checking between start and end of deck.
And if there is, then you've just struck one of the limitations of a
*pseudo* random gen.

I have no idea what sheme is actually used in Python's generator, but
one approach that helps avoid such troubles is to keep a pool of the
"next" P random numbers (where P might be a few hundred). Then use an
*independent* random number generator (which could be very simple) to
select which item of the pool to use next (followed by replacement from
the first).

it's kind of a local-shuffle of the very long stream of numbers.

Even fairly poor random number generators, if they generate close to
2**n values (for a int size of n) generally become very good when
shuffled this way.

 

[Antoon Pardon]

Op 28-09-13 12:31, Ned Batchelder schreef:

On 9/27/13 12:10 PM, Denis McMahon wrote:
On Fri, 27 Sep 2013 12:08:33 +0000, Dave Angel wrote:

i recall
writing a shuffle function in C decades ago, which took an array of
(52) unique items and put them in random order.
Whenever I tried to write shuffles I came up against a fairly
fundamental limit:

52! > prng states

Granted prngs seem to be better on the importing entropy from elsewhere
front these days.


Python's PRNG holds plenty of state to handle card shuffling. Python's
random number generator has a period of 2**19337-1, so it has that many
states. That is much larger than 52!, about 10**5933 times larger.
(Unless I've botched the math...)

There's a warning about that in the docs:

http://docs.python.org/3/library/random.html#random.shuffle

Note that for even rather small len(x), the total number of permutations
of x is larger than the period of most random number generators; this
implies that most permutations of a long sequence can never be generated.
[end quote]

If I've done that maths right, it turns out that 2025 is the largest
number of items that a list can have for Python's default PRNG to
generate every possible shuffle. But does it really matter? For most
purposes, I'd say No. Even if you generated one trillion shuffles per
second, you would have to keep shuffling for more than a trillion years
before repeating yourself.

To be pedantic: a *lot* more than a trillion years. Approximately
10**5789 trillion years. That's about a:

trillion trillion trillion trillion trillion trillion trillion trillion
trillion trillion trillion trillion trillion trillion trillion trillion
trillion trillion trillion trillion trillion trillion trillion trillion
... and so on for 57 more lines ... years.


So in practice it's not really relevant that some shuffles won't be
generated. They'll be randomly distributed throughout the space of all
possible shuffles, which is so large that you really won't notice the
missing ones.

I've thought that way about it too: there are so many shuffles any way,
it won't be a problem. But think about it like this: if you shuffle a
deck of 52 cards with a default Python random object, then once you have
dealt out only 28 cards, the entire rest of the deck is completely
determined. That is, given the sequence of the first 28 cards, there's
only one choice for how the remaining 24 will be dealt. Depending on
what you need from your deck of cards, that could be a complete disaster.

I don't see it. Unless given those 28 cards you can actually predict
those 24 other cards or at least can devise some betting strategy that
will allow you to beat the odds I don't see how this could lead to a
disaster.

Is it a problem for a card game simulation? No. Is it a problem for a
program that analyze correlations between the start of the deck and the
end of the deck? Maybe.

Well if a program would actually find a correlation between the start of
the deck and the end, that may indeed be a cause for worry. But what
evidence is there for that possibility?

 

[Tim Roberts]

Op 28-09-13 12:31, Ned Batchelder schreef:

I don't see it. Unless given those 28 cards you can actually predict
those 24 other cards or at least can devise some betting strategy that
will allow you to beat the odds I don't see how this could lead to a
disaster.

That's exactly the problem. Because the number of permutations is limited,
once you know the first 28 cards, you can uniquely identify the permutation
you started with, and that's enough to get the entire sequence.

Now, it's going to take a hell of a lot of memory to store that
information, so I'm not sure it is a disaster in a practical sense.