Cooperative Zendo

[Lambda]

0.0.
1.72.34
2.771.8
0.0.0.
0.0.1.1
13.1234567890123

[DanielH]

All yes

Information

---

Initial post: http://alicorn.elcenia.com/board/viewto ... 066#p28066
SHA-1: c74602e56cdb76a3be274c76246839c4175a52cd

Yes:
(the empty string)
0.
0.0.
00.
0.0.0.
0.0.1.1
01.1
1..
1.0
10.1234567890
1.1
1.2
1.3
13.1234567890123
1.4
1.5
1.6
1.7
1.72.34
1.8
1.9
2...
2.771.8
3....
4.....
5......
6.......
6.1111..
6.183...
6.2.....
6.2111..
6.213...
6.28....
6.281...
6.2811..
6.283...
6.283..1
6.283.1.
6.2831..
6.2831.1
6.28311.
6.283111
6.284...
6.284..0
6.284..1
6.284..2
6.285...
7........
8.........
9..........

No:
.
..
...
....
.....
......
0
..0
00
000
0000
00000
000000
0.1
0.4
070
1
.1
..1
.1.
1.
10
101234567890
104
110
1.10
111
114
123
1.2.34
124
1.283...
1.333...
134
14.
1.41
1.414
1.4142
1.4142...
1.41421
1.41421.
1.41421..
1.41421...
144
154
16.283...
164
174
184
194
..2
2..
2.0
2.3
2.4
..283...
3
..3
321
3.4
340
349
3.5
4
..4
4.1
436
4.5
479
..5
..6
6..
611111..
61283...
6.2
6.2.
6.2...
625
6.28..
6.28...
6.283
6.283.
6.283..
6.283...1
6.3
6.3.
6.3...
..7
..8
829
836
858
..9
918

[Lambda]

Zero or more repetitions of ( (nonempty string of digits) . (number of characters equal to number indicated by previous digit-string) ). If this is ambiguous, please give an example of a string that it fails to assign a classification.

[Unbitwise]

I guess that the rule is: Any string which is either:

1. the empty string, or
2. the concatenation of: one or more digits; .; as many characters as the decimal value of said digits; another string accepted by this rule.

[DanielH]

I’m pretty sure those rules are equivalent except for Unbitwise specifically specifying decimal and Lambda leaving it as assumed, which I would say is valid.

My original wording:

Code: Select all

Zero or more length-dot-string sections, where "length" is a series of digits interpreted as a base-10 integer, perhaps with leading zeros, and "string" can be any sequence of characters.

I did consider letting a length of zero be omitted, but had thought this would be harder to discover. I also considered interpreting the length as some programming languages do, where a leading zero makes it (so 010.12345678 would be valid) but that had a number of problems including being much harder to guess. I also considered only having one set allowed, not arbitrarily many, but the entire point of prepending the length of a string is so you can tell how much space it’ll take up, so you can put something else after it.

Interestingly, Lambda’s was closer to my wording, but Unbitwise closer to my coding:

Python3 Classify Function

---

Code: Select all

def classify(s: str) -> bool:
    # Base case
    if not s: return True

    # Parse
    if "." not in s:
       return False
    lengthStr, body = s.split(".", 1)
    try:
        length = int(lengthStr)
    except:
        return False

    # Check
    if len(body) < length:
        return False
    else: # Perhaps multiple together
        return classify(body[length:])

[Unbitwise]

I wrote it as a recursive working-from-the-left definition because I was concerned about some “non-greedy matching” issues (getting a different number by not using all the digits) but I now see that was unnecessary.

[DanielH]

Unbitwise, Lambda has gone the time before I did. You haven’t been the master yet. Do you want to go next?

[Unbitwise]

Sure. Got an idea, writing it down…

[Unbitwise]

Allowed strings: English words (broadly defined) written using only lowercase a-z.
Initial koan: bookkeeper
Initial non-koan: witchbells
SHA-1 of rule: 79650df68be392de8cbce43a66e9f968268339b4

[Unbitwise]

(This post for clarifications in lieu of editing the preceding post.)

If people object to the English words restriction on the grounds it is too fuzzy/dependent-on-external-data I will remove it, but I think it's a fun constraint and the rule doesn't depend on it (that is, you'll never get a yes/no answer depending on the Englishness of a word, since it'll be visibly allowed or not-allowed).