# August 2016 Community Challenge

We've just gotten the July 2016 Community Challenge going, so it's time to pick one for August.

It's time to choose a for August 2016.

• Post your challenge as an answer to this question. Feel free to resubmit non-winning ideas from previous months.
• Vote for those answers which interest you.
• At the end-of-day on Sunday, July 31st, the top-voted post will become the next challenge.

Once the challenge topic is decided, post your solution as a question on the main site and tag it with . The challenge runs throughout August (but nothing stops you from posting an entry later on).

### The Rainfall Challenge

Problem description is copied verbatim from the linked Code Review question:

Problem Statement

A group of farmers has some elevation data, and we're going to help them understand how rainfall flows over their farmland.

We'll represent the land as a two-dimensional array of altitudes and use the following model, based on the idea that water flows downhill:

If a cell’s four neighboring cells all have higher altitudes, we call this cell a sink; water collects in sinks.

Otherwise, water will flow to the neighboring cell with the lowest altitude. If a cell is not a sink, you may assume it has a unique lowest neighbor and that this neighbor will be lower than the cell.

Cells that drain into the same sink – directly or indirectly – are said to be part of the same basin.

Your challenge is to partition the map into basins. In particular, given a map of elevations, your code should partition the map into basins and output the sizes of the basins, in descending order.

Assume the elevation maps are square. Input will begin with a line with one integer, S, the height (and width) of the map. The next S lines will each contain a row of the map, each with S integers – the elevations of the S cells in the row. Some farmers have small land plots such as the examples below, while some have larger plots. However, in no case will a farmer have a plot of land larger than S = 5000.

Your code should output a space-separated list of the basin sizes, in descending order. (Trailing spaces are ignored.)

For examples see the the linked question :)

I like this challenge because it can be solved in so many different ways. It has a large variety of solution processes and it helps with correctly extrapolating from small problem spaces into big problem spaces. Making code correctly deal with scaling is hard for many programmers and this would make for a great project in a new language where (the millionth) FizzBuzz and (the billionth) Linked Lists are utterly boring, but bigger problems seem daunting

• Is input supposed to be delimited as certain way? Like a 3x3 would be "3, 1x 1y 1z, 2x 2y 2z, 3x 3y 3z" Commented Aug 1, 2016 at 19:22
• The linked question uses spaces to delimit between altitudes in the same "row" and newlines to delimit "rows" of the grid Commented Aug 1, 2016 at 19:24
• Note to self; do no read challenges before going to bed. Commented Aug 1, 2016 at 21:08
• I wonder if a public text file with test cases (in the documented input format) and expected output would be useful. Perhaps in a location where – in addition to the 4 given examples – people could add more test cases which turned out to be interesting. That would allow for an automated testing of one's own and other solutions. Commented Aug 3, 2016 at 11:28
• I would suggest a relatively minor modification to the file format. Specifically, I'd use the ESRI ASCII raster format, most of which is exactly as above, but with a couple of minor changes (not always square, can be larger, added fields for location, size of each cell, etc.) The advantage is that the format is in real use, and lots of real samples are readily available (e.g., SRTM data). Commented Aug 3, 2016 at 20:50
• Oh, the other big advantage: it would be pretty easy to produce output in a format that a GIS program (e.g., QGIS) could display as a real map so you could ooh and ah over the fruits of your labors... :-) Commented Aug 3, 2016 at 21:12
• Omg someone design an esolang on this! Commented Aug 13, 2016 at 1:04
• would a corner element be a sink if its two relevant neighbors are higher than it is? Commented Aug 25, 2016 at 4:02

# CRitter Collaboration

Choose a previous community challenge and work with someone(s) to complete it.

Though interest in challenges may be high time can be scarce so this is a way to get more participation! It doesn't even have to be a community challenge as long is it's something you and others agree to work towards for the challenge period.

Definite Benefits:

1. Exercise in effective communication.
2. Getting to know fellow CRitters!
3. Experience in organization / group tasks.
4. Less time-consuming.

Possible Benefits:

1. Practice in another language.
2. Exercise in language agnostic design.
3. Using a VCS such as Git.

Room to find people to work with / discuss implementation, and plan.

• "must be something none of you have already submitted" -- I'll have to disagree on that. There's several community challenges that can be taken further. Commented Jul 10, 2016 at 0:55
• You're right. Consider it removed. The entire point is inclusion, after all. Commented Jul 10, 2016 at 19:33
• So which person would post the question?... Commented Jul 29, 2016 at 21:41
• Something to be discuss on your team! Though it's entirely reasonable to have multiple questions dealing with different modules of an overall project. Commented Jul 29, 2016 at 22:32

# Text-based version of Conway's Game of Life

## Game Rules

Rules are copied from conwaylife.com

The universe of the Game of Life is an infinite two-dimensional orthogonal grid of square cells, each of which is in one of two possible states, live or dead. Every cell interacts with its eight neighbours, which are the cells that are directly horizontally, vertically, or diagonally adjacent. At each step in time, the following transitions occur:

1. Any live cell with fewer than two live neighbors dies (referred to as underpopulation or exposure).

2. Any live cell with more than three live neighbors dies (referred to as overpopulation or overcrowding).

3. Any live cell with two or three live neighbors lives, unchanged, to the next generation.

4. Any dead cell with exactly three live neighbors will come to life.

## Implementation Requirements

1. The game should be implemented as text-based game (e.g. console application, text-based browser game, GUI with a big text field, something like that).

2. Dead cells are represented by -, living cells are represented by X.

3. The size of the game area should be configurable

4. The cells on one site interact with the cells on the opposite site (also known as Periodic Boundary Condition)

5. The initial state should be initialized randomly

• "The cells on the left side are the right neighbors of the cells on the right side and vice versa", huh? Commented Jul 9, 2016 at 13:09
• @SimonForsberg: I've tryied to improved explanation... Is it understandable now? Commented Jul 10, 2016 at 10:08