Problem-specifications: connect: update readme to clarify that not all games are "fair"

[kytrinyx]

Excerpt from @khoguan's post in the Scala track repository (https://github.com/exercism/xscala/issues/107):

---

In the exercise "Connect", the 4th test case is:

test("convoluted path") {
    val lines = List(". X X . ."
                    ," X . X . X"
                    ,"  . X . X ."
                    ,"   . X X . ."
                    ,"    O O O O O")
    Connect(mkBoard(lines)).result should be (Some(Color.Black))
  }

There are 9 X's but only 5 O's. Then the X player (Black) must have cheated! A cheater should not win.

The 5th test case is:

test("rectangle - black wins") {
    val lines = List(". O . ."
                    ," O X X X"
                    ,"  O X O ."
                    ,"   X X O X"
                    ,"    . O X .")
    Connect(mkBoard(lines)).result should be (Some(Color.Black))
  }

There are 8 X's but only 6 O's. The player X must have cheated. In addition, there are 5 rows but only 4 columns. The numbers of the rows and the columns should be the same to be fair for the two players. The 6th test case has the same problem with 5 rows but 4 columns:

 test("rectangle - white wins") {
    val lines = List(". O . ."
                    ," O X X X"
                    ,"  O O O ."
                    ,"   X X O X"
                    ,"    . O X .")
    Connect(mkBoard(lines)).result should be (Some(Color.White))
  }

---

This likely affects Go, Haskell, PHP, and Scala, who have implemented this exercise.

Once we've figured out what the right answer is, we can write up an issue that explains the problem in-depth, along with the proposed solution. We can then post this to all of the affected language track repositories at once using the https://github.com/exercism/blazon tool.

/cc @ricemery who also participated in the discussion there.

[Insti]

1) In piece placement games like this it is common when playing young/beginner players to give them an extra n pieces at fixed positions on the board, so mismatched piece counts could still occur in an otherwise fully legal game.

2) This exercise is about working out if there is a winning connection between the sides of the board, it is not interested in any other state of the game such as who moved where when, or whose turn it is.

3) @jonatas has recently created the common test file for this problem: https://github.com/exercism/x-common/pull/297 which includes these cases and the general consensus seemed to be that these cases were appropriate.

For these reasons I would argue that the test cases listed above are all correct, there are no further modifications required, and this issue can be closed.

[petertseng]

I agree that the games pointed out are unfair in some way or another.

I don't feel it is imperative to change the test cases since there may be legitimate reasons for the unfairness (giving a handicap) and the exercise only cared about determining a winner of a game which may have a variety of parameters (board lengths, extra pieces).

Pretty much I'm saying the same things that have already been said.

As for how this applies to this issue: I would see "close and take no action" as acceptable.
I would not object to modification of all tests to make all games fair, of course, but I don't care enough to do it myself.

[Insti]

I would object to modification of all tests to make all games fair, and care enough to argue about it.

[khoguan]

It's OK that you keep all tests intact. But I'd like to suggest that extra note, which says that unfair games are somehow normal in the test cases, be added in README.md so that future code newbies will not be puzzling over them like me.

[kytrinyx]

Let's go with @khoguan's suggestion of updating the README to talk about the contexts in which unequal games make sense.