aebletrae

Shouldn't you be more wary of the unexpected, Redshirt?

Are other lines in .profile being executed, or is the whole file ignored? Have you logged out and in again since adding these lines?

Aren't hiragana and katakana named that because they're both modifications of kanji—katakana by taking parts, and hiragana by smoothing out—with ka (か/カ from 加), se (せ/セ from 世), ni (に/ニ from 仁), he (へ/ヘ from ヘ), and ya (や/ヤ from 也) demonstrating the similarity?

And does the history matter to kids who just have to accept that G and g or ぢ and ヂ, however differently shaped, both make a "jee" sound, and end up switching so naturally that they don't even think about it, even as they think the other pair is weird?

Mixing capitals, little letters, and numerals—I see what you did there. :janet-wink:

Ah, Enhanced, the folks that brought us interrogation.

Having thought about this some more with practicality and clarity thrown out the window in favour of abstractions, how about this?

A game is a sequence of moves. Past moves are immutable, future moves unknowable; a singly linked list fits the bill here.

Each move consists of a player token and a position. The position might ordinarily be thought of as a grid index but, as you point out, it could just as well be membership in one of the potentially winning lines. Either a move is part of one of these lines or it isn't. This makes the position equivalent to a bit field. If each potential win line is distinct, they could indeed be held sparsely in a set.

Checking for a win then consists of counting player tokens for each potential win line and checking for crossing the necessary threshold. Filter, sum, max, greater than?, any?

I think this scheme would be applicable to arbitrary game boards, with none of it requiring mutation. Is that the kind of thing you were after? The reflection/rotation equivalence isn't present here, but I still think that's more an artefact of analysis, rather than a property of gameplay.

2. The ordering of each row should not matter.

This is true for your abstracted rows, but is maintaining eight sets of three square states, two or three of which must be updated with every move, really a better model than a single sequence of nine, where only one needs to change at a time? It's more complex to think about, and is less efficient to update. When you throw in steps to canonicalize the rotation and reflection, which may produce different transformations from the input/output grid on the first three moves, you may need to change even more set items with each move.

It's true that, mathematically, the mapping from grid to sequence is arbitrary and the only thing that matters is consistency, but if you view programming languages as a way to communicate with humans, then clarity of purpose, rather than mathematical idealism, should be your goal. Use a nine-item array or a three-by-three nested array for the underlying storage and treat your eight win-checking sets as views into that more ordered structure. These views could well be functions that return a set and are themselves held in a set to be applied in any order. Similarly, treat canonicalization as another way to view the underlying board.

You could sidestep the mutable borrowing by not mutating individual squares. Take a leaf from the functional-programming books and use a function that takes a board and a move and returns an entirely new board. Or takes a board and returns one of the abstracted row sets. There are only nine squares and nine moves. The win-checking views aren't needed before move six. A bit of copying isn't going be a problem.

I thought perhaps :kim-jong-gun:.

He should get those injuries checked out. No need to bother with an ambulance though; just call him a cab.