Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #54871 > unrolled thread

card dealer

Started bymarkotaht@gmail.com
First post2013-09-27 03:24 -0700
Last post2013-09-28 17:04 -0700
Articles 13 — 9 participants

Back to article view | Back to comp.lang.python


Contents

  card dealer markotaht@gmail.com - 2013-09-27 03:24 -0700
    Re: card dealer Dave Angel <davea@davea.name> - 2013-09-27 11:26 +0000
    Re: card dealer MRAB <python@mrabarnett.plus.com> - 2013-09-27 12:27 +0100
    Re: card dealer Alister <alister.ware@ntlworld.com> - 2013-09-27 11:41 +0000
    Re: card dealer Dave Angel <davea@davea.name> - 2013-09-27 12:08 +0000
      Re: card dealer Denis McMahon <denismfmcmahon@gmail.com> - 2013-09-27 16:10 +0000
        Re: card dealer Dave Angel <davea@davea.name> - 2013-09-27 21:00 +0000
        Re: card dealer Ned Batchelder <ned@nedbatchelder.com> - 2013-09-27 17:40 -0400
          Re: card dealer Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-28 06:01 +0000
            Re: card dealer Ned Batchelder <ned@nedbatchelder.com> - 2013-09-28 06:31 -0400
            Re: card dealer Dave Angel <davea@davea.name> - 2013-09-28 12:56 +0000
            Re: card dealer Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-28 16:49 +0200
              Re: card dealer Tim Roberts <timr@probo.com> - 2013-09-28 17:04 -0700

#54871 — card dealer

Frommarkotaht@gmail.com
Date2013-09-27 03:24 -0700
Subjectcard dealer
Message-ID<0617088e-5aa3-4c5d-b660-22040ee858a1@googlegroups.com>
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[i] = 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 = i + 1
    kaart_tõmmatud[i] = 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.

[toc] | [next] | [standalone]


#54874

FromDave Angel <davea@davea.name>
Date2013-09-27 11:26 +0000
Message-ID<mailman.376.1380281201.18130.python-list@python.org>
In reply to#54871
On 27/9/2013 06:24, markotaht@gmail.com wrote:

> 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[i] = 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 = i + 1
>     kaart_tõmmatud[i] = 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

-- 
DaveA

[toc] | [prev] | [next] | [standalone]


#54875

FromMRAB <python@mrabarnett.plus.com>
Date2013-09-27 12:27 +0100
Message-ID<mailman.377.1380281278.18130.python-list@python.org>
In reply to#54871
On 27/09/2013 11:24, markotaht@gmail.com wrote:
> 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[i] = 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 = i + 1
>      kaart_tõmmatud[i] = 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.

[toc] | [prev] | [next] | [standalone]


#54877

FromAlister <alister.ware@ntlworld.com>
Date2013-09-27 11:41 +0000
Message-ID<7ae1u.2$1W6.0@fx05.am4>
In reply to#54871
On Fri, 27 Sep 2013 03:24:28 -0700, markotaht wrote:

> 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[i] = 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 = i + 1
>     kaart_tõmmatud[i] = 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.


It looks like you a simply selecting a random entry in the deck 
i would suggest you try the following

1) build the deck as a list (i think you are already doing this)
2) shuffle the list (random.shuffle would be good here)
3) pop the cards of the list as required

this resemble the real world & should be easy to break down into various 
classes & expand for multiple decks if req.


-- 
Passionate hatred can give meaning and purpose to an empty life.
		-- Eric Hoffer

[toc] | [prev] | [next] | [standalone]


#54878

FromDave Angel <davea@davea.name>
Date2013-09-27 12:08 +0000
Message-ID<mailman.380.1380283737.18130.python-list@python.org>
In reply to#54871
On 27/9/2013 07:26, Dave Angel wrote:

> On 27/9/2013 06:24, markotaht@gmail.com 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[i])
    kaart_tõmmatud[i] = 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 = 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.


-- 
daveA

[toc] | [prev] | [next] | [standalone]


#54893

FromDenis McMahon <denismfmcmahon@gmail.com>
Date2013-09-27 16:10 +0000
Message-ID<l24am7$j2k$2@dont-email.me>
In reply to#54878
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.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]


#54911

FromDave Angel <davea@davea.name>
Date2013-09-27 21:00 +0000
Message-ID<mailman.392.1380315681.18130.python-list@python.org>
In reply to#54893
On 27/9/2013 12:10, 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.
>

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

-- 
DaveA

[toc] | [prev] | [next] | [standalone]


#54913

FromNed Batchelder <ned@nedbatchelder.com>
Date2013-09-27 17:40 -0400
Message-ID<mailman.394.1380318056.18130.python-list@python.org>
In reply to#54893
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...)

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.

[toc] | [prev] | [next] | [standalone]


#54928

FromSteven D'Aprano <steve+comp.lang.python@pearwood.info>
Date2013-09-28 06:01 +0000
Message-ID<524670be$0$30000$c3e8da3$5496439d@news.astraweb.com>
In reply to#54913
On Fri, 27 Sep 2013 17:40:46 -0400, Ned Batchelder wrote:

> 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

[quote]
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.


-- 
Steven

[toc] | [prev] | [next] | [standalone]


#54935

FromNed Batchelder <ned@nedbatchelder.com>
Date2013-09-28 06:31 -0400
Message-ID<mailman.406.1380364294.18130.python-list@python.org>
In reply to#54928
On 9/28/13 2:01 AM, Steven D'Aprano wrote:
> On Fri, 27 Sep 2013 17:40:46 -0400, Ned Batchelder wrote:
>
>> 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
>
> [quote]
> 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.

[toc] | [prev] | [next] | [standalone]


#54939

FromDave Angel <davea@davea.name>
Date2013-09-28 12:56 +0000
Message-ID<mailman.410.1380373000.18130.python-list@python.org>
In reply to#54928
On 28/9/2013 06:31, Ned Batchelder wrote:

    <snip>
>
> 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.


-- 
DaveA

[toc] | [prev] | [next] | [standalone]


#54946

FromAntoon Pardon <antoon.pardon@rece.vub.ac.be>
Date2013-09-28 16:49 +0200
Message-ID<mailman.415.1380384238.18130.python-list@python.org>
In reply to#54928
Op 28-09-13 12:31, Ned Batchelder schreef:
> On 9/28/13 2:01 AM, Steven D'Aprano wrote:
>> On Fri, 27 Sep 2013 17:40:46 -0400, Ned Batchelder wrote:
>>
>>> 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
>>
>> [quote]
>> 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?

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]


#54981

FromTim Roberts <timr@probo.com>
Date2013-09-28 17:04 -0700
Message-ID<sfre49p2jnmq2dgng6s1dod34i4p6s8qv0@4ax.com>
In reply to#54946
Antoon Pardon <antoon.pardon@rece.vub.ac.be> wrote:
>
>Op 28-09-13 12:31, Ned Batchelder schreef:
>>
>> 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.

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.
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web