Shuffle card deck

[JC]

I am very new to programming and learning on my own.

Why do I keep getting duplicate values using this code? I want to shuffle a
deck of 52 cards. The logic seems right to me.

Randomize

For C = 0 To 1000

C1 = Cards(Int(Rnd * 52)) ' returns a number from 0 to 51

C2 = Cards(Int(Rnd * 52)) ' returns a number from 0 to 51
Cards(C1) = C2 ' Value of C2 is assigned to Card in location Cards(C1)
Cards(C2) = C1 ' Value of C1 is assigned to Card in location Cards(C2)

Next C

TIA

[James Rogers]

gb*@email.si (Gorazd Bozic) wrote in news:bl******** **@planja.arnes .si:

In article <Xn************ *************** *@204.127.36.1> ,
James Rogers <ji************ **@att.net> wrote:

The reason is pretty simple. Both Pips and Suits are defined as
enumerated types. In Ada enumerated types are non-numeric discrete
types. There is no multiplication operation defined for any
emumerated type.

This is not what I meant. If you can get the number of elements in an
enumerated type (I assume the attribute is called Range):

Suits'Range = 4
Pips'Range = 13

So if you take these two numbers, surely you can multiply them and get
52 as a result. So instead of using a hardcoded number, you would use
the actual number of all possible cards as defined by those two
types. That would allow you to change the definition of Pips or Suits
and avoid having to recalculate by hand and change another constant in
a program.

I guess if you make a mistake in a constant, the Initialize function
will generate an exception. If you use Suits'Range * Pips'Range, it will
not as the types will be consistant with the range of Deck_Index.

I see what you mean. Your assumption of the Ada syntax is reasonable
but not quite accurate.

In Ada, the Range attribute evaluates to the full range of values, not
the number of values, for a type. In other words, it evaluates to a
list of all the valid values for a type.

Every Ada enumerated type has several automatically defined attributes.
Range is one. Another is Pos. The Pos attribute returns the position
number of an enumeration value. There are also the attributes First
and Last which evaluate to the lowest and highest valid value for the
enumerated type.

Using this information, I could have written my code as follows.

Suits_Length : constant := Suits'Pos(Suits 'Last) -
Suits'Pos(Suits 'First) + 1;
Pips_Length : constant := Pips'Pos(Pips'L ast) -
Pips'Pos(Pips'F irst) + 1;

type Deck_Index is range (1..Suits_Lengt h * Pips_Length);

This would have caused the compiler to calculate the values,
eliminating any possible counting error on my part. If I wanted
to define the card deck in a generic package I would have been
forced to use this approach. I was taking a short cut.

You are correct that this approach is generally stronger.

Jim Rogers

[Scott D. Barrish]

I'll be happy to send anyone my Ada textbooks...Don 't need them anymore :-D

[Raoul Watson]

"James Rogers" <ji************ **@att.net> wrote in message
news:Xn******** *************** *******@204.127 .36.1...

"Raoul Watson" <Wa*****@Intell igenCIA.com> wrote in
news:WQ******** *********@nwrdn y01.gnilink.net :

"James Rogers" <ji************ **@att.net> wrote in message
news:Xn******** *************** *******@204.127 .36.1...

"Raoul Watson" <Wa*****@Intell igenCIA.com> wrote in
news:NA******** ********@nwrdny 01.gnilink.net:

>
>
> I agree. Why not pick randomly from a sequential deck. No one knows
> the deck is "not shuffled" and drawing randomly is the same as
> having a shuffled deck
>:)

Because that is not efficient.
Every card must have a flag indicating whether or not it has been
dealt. Your random pick will frequently pick a card that has already
been dealt, requiring you to pick another card until you find one
that has not yet been dealt.
Jim.. if you draw the card you simply zero the array. If it's zero
it's not pickable.

That is yet another inefficiency. Did you ever study algorithms?

This problem gets worse as you deal more cards. Dealing the

last card from the deck can be very slow.

Well.. you either haven't been programming for very long or you have
no idea about processor power. On a very old 166 Pentium 1, VB can
loop 50,000 (fifty thousand times) executing a random statement plus
two IF then statements in less than 8/10 eight tenth of a second. Slow
? Yeah sure not nano second.

Wrong on both counts. I have been programming since 1972.
I do understand the speed of a 3 GHz processor.

Obviously you come from the school of thought that creates fatware.
Do you really believe that efficiency is unnecessary if a processor
is fast? 8/10 of a second on a multi-GHz processor is an eternity.
Why do you want to buy a fast processor then force it to execute
slow code? That simply wastes the resources of the processor.

Why don't you try this on your PC.. if it takes more than three-tenth
of a second, you have a very slow PC :)

<snip irrelevant example>

0.3 seconds. Let's see, that is 300000 nanoseconds, or 900000 cycles for
a 3GHz processor.

An algorithm that takes 300000 cycles (0.1 seconds) is very inefficient
compared to another algorithm that achieves the same goals yet takes only
5769 cycles (0.002 seconds). Why are you satisfied with making your
fast processor behave as though it was operating at only 2% of its
actual speed? You are effectively making your 3GHz processor run at 58
MHz. By today's standards that is terrible performance.

If you want to benefit from all your system's performance you cannot
run grossly inefficient software on the machine. Overall system

performance is achieved through the combined effects of fast hardware and efficient
software. Just as slow hardware will reduce your performance, inefficient
software will also reduce performance. It is a waste of money to buy
fast hardware so that you can run inefficient software.

You buy fast hardware because performance matters. You then claim that it
is acceptable to run slow software because performance does not matter.
I do not think such a position is well reasoned.

Jim Rogers

You wanted to create a flag to indicate that a card is picked. I said,
that's not necessary, simply zero the array. So *who* is being inefficient?
Study algorithms? Why.. if you did, you wouldn't have used a flag. If you
started programming in 1972, you would understand that memory is precious.
An array of flags is a waste of memory.

You would also know that computing power is premium. Remember checking your
card deck after being punched? Remember only having 32K of RAM and you have
to run a Cobol program while compiling RPG? Playing computer so that you
only need to compile once? Those days are gone. Yes, we can be wastefull
now.

My point is exactly that. Just because a method is not "elegant" it doesn't
mean that it doesn't work. I know several elegant "algorithm savvy" way of
shuffling a card deck but that wasn't as simple as the one Mel Wilson
mentioned, and I agree with him.

These were your exact words about speed "Dealing the last card from the deck
can be very slow" when you mention *slow*, it is from a user point of
view -NOT- processor point of view as you wormed out. All I was saying is,
you are wrong, it won't be slow (from the user perspective). Who cares about
CPU wasted cycles?

If you worry about CPU wasted cycle, and "fat programming" (huh? If you
compile my method and yours, you will see whose code is fatter :), since you
are an old timer like me, I am sure we can whip up a very memory and speed
efficient shuffling routine. Not in VB, but in Assembly.

I have no further comments on this subject.

[Jordan T. Cox]

Raoul Watson wrote:

"James Rogers" <ji************ **@att.net> wrote in message
news:Xn******** *************** *******@204.127 .36.1...

"Raoul Watson" <Wa*****@Intell igenCIA.com> wrote in
news:WQ****** ***********@nwr dny01.gnilink.n et:

"James Rogers" <ji************ **@att.net> wrote in message
news:Xn***** *************** **********@204. 127.36.1...

"Raoul Watson" <Wa*****@Intell igenCIA.com> wrote in
news:NA**** ************@nw rdny01.gnilink. net:
>
>I agree. Why not pick randomly from a sequential deck. No one knows
>the deck is "not shuffled" and drawing randomly is the same as
>having a shuffled deck
>:)

Because that is not efficient.
Every card must have a flag indicating whether or not it has been
dealt. Your random pick will frequently pick a card that has already
been dealt, requiring you to pick another card until you find one
that has not yet been dealt.

Jim.. if you draw the card you simply zero the array. If it's zero
it's not pickable.

That is yet another inefficiency. Did you ever study algorithms?

This problem gets worse as you deal more cards. Dealing the

last card from the deck can be very slow.

Well.. you either haven't been programming for very long or you have
no idea about processor power. On a very old 166 Pentium 1, VB can
loop 50,000 (fifty thousand times) executing a random statement plus
two IF then statements in less than 8/10 eight tenth of a second. Slow
? Yeah sure not nano second.

Wrong on both counts. I have been programming since 1972.
I do understand the speed of a 3 GHz processor.

Obviously you come from the school of thought that creates fatware.
Do you really believe that efficiency is unnecessary if a processor
is fast? 8/10 of a second on a multi-GHz processor is an eternity.
Why do you want to buy a fast processor then force it to execute
slow code? That simply wastes the resources of the processor.

Why don't you try this on your PC.. if it takes more than three-tenth
of a second, you have a very slow PC :)

<snip irrelevant example>

0.3 seconds. Let's see, that is 300000 nanoseconds, or 900000 cycles for
a 3GHz processor.

An algorithm that takes 300000 cycles (0.1 seconds) is very inefficient
compared to another algorithm that achieves the same goals yet takes only
5769 cycles (0.002 seconds). Why are you satisfied with making your
fast processor behave as though it was operating at only 2% of its
actual speed? You are effectively making your 3GHz processor run at 58
MHz. By today's standards that is terrible performance.

If you want to benefit from all your system's performance you cannot
run grossly inefficient software on the machine. Overall system

performance

is achieved through the combined effects of fast hardware and efficient
software. Just as slow hardware will reduce your performance, inefficient
software will also reduce performance. It is a waste of money to buy
fast hardware so that you can run inefficient software.

You buy fast hardware because performance matters. You then claim that it
is acceptable to run slow software because performance does not matter.
I do not think such a position is well reasoned.

Jim Rogers

You wanted to create a flag to indicate that a card is picked. I said,
that's not necessary, simply zero the array. So *who* is being inefficient?
Study algorithms? Why.. if you did, you wouldn't have used a flag. If you
started programming in 1972, you would understand that memory is precious.
An array of flags is a waste of memory.

You would also know that computing power is premium. Remember checking your
card deck after being punched? Remember only having 32K of RAM and you have
to run a Cobol program while compiling RPG? Playing computer so that you
only need to compile once? Those days are gone. Yes, we can be wastefull
now.

My point is exactly that. Just because a method is not "elegant" it doesn't
mean that it doesn't work. I know several elegant "algorithm savvy" way of
shuffling a card deck but that wasn't as simple as the one Mel Wilson
mentioned, and I agree with him.

These were your exact words about speed "Dealing the last card from the deck
can be very slow" when you mention *slow*, it is from a user point of
view -NOT- processor point of view as you wormed out. All I was saying is,
you are wrong, it won't be slow (from the user perspective). Who cares about
CPU wasted cycles?

If you worry about CPU wasted cycle, and "fat programming" (huh? If you
compile my method and yours, you will see whose code is fatter :), since you
are an old timer like me, I am sure we can whip up a very memory and speed
efficient shuffling routine. Not in VB, but in Assembly.

I have no further comments on this subject.

Despite your saying you have no further comments, I must interject.

A single inelegant (read, slow or inneficient) algorithm is not a
killing point. However, when one programs sloppily and learns to use
inelegant algorithms on a regular basis, their software becomes bloated.
One of our previous programmers learned this way; and thus he is
previous and not current. At one point he created a class to hold a
single variable.

My boss programs inelegantly. His mindset is simply that "processors
are getting faster, so I can program less efficiently.". While his
programs parse data and run for days, mine finish overnight. Why?
Sure, when he runs one or two iterations of his inelegant code - he may
not notice a speed decline. However when he iterates fifty thousand
times, it is quickly noticed (or rather slowly noticed ;p).

Regarding the topic of "memory consumption"; I haven't followed this
thread carefully, so I'm not sure what he meant by "flag"... memory is
much more volatile and inconsequential than cpu speed [1]. So long as
you clear out your memory for each function run (read: your function
isn't recursive); if it takes an extra five megabytes of memory, so
what? The program won't theoretically run any slower - as far as I see.
Mayhaps a small amount, constructing the flag - but that may be
miniscule compared to zeroing the array [2].

And I fully agree with your final paragraph. :) Indeed, if you are
programming in VB - your mind is not quite set on being effecient with
the cpu; rather with being effecient with your own time.

*breaths and waits to be set upon by wolves*

[1] When dealing with small amounts. Larger amounts, that may cause
swapping or machine lag - sure, then care. But the extra 5k that may be
created by an extra array...

[2] That is, rather than comparing it to doing nothing - compare it to
zeroing the array; not that zeroing the array is slower.

--
-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
Jordan T. Cox
Programmer, IT Administrator, Tech Support
Geronimo Development Corporation
-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-