# Analyze overhanded shuffles

Rod is moderating a card game between two players: George and Tim. Currently, Tim is shuffling the cards. Rod suspects that Tim is trying to cheat, so he needs your help to check that the shuffle is fair.

Tim is doing the overhanded shuffle: he cuts a pile of cards from the bottom of the deck, then cuts various parts from the top of the pile onto the top of the deck, and repeats the process a few times.

Rod is eagle-eyed and can see exactly how many cards Tim is cutting each time, however he can't calculate and keep track of the cards as fast as Tim is shuffling. This is where you come in: Rod would like you to write a program or function that gets the detailed shuffling information and determines whether the shuffle is fair, weak or a trick.

• If after shuffling, less than 25 pairs of adjacent cards remain adjacent (in the same order), then the shuffle is fair and the game can go on.
• If at least 25 (but not all) pairs of adjacent cards remain adjacent, then the shuffle is weak and Rod will bonk Tim over the head and ask him to shuffle some more.
• If all the cards remain in the same position at the end, then Tim is obviously cheating and Rod will whack him with a large trout.

This is code golf, so the shortest code wins.

Input:

You will get a series of numbers between 0 and 52 (both exclusive) separated by space, on several lines, where each line represents a round of shuffling that begins and ends with all the cards piled together.

On each line, the first number is the number of cards Tim cuts from the bottom of the deck, and each subsequent number is a number of cards he drops from his hand onto the top of the deck. If any cards remain after the last number on a line, you should assume that Tim puts them on top of the deck.

The input is guaranteed to be valid. There is at least one line of numbers, and each line contains at least 2 numbers. The first number on each line is not smaller than the sum of all the other numbers on the same line. A trailing newline is optional, you may assume that the input has one or that it doesn't have one.

Output:

Your program should print/return "fair" if the shuffle is fair, "weak" if the shuffle is weak and "trick" if Tim is keeping all the cards in the same order. A trailing newline is optional.

Example:

The deck is assumed to have 52 cards, but for demonstration purposes, I'll use a smaller deck of 10 cards.

Input:

5 3 1
4 2 2


Initial deck, viewed from the top: 0 1 2 3 4 5 6 7 8 9
50 1 2 3 4 (5 6 7 8 9 in hand)
35 6 7 0 1 2 3 4 (8 9 in hand)
18 5 6 7 0 1 2 3 4 (9 in hand)
end of line ➜ 9 8 5 6 7 0 1 2 3 4
49 8 5 6 7 0 (1 2 3 4 in hand)
21 2 9 8 5 6 7 0 (3 4 in hand)
23 4 1 2 9 8 5 6 7 0
4 pairs remain adjacent: (3 4) (1 2) (5 6) (6 7)

Test cases:

43 5 5 5 5 5 5 5 5
43 5 5 5 5 5 5 5 5
43 5 5 5 5 5 5 5 5


Output: fair

43 5 5 5 5 5 5 5 5
43 5 5 5 5 5 5 5 5
43 5 5 5 5 5 5 5


Output: weak

29 24
19 18
38 2 1 8 13 6 4
47 15 16 5 2 1 7
34 22 9 3
44 9 10 11 3 1 7
33 18 4 2 3 3


Output: fair

24 6 12 4
25 3 19
36 4 25 2
19 11 1 3
15 9 3
37 5 27


Output: weak

26 13
26 13
26 13
26 13


Output: trick

50 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2


Output: weak

50 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
50 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2


Output: trick

50 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
49 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2


Output: fair

Requirements:

• If you write a function, it can either read from the standard input or receive the input as a single string parameter. Also, the function can either print out the output or return it.
• The program must be runnable in Linux using freely available software.
• The source code must use only ASCII characters.
• No standard loopholes.
• Why the restriction to ASCII? Many languages (APL, machine code, TI-BASIC) don't use ASCII at all, so you're implicitly disallowing those. – lirtosiast Jul 13 '15 at 23:00
• @ThomasKwa Because I don't like the issues associated with displaying and counting non-ASCII characters. Some of those languages have ASCII representations or alternatives. I think it's not a very harsh restriction, and it slightly levels the playing field. – aditsu quit because SE is EVIL Jul 13 '15 at 23:09
• I think a scoring system like "Entries that use only printable ASCII characters will have their byte count multiplied by log(95)/log(256)" would be a better option if you want to fairly incentivize printable ASCII submissions. The reasoning is that the information content of entries with the same score would be equal. Personally, I would still prefer a plain scoring by bytes though. – lirtosiast Jul 14 '15 at 1:05

# Pyth, 62 bytes

@c"weak trick fair"d-!JlfhT-M.:us_cG.u+NYtKrH7-52hK.zU52 2>J26


Demonstration.

# CJam, 76 75 bytes

52,qN/{[~](52\-@/(\e_@{/(@+\e_}/\+}/2ew::m2f/0-,_!\26>-"weak trick fair"S/=


Try it online in the CJam interpreter.

## JavaScript, 292 289 bytes

This could probably get some more bytes squeezed out of it, but it's a quick first pass for now:

d=[];for(i=0;i<52;i+=1)d[i]=i
s=prompt().split('\n')
s.forEach(function(e,i){s[i]=e.split(' ')
h=d.splice(-s[i][0],99)
for(j=1;j<s[i].length;j+=1)d.unshift.apply(d,h.splice(0,s[i][j]))
d.unshift.apply(d,h)})
for(c=0;i>1;i-=1)if(d[i-2]==d[i-1]-1)c+=1

EDIT: Saved 3 bytes by reusing the value of i from the deck-building loop when counting the number of adjacent cards.