Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #54871 > unrolled thread
| Started by | markotaht@gmail.com |
|---|---|
| First post | 2013-09-27 03:24 -0700 |
| Last post | 2013-09-28 17:04 -0700 |
| Articles | 13 — 9 participants |
Back to article view | Back to comp.lang.python
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
| From | markotaht@gmail.com |
|---|---|
| Date | 2013-09-27 03:24 -0700 |
| Subject | card 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]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2013-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]
| From | MRAB <python@mrabarnett.plus.com> |
|---|---|
| Date | 2013-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]
| From | Alister <alister.ware@ntlworld.com> |
|---|---|
| Date | 2013-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]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2013-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]
| From | Denis McMahon <denismfmcmahon@gmail.com> |
|---|---|
| Date | 2013-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]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2013-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]
| From | Ned Batchelder <ned@nedbatchelder.com> |
|---|---|
| Date | 2013-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]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-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]
| From | Ned Batchelder <ned@nedbatchelder.com> |
|---|---|
| Date | 2013-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]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2013-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]
| From | Antoon Pardon <antoon.pardon@rece.vub.ac.be> |
|---|---|
| Date | 2013-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]
| From | Tim Roberts <timr@probo.com> |
|---|---|
| Date | 2013-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