Haha, seems correct 🙈

fn main() {
    let string = std::fs::read_to_string("string.txt").unwrap();
    let time_before = std::time::Instant::now();
    // Benchmarked block
    {
        let answer = arrow_search(&string);
        println!("Answer: {}", answer);
    }
    println!("Elapsed time: {:.2?}", time_before.elapsed());
}

I wasn't actually very experienced at this stuff, so I used plain std::time and manually ran the code multiple times to check the variance. Benchmarking println!("Answer: {}", answer); looks very weird, but I probably didn't know about black_box and needed to make sure that the code actually did the work.

I don't remember why I saved a fixed generated string to disk. I don't have the code that generated it, but I still have string.txt. It looks like it was the same b".-=<>".choose(&mut rng), but 10 MB in size rather than 1 KiB.

On my current machine, here are the timings from this bench:

• My regex solution: 29.35s
• My table solution: 347ms
• Your solution: 223ms

The speedup is still 84x, even though I'm on a different machine now

Yep, I agree that it should be (u32, u32)

To see your solution, I have to complete tha kata in the same language as you. And since I do not know your language... I would have to complete the kata in three languages to see your solution. And I know only one of them. So I have to solve the kata in two languages which I do not even know to see your solution. I wold have to use a lot of google and a lot of reading to solve it. The kata is 5 kyu, which means not easy. I would have to solve a non-trivial kata in three languages, including two languages which I do not know.

But the "unlock solutions" button exists. The whole paragraph is incorrect. Although I agree that the OP could be nicer and at least mention the language from the start.

Look, we can be sure that the "remaining defending power" of d is 4-2=2. The rule about "more points than usual" means that if it was greater than d's usual power (2), we would need to bring it down to 2 before attacking. In this case, it's not greater, so the remaining power stays unchanged and the rule doesn't really change the outcome. Similarly, if sss were attacking, the remaining power of d would stay at 1. That rule makes a difference in cases like attack from a single s. The "remaining defending power" of d would be 4-1=3, but the attacking potential of d is limited at 2.

Any ideas about how I can shortly express this in the description?

Hi, thanks. Looks good to me. Submit it here (so that you get the credit) and I'll accept it

The description should mention that menu items must be displayed using repr(), not str().

For example, "a" must be displayed as 'a', not as a

You mean "If it survives, then that's enough of advantage"? Added that to the C version. Later I'll do renaming/minimization as discussed

Added this to fixed tests

As I think more about it, I think I'd prefer to edit the sample tests instead of bloating the description. Minimal examples don't really need a step-by-step walkthrough, as they only consist of 1-2 steps. What if I just minify the sample tests and give them descriptive names that directly reference the tested mechanic? For example, I'd turn

    @test.it("They never leave the trench")
    def they_never_leave_the_trench():
        check_solution("     s\n"
                       "mmmm|-",
                       "RRRR|L")

into

    @test.it("Should not attack from the trench")
    def should_not_attack_from_the_trench():
        check_solution("  s\n"
                       "m|-",
                       "R|L")

Would that be enough?

Done. I also suggest adding one of the failing cases as a fixed test. Cound you print it (then maybe reduce to a minimal reproducible example) and post it?

Which mechanics would you like to be covered in a walkthrough?

• Joining forces when entering the trench?
• Joining forces again after a successful attack?
• Equal power between defender and attackers?
• The first letter in the trench attacking with "no more points than usual"?

Other cases seem to be already covered.

I've edited the description. Let me know if the issue is resolved or suggest how I should improve it further.

if letters join attack force on the ground, will they be split up again once they start going into trenches?

No. Old wording: "attackers [...] continue to attack or join forces with allies. This includes going from the ground deep into the trench". This was hidden under "If defending letter has less power than the attacking letters", so I've extracted the last sentence and merged it into the general rule about never leaving trenches: "While joining forces or attacking, letters can stay on the same level or go down into a trench, but they never leave trenches. They stop at the right end of the trench, and the next letter on the ground starts a new chain of attacks".

if a defender defeats an attacking letter in the trenches, will any other attacking letter to the left of the defeated letter start attacking the defender, or will we proceed from the defending letter to the right?

All letters to the left will attack. In my mental model, this is a single attack by a group that has joined their forces beforehand. Added rule that enforces the "beforehand" part: "Letters act in order, from left to right".

attacking group enters trenches, and there are some of their own in there .. can they ally?

Yes. See my first answer for references.

should those troopers in the trenches attack first, one by one, before the entering troops attack the remaining enemy forces in the trenches?

No. Letters to the left of the trench should act first, i.e. enter the trench. Added rule that enforces this: "Letters act in order, from left to right".

Hmmm, you're right. Apparently, I didn't check the initial solution before posting this. I've encountered that error because I added an export list (probably copied it from sample tests' imports). Export lists play nicely with IDEs. For instance, they allow me to "rename symbol" in VSCode. I suggest adding one

u32 is the smallest appropriate type, given the size limit in the description. This reasoning and choice seems fine to me. usize is also fine.