Here is a game where cards 1-50 are distributed to two players each having 10 cards which are in random order. Aim is to sort all the cards and whoever does it first is the winner. Every time a person can pick up the card from the deck and he has to replace an existing card. A player can't exchange his cards. i.e only he can replace his card with the card from the deck.A card discarded will go back to deck in random order. Now I need to write a program which does this efficiently.
I have thought of following solution
1) find all the subsequences which are in ascending order in a given set of cards
2) for each subsequence compute a weight based on the probability of the no of ways which can solve the problem.
for ex: If I have a subsequence 48,49,50 at index 2,3,4 probability of completing the problem with this subsequnce is 0. So weight is multiplied by 0 .
Similarly if I have a sequence 18,20,30 at index 3,4,5 then no of possible ways completing the game is 20 possible cards to chose for 6-10 and 17 possible cards to chose for first 2 position ,
3) for each card from the deck, I'll scan through the list and recalculate the weight of the subsequnces to find a better fit.
Well, this solution may have lot of flaws but I wanted to know
1) Given a subsequence , how to find the probability of possible ways to complete the game?
2) What are the best algorithm to find all the subsequences?
So if I understand correctly, the goal is to obtain an ordered hand by exchanging as few cards as possible, right? Have you tried the following approach? It is very simplistic, yet I would guess it has a pretty good performance.
N=50
I=10
while hand is not ordered:
get a card from the deck
v = value of the card
put card in position round(v/N*I)
Related
I am making an algorithm which allocates badminton players into games (2 x 2) in the following way:
Players are divided into pairs.
All possible pair combinations must be done so everyone plays with everyone. If there are 10 players, everyone will belong to 9 pairs.
So far, this is simple to implement.
Then, games should be allocated into 2 courts. This means, 2 games can be going on simultaneously but of course, a player can't be part of two games going on at the same time.
My algorithm idea was:
Create an array containing all possible pairs.
Allocate two pairs from the array into court 1 to play against each other. If the second pair has overlapping members with pair 1, take the next pair from the array. Iterate the array in order and remove allocated pairs from it.
Do the same for court 2 but also make sure that the pairs do not contain overlapping members with players in court 1.
Make a new round and continue from step 2.
This works quite well but as a side effect, on the last rounds, only court 1 will be used because it is impossible to find any more pairs into court 2 fulfilling the condition in step 3. So the capacity of court 2 will be wasted. I am a little unsure if it is even possible to find a perfect solution to this problem. If yes, how the algorithm could be improved?
Using only a coin, a regular deck of playing cards and a 6 sided die, invent a game of chance where you have a 1 in 20 chance of winning in any given turn or attempt. You do not have to use all the items listed above, but you cannot use anything more. you may use them multiple times and/or combine them in each attempt. For example, "a game is played by picking a card from the deck and tossing a coin twice." You win if you get 2 tails and a spade. Probability of winning is 1 /16. Describe your event, how you play and win the game, and show with calculations how the probability of winning = 1/20?
I think you'd get a better answer on mathematical site rather than a programming one. But here's my attempt:
It depends on what sort of rules you allow.
If you allow rules like: throw the dice; if its 1,2,3,4 you lose; if its 5 you win; if its a 6 repeat, then a game with a 1/20 chance of winning would be: throw a coin twice, if you don't get two heads you lose, if you do get two heads throw the dice as above.
If you don't allow such recursive rules then there is no such game. All the elementary events (throwing a particular side of the coin, picking a particular card, throwing a particular value of the dice) have probabilities that can be expressed as N/D where N and D are integers, and D can be factorised as a product of powers of 2,3 and 13. All events made by ands and ors and selections will have probabilities of this form, since they will be finite sums of finite products of probabilities of elementary events. But 1/20 isn't of this form, because 20 = 2*2*5
I came across the solution that uses Patience sort to obtain the length of the Longest Increasing Subsequence (LIS). http://www-stat.stanford.edu/~cgates/PERSI/papers/Longest.pdf, and here - http://en.wikipedia.org/wiki/Patience_sorting.
The proof that following the greedy strategy actually gives us the length correctly has 2 parts -
proves that the number of piles is at least equal to the length of the LIS.
proves that the number of piles using greedy strategy is at most equal to the LIS.
Thus by virtue of both 1) and 2), the solution gives the length of LIS correctly.
I get the explanation for 1), but I just cannot intuitively realize part 2). Can someone may be use a different example to convince me that this is indeed true. Or, you could even use a different proof technique too.
I just read over the paper and I agree that the proof is a bit, um, terse. (I'd say that it's missing some pretty important steps!)
Intuitively, the idea behind the proof is to show that if you play with the greedy strategy and at the end of the game pick any card in a pile numbered p, you can find an increasing subsequence in the original array whose length is p. If you can prove this fact, then you can conclude that the maximum number of piles produced by the greedy strategy is the length of the longest increasing subsequence.
To formally prove this, we're going to argue that the following two invariants hold at each step:
The top cards in each pile, when read from left to right, are in sorted order.
At any point in time, every card in every pile is part of an increasing subsequence whose length is given by the pile index.
Part (1) is easy to see from the greedy strategy - every element is placed as far to the left as possible without violating the rule that smaller cards must always be placed on top of larger cards. This means that if a card is put into pile p, we are effectively taking a sorted sequence and reducing the value of the pth element to a value that's greater than whatever is in position p - 1 (if it exists).
To see part (2), we'll go inductively. The first placed card is put into pile 1, and it's also part of an increasing subsequence of length 1 (the card by itself). For the inductive step, assume that this property holds after placing n cards and consider the (n+1)st. Suppose that it ends up in pile p. If p = 1, then the claim still holds because this card forms an increasing subsequence of length 1 all by itself. Otherwise, p > 1. Now, look at the card on top of pile p - 1. We know that this card's value is less than the value of the card we just placed, since otherwise we would have placed the card on top of that pile. We also know that the card on top of that pile precedes the card we just placed in the original ordering, since we're playing the cards in order. By our existing invariant, we know that the card on top of pile p - 1 is part of an increasing subsequence of length p - 1, so that subsequence, with this new card added into it, forms an increasing subsequence of length p, as required.
Every now and then I read all those conspiracy theories about Lotto-based games being controlled and a computer browsing through the combinations chosen by the players and determining the non-used subset. It got me thinking - how would such algorithm have to work in order to determine such subsets really efficiently? Finding non-used numbers is definitely crossed out as is finding the least used because it's not necesserily providing us with a solution. Also, going deeper, how could an algorithm efficiently choose such a subset that it was used some k times by the players? Saying more formally:
We are given a set of 50 numbers 1 to 50. In the draw 6 numbers are picked.
INPUT: m subsets each consisting of 6 distinct numbers 1 to 50 each,
integer k (0<=k) being the maximum players having all of their 6
numbers correct.
OUTPUT: Subsets which make not more than k players win the jackpot ('winning' means all the numbers they chose were picked in the draw).
Is there any efficient algorithm which could calculate this without using a terrabyte HDD to store all the encounters of every possible 50!/(44!*6!) in the pessimistic case? Honestly, I can't think of any.
If I wanted to run such a conspirancy I would first of all acquire the list of submissions by players. Then I would generate random lottery selections and see how many winners would be produced by each such selection. Then just choose the random lottery selection most attractive to me. There is little point doing anything more sophisticated, because that is probably already powerful enough to be noticed by staticians.
If you want to corrupt the lottery it would probably be easier and safer to select a few competitors you favour and have them win the lottery. In (the book) "1984" I think the state simply announced imaginary lottery winners, with the announcement in each area announcing somebody outside the area. One of the ideas in "The Beckoning Lady" by Margery Allingham is of a gang who attempt to set up a racecourse so they can rig races to allow them to disguise bribes as winnings.
First of all, the total number of combinations (choosing 6 from 50) is not very large. It is about 16 million which can be easily handled.
For each combination keep a count of number of people who played it. While declaring a winner choose the combination that has less than k plays.
If the number within each subset are sorted, then you can treat your subsets as strings - sort them in lexicographical order, then it is easy to count how many players selected each subset (and which subsets were not selected at all). So the time is proportional to the number of players and not the number of numbers in the lottery.
I'm working in Ruby, but I think this question is best asked agnostic of language. It may be assumed that we have access to basic list/array functions, as well as a "random" number generator. Here's what I'd like to be able to do:
Given a collection of n teams, with n even,
Randomly pair each team with an opponent, such that every team is part of exactly one pair. Call this ROUND 1.
Randomly generate n-2 subsequent rounds (ROUND 2 through ROUND n-1) such that:
Each round has the same property as the first (every team is a
member of one pair), and
After all the rounds, every team has faced every other team exactly once.
I imagine that algorithms for doing exactly this must be well known, but as a self-taught coder I'm having trouble figuring out how to find them.
I belive You are describing a round robin tournament. The wikipedia page gives an algorithm.
If You need a way to randomize the schedule, randomize team order, round order, etc.
Well not sure if this is the most efficient algorithm but:
Randomly assign N teams into two lists of same length n/2 (List1, List2)
Starting with i = 0:
Create pairs: List1[i],List2[i] = a team pair
Repeat for i = 1-> (n/2-1)
For rounds 2-> n/2-1:
Rotate List2, so that the first team in List2 is now at the end.
Repeat steps 2 through 5, until List2 has been cycled once.
This link was very helpful to me the last time I wrote a round robin scheduling algorithm. It includes a C implementation of a first fit algorithm for round robin pairings.
http://www.devenezia.com/downloads/round-robin/
In addition to the algorithm, he has some helpful links to other aspects of tournament scheduling (balancing home and away games, as well as rotating teams across fields/courts).
Note that you don't necessarily want a "random" order to the pairings in all cases. If, for example, you were scheduling a round robin soccer league for 8 games that only had 6 teams, then each team is going to have to play two other teams twice. If you want to make a more enjoyable season for everyone, you have to start worrying about seeding so that you don't have your top 2 teams clobbering the two weakest teams in their last two games. You'd be better off arranging for the extra games to be paired against teams of similar strength/seeding.
Based on info I found through Maniek's link, I went with the following:
A simple round robin algorithm that
a. Starts with pairings achieved by zipping [0,...,(n-1)/2] and [(n-1)/2 + 1,..., n-1]. (So, if n==10, we have 0 paired with 5, 1 with 6, etc.)
b. Rotates all but one team n-2 times clockwise until all teams have played each other. (So in round 2 we pair 1 with 6, 5 with 7, etc.)
Randomly assigns one of [0,..., n-1] to each of the teams.