«

Hi all,

The following post is probably not appropriate for this group but I
know there are brilliant minds active at this place (trust me, this
puzzle will involve some time and lots of grey matter), so would
appreciate if you guys can jump in with any solutions/suggestions.
Thanks!

You are given a deck containing n cards. While holding the deck:

1. Take the top card off the deck and set it on the table
2. Take the next card off the top and put it on the bottom of the deck
in your hand.
3. Continue steps 1 and 2 until all cards are on the table. This is a
round.
4. Pick up the deck from the table and repeat steps 1-3 until the deck
is in the original order.

Write a program to determine how many rounds it will take to put a
deck back into the original order. This will involve creating a data
structure to represent the
order of the cards. This program should be written in C or C++. Do
not use STL. It should
take a number of cards in the deck as a command line argument and
write the result to stdout.

Ankur Arora wrote:
> Do not use STL.

Any rational reason for this?

In message <CQZLk.87$>, Juha Nieminen
<> writes
>Ankur Arora wrote:
>> Do not use STL.
>
> Any rational reason for this?

It motivates homework question 2:

"Why didn't your first design work?
(a) dangling pointers;
(b) uninitialised pointers;
(b) double deletion;
(c) incorrect container insertion/deletion algorithm;
(d) all of the above"

:-/
--
Richard Herring

Ankur Arora wrote:
> Hi all,
> ["do my homework" redacted]

You can find a good solution here:

http://www.parashift.com/c++-faq-lit...t.html#faq-5.2

"Ankur Arora" wrote:

> The following post is probably not appropriate for this group but I
> know there are brilliant minds active at this place (trust me, this
> puzzle will involve some time and lots of grey matter), so would
> appreciate if you guys can jump in with any solutions/suggestions.
> Thanks!
>
> You are given a deck containing n cards. While holding the deck:
>
> 1. Take the top card off the deck and set it on the table
> 2. Take the next card off the top and put it on the bottom of the deck
> in your hand.
> 3. Continue steps 1 and 2 until all cards are on the table. This is a
> round.
> 4. Pick up the deck from the table and repeat steps 1-3 until the deck
> is in the original order.
>
> Write a program to determine how many rounds it will take to put a
> deck back into the original order. This will involve creating a data
> structure to represent the
> order of the cards. This program should be written in C or C++. Do
> not use STL. It should
> take a number of cards in the deck as a command line argument and
> write the result to stdout.

The question is phrased in a way to start you on a wild goose chase.
Identify that bit and go on from there. I think that is the only part that
requires gray (or grey) matter.

On Oct 23, 12:42*am, Ankur Arora <ankuraror...@gmail.com> wrote:

> This program should be written in C or C++.

How about that? Any rationale for that?

Ali

On Oct 23, 2:51*pm, Richard Herring <junk@[127.0.0.1]> wrote:
> In message <CQZLk.87$yl1...@read4.inet.fi>, Juha Nieminen
> <nos...@thanks.invalid> writes
>
> >Ankur Arora wrote:
> >> Do not use STL.
>
> > *Any rational reason for this?
>
> It motivates homework question 2:
>
> "Why didn't your first design work?
> (a) dangling pointers;
> (b) uninitialised pointers;
> (b) double deletion;
> (c) incorrect container insertion/deletion algorithm;
> (d) all of the above"
>
> :-/
> --
> Richard Herring

Wow!!sorry about that, I can see its very offending.'will make it a
point to follow the guidelines.Thanks.

Here's what I have come up with so far (very basic, algorithmic
steps):-
- use of pointers to manipulate the deck since we will be doing a lot
of shuffling. A link list would be a good choice with each node
representing a card and the link list chain representing a particular
ordering.
- At least two loops, outer representing the condition till the deck
is in the original order and the inner representing a complete round.
- The inner loop will have its auxiliary list i.e. a particular
ordering after the completion of a complete round.
- At the end of each inner loop iteration we will check the auxiliary
list with the original list to see whether its the same as the
original list (this would be done in the conditional statement of the
outer loop).

Need to find out the implementation details for the inner loop (guess
that would easy) and a way to check whether the auxiliary list is same
as the original list at the end of each inner loop iteration.

Any other design/ideas ?

Ankur Arora wrote:

[snip]
> Here's what I have come up with so far (very basic, algorithmic
> steps):-
> - use of pointers to manipulate the deck since we will be doing a lot
> of shuffling. A link list would be a good choice with each node
> representing a card and the link list chain representing a particular
> ordering.
> - At least two loops, outer representing the condition till the deck
> is in the original order and the inner representing a complete round.
> - The inner loop will have its auxiliary list i.e. a particular
> ordering after the completion of a complete round.
> - At the end of each inner loop iteration we will check the auxiliary
> list with the original list to see whether its the same as the
> original list (this would be done in the conditional statement of the
> outer loop).
>
> Need to find out the implementation details for the inner loop (guess
> that would easy) and a way to check whether the auxiliary list is same
> as the original list at the end of each inner loop iteration.
>
> Any other design/ideas ?

Yes: The shuffle rule describes a fixed permutation of [1...n]. All you need
to do is find the order of that permutation. That can be accomplished by
finding the cycle representation and computing the LCM of the lengths of
all cycles. This approach has the advantage of being much faster in those
cases where the counting would take forever (and there are such n).


Best

Kai-Uwe Bux

On 2008-10-23 15:51, Ankur Arora wrote:
> On Oct 23, 2:51 pm, Richard Herring <junk@[127.0.0.1]> wrote:
>> In message <CQZLk.87$yl1...@read4.inet.fi>, Juha Nieminen
>> <nos...@thanks.invalid> writes
>>
>> >Ankur Arora wrote:
>> >> Do not use STL.
>>
>> > Any rational reason for this?
>>
>> It motivates homework question 2:
>>
>> "Why didn't your first design work?
>> (a) dangling pointers;
>> (b) uninitialised pointers;
>> (b) double deletion;
>> (c) incorrect container insertion/deletion algorithm;
>> (d) all of the above"
>>
>> :-/
>> --
>> Richard Herring
>
> Wow!!sorry about that, I can see its very offending.'will make it a
> point to follow the guidelines.Thanks.
>
> Here's what I have come up with so far (very basic, algorithmic
> steps):-
> - use of pointers to manipulate the deck since we will be doing a lot
> of shuffling. A link list would be a good choice with each node
> representing a card and the link list chain representing a particular
> ordering.
> - At least two loops, outer representing the condition till the deck
> is in the original order and the inner representing a complete round.
> - The inner loop will have its auxiliary list i.e. a particular
> ordering after the completion of a complete round.
> - At the end of each inner loop iteration we will check the auxiliary
> list with the original list to see whether its the same as the
> original list (this would be done in the conditional statement of the
> outer loop).
>
> Need to find out the implementation details for the inner loop (guess
> that would easy) and a way to check whether the auxiliary list is same
> as the original list at the end of each inner loop iteration.

A tip: represent each card with a number and let the original deck be
sorted (so a deck of 4 cards would start as 1, 2, 3, 4). Then checking
if the deck is back to the original state is easy.

--
Erik Wikström

On Oct 23, 3:50*pm, Stuart Golodetz
<sgolod...@NdOiSaPlA.pMiPpLeExA.ScEom> wrote:
> Juha Nieminen wrote:
> > Ankur Arora wrote:
> >> Do not use STL.

> > * Any rational reason for this?

> By not allowing you to use STL, they encourage you to write
> your own classes to do the same thing - the process of
> reinventing the wheel will convey to you (a) a fair amount
> about the STL, (b) an understanding of why reinventing the
> wheel is generally to be avoided and (c) a healthy
> appreciation of the hard work put in by the people who have
> worked on the STL over the years.

I'm not so sure about that. Writing a simple array class which
is usable in one particular context is actually very simple.
Designing the interface so that it can be generally usable in
the widest number of different contexts is another matter, not
to mention implementing it in a manner so that it will have
adequate performance for all possible uses.

It's worth implementing some simple containers and algorithms
yourself, to understand the issues better, but doing so will not
help you better understand the STL.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34