You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recurring monthly meetups are generally scheduled on the given weekday of a given week each month.
4
+
In this exercise you will be given the recurring schedule, along with a month and year, and then asked to find the exact date of the meetup.
4
5
5
-
Typically meetups happen on the same day of the week. In this exercise, you
6
-
will take a description of a meetup date, and return the actual meetup date.
6
+
For example a meetup might be scheduled on the _first Monday_ of every month.
7
+
You might then be asked to find the date that this meetup will happen in January 2018.
8
+
In other words, you need to determine the date of the first Monday of January 2018.
7
9
8
-
Examples of general descriptions are:
10
+
Similarly, you might be asked to find:
9
11
10
-
-The first Monday of January 2017
11
-
-The third Tuesday of January 2017
12
-
-The wednesteenth of January 2017
13
-
-The last Thursday of January 2017
12
+
-the third Tuesday of August 2019 (August 20, 2019)
13
+
-the teenth Wednesday of May 2020 (May 13, 2020)
14
+
-the fourth Sunday of July 2021 (July 25, 2021)
15
+
-the last Thursday of November 2022 (November 24, 2022)
14
16
15
-
The descriptors you are expected to parse are:
16
-
first, second, third, fourth, fifth, last, monteenth, tuesteenth, wednesteenth,
17
-
thursteenth, friteenth, saturteenth, sunteenth
17
+
The descriptors you are expected to process are: `first`, `second`, `third`, `fourth`, `last`, `teenth`.
18
18
19
-
Note that "monteenth", "tuesteenth", etc are all made up words. There was a
20
-
meetup whose members realized that there are exactly 7 numbered days in a month
21
-
that end in '-teenth'. Therefore, one is guaranteed that each day of the week
22
-
(Monday, Tuesday, ...) will have exactly one date that is named with '-teenth'
23
-
in every month.
19
+
Note that descriptor `teenth` is a made-up word.
24
20
25
-
Given examples of a meetup dates, each containing a month, day, year, and
26
-
descriptor calculate the date of the actual meetup. For example, if given
27
-
"The first Monday of January 2017", the correct meetup date is 2017/1/2.
21
+
It refers to the seven numbers that end in '-teen' in English: 13, 14, 15, 16, 17, 18, and 19.
22
+
But general descriptions of dates use ordinal numbers, e.g. the _first_ Monday, the _third_ Tuesday.
23
+
24
+
For the numbers ending in '-teen', that becomes:
25
+
26
+
- 13th (thirteenth)
27
+
- 14th (fourteenth)
28
+
- 15th (fifteenth)
29
+
- 16th (sixteenth)
30
+
- 17th (seventeenth)
31
+
- 18th (eighteenth)
32
+
- 19th (nineteenth)
33
+
34
+
So there are seven numbers ending in '-teen'.
35
+
And there are also seven weekdays (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday).
36
+
Therefore, it is guaranteed that each day of the week (Monday, Tuesday, ...) will have exactly one numbered day ending with "teen" each month.
37
+
38
+
If asked to find the teenth Saturday of August, 1953 (or, alternately the "Saturteenth" of August, 1953), we need to look at the calendar for August 1953:
39
+
40
+
```plaintext
41
+
August 1953
42
+
Su Mo Tu We Th Fr Sa
43
+
1
44
+
2 3 4 5 6 7 8
45
+
9 10 11 12 13 14 15
46
+
16 17 18 19 20 21 22
47
+
23 24 25 26 27 28 29
48
+
30 31
49
+
```
50
+
51
+
The Saturday that has a number ending in '-teen' is August 15, 1953.
Copy file name to clipboardExpand all lines: exercises/practice/sgf-parsing/.docs/instructions.md
+52-21Lines changed: 52 additions & 21 deletions
Original file line number
Diff line number
Diff line change
@@ -2,12 +2,14 @@
2
2
3
3
Parsing a Smart Game Format string.
4
4
5
-
[SGF](https://en.wikipedia.org/wiki/Smart_Game_Format) is a standard format for
6
-
storing board game files, in particular go.
5
+
[SGF][sgf] is a standard format for storing board game files, in particular go.
7
6
8
-
SGF is a fairly simple format.
9
-
An SGF file usually contains a single tree of nodes where each node is a property list.
10
-
The property list contains key value pairs, each key can only occur once but may have multiple values.
7
+
SGF is a fairly simple format. An SGF file usually contains a single
8
+
tree of nodes where each node is a property list. The property list
9
+
contains key value pairs, each key can only occur once but may have
10
+
multiple values.
11
+
12
+
The exercise will have you parse an SGF string and return a tree structure of properties.
11
13
12
14
An SGF file may look like this:
13
15
@@ -17,24 +19,32 @@ An SGF file may look like this:
17
19
18
20
This is a tree with three nodes:
19
21
20
-
- The top level node has three properties: FF\[4\] (key = "FF", value = "4"), C\[root\](key = "C", value = "root") and SZ\[19\] (key = "SZ", value = "19").
21
-
(FF indicates the version of SGF, C is a comment and SZ is the size of the board.)
22
-
- The top level node has a single child which has a single property: B\[aa\].
23
-
(Black plays on the point encoded as "aa", which is the 1-1 point).
24
-
- The B\[aa\] node has a single child which has a single property: W\[ab\].
22
+
- The top level node has three properties: FF\[4\] (key = "FF", value
23
+
= "4"), C\[root\](key = "C", value = "root") and SZ\[19\] (key =
24
+
"SZ", value = "19"). (FF indicates the version of SGF, C is a
25
+
comment and SZ is the size of the board.)
26
+
- The top level node has a single child which has a single property:
27
+
B\[aa\]. (Black plays on the point encoded as "aa", which is the
28
+
1-1 point).
29
+
- The B\[aa\] node has a single child which has a single property:
30
+
W\[ab\].
25
31
26
-
As you can imagine an SGF file contains a lot of nodes with a single child, which is why there's a shorthand for it.
32
+
As you can imagine an SGF file contains a lot of nodes with a single
33
+
child, which is why there's a shorthand for it.
27
34
28
-
SGF can encode variations of play. Go players do a lot of backtracking in their reviews (let's try this, doesn't work, let's try that) and SGF supports variations of play sequences.
29
-
For example:
35
+
SGF can encode variations of play. Go players do a lot of backtracking
36
+
in their reviews (let's try this, doesn't work, let's try that) and SGF
37
+
supports variations of play sequences. For example:
30
38
31
39
```text
32
40
(;FF[4](;B[aa];W[ab])(;B[dd];W[ee]))
33
41
```
34
42
35
-
Here the root node has two variations.
36
-
The first (which by convention indicates what's actually played) is where black plays on 1-1.
37
-
Black was sent this file by his teacher who pointed out a more sensible play in the second child of the root node: `B[dd]` (4-4 point, a very standard opening to take the corner).
43
+
Here the root node has two variations. The first (which by convention
44
+
indicates what's actually played) is where black plays on 1-1. Black was
45
+
sent this file by his teacher who pointed out a more sensible play in
46
+
the second child of the root node: `B[dd]` (4-4 point, a very standard
47
+
opening to take the corner).
38
48
39
49
A key can have multiple values associated with it. For example:
40
50
@@ -44,9 +54,30 @@ A key can have multiple values associated with it. For example:
44
54
45
55
Here `AB` (add black) is used to add three black stones to the board.
46
56
47
-
There are a few more complexities to SGF (and parsing in general), which you can mostly ignore.
48
-
You should assume that the input is encoded in UTF-8, the tests won't contain a charset property, so don't worry about that.
49
-
Furthermore you may assume that all newlines are unix style (`\n`, no `\r` or `\r\n` will be in the tests) and that no optional whitespace between properties, nodes, etc will be in the tests.
57
+
All property values will be the [SGF Text type][sgf-text].
58
+
You don't need to implement any other value type.
59
+
Although you can read the [full documentation of the Text type][sgf-text], a summary of the important points is below:
60
+
61
+
- Newlines are removed if they come immediately after a `\`, otherwise they remain as newlines.
62
+
- All whitespace characters other than newline are converted to spaces.
63
+
-`\` is the escape character.
64
+
Any non-whitespace character after `\` is inserted as-is.
65
+
Any whitespace character after `\` follows the above rules.
66
+
Note that SGF does **not** have escape sequences for whitespace characters such as `\t` or `\n`.
67
+
68
+
Be careful not to get confused between:
69
+
70
+
- The string as it is represented in a string literal in the tests
71
+
- The string that is passed to the SGF parser
72
+
73
+
Escape sequences in the string literals may have already been processed by the programming language's parser before they are passed to the SGF parser.
74
+
75
+
There are a few more complexities to SGF (and parsing in general), which
76
+
you can mostly ignore. You should assume that the input is encoded in
77
+
UTF-8, the tests won't contain a charset property, so don't worry about
78
+
that. Furthermore you may assume that all newlines are unix style (`\n`,
79
+
no `\r` or `\r\n` will be in the tests) and that no optional whitespace
80
+
between properties, nodes, etc will be in the tests.
50
81
51
-
The exercise will have you parse an SGF string and return a tree structure of properties.
52
-
You do not need to encode knowledge about the data types of properties, just use the rules for the [text](http://www.red-bean.com/sgf/sgf4.html#text) type everywhere.
0 commit comments