For starters: I don't find it more readable. Additionally: code formatted like that cannot be formatted easily using an IDE. When I would refactor the name of the remove char function to RemoveCharAt, I'd have to manually reformat that code to get everything aligned. No problem for a tiny kata, but bound to result in very ugly code in big projects.

Heh, I think you're right about that. The second part of the concatenation is incorrect. good catch!

thank you 😁

Thanks for your comment.
Really cool to read that the code sparked an idea for you.
Have a merry, code-y Christmas!

A blind guess would be that the error stems from the use of Seq.reduce, which needs to start out with the zero-value of the type at hand. For an integer, that would be 0. However, because of the code before the reduce call, the type might only be known as IComparable, and the zero value cannot be derived from that.
That's what I think when I see the error message. I only did F# during a holiday a while back, so it's not up front knowledge to me, but I hope this helped in some way.

Like it says right at the start of my comments: "It was a fun journey, even though it feels like I took the long way."

Believe me, I had a big laugh at myself after solving the puzzle using this route. I decided to type out the scribbles that I had on paper into the comments, just in case it might put a smile on other peoples faces too ;-)

Thanks! :)

Yes, I agree on that. I opt for staying close to intent and optimize when needed.  But as long as you know the function exists, I'm happy ;)
Cheers!

Yes, you're absolutely right! My code is wrong.
I remember being a bit annoyed by the opinionated tests, so I might have taken a shortcut there.
That's a sin of course, sorry for that ;-)

At a glance, the two things that might be the issue here are:

• Not clamping my regular expression with ^......$, making my regular expression a check to see if an IP-adres is somewhere within the provided string, instead of checking that the full string is following the IP-address format. That is what makes 07.1.1.1 valid, since the 0 is ignored by the regex.
• making the number format [1-9]\d{0,2}, which says that the first number in an octet should always be 1 - 9. That is what breaks 127.0.0.1 here, since that one shows that a 0 is a perfectly fine number as well.
• I can't really explain 08.1.1.1 right now, but I'll create a new iteration in a minute, in which I test that case as well.

Thanks for your comment, much appreciated!

Though this is a sensible and elegant algorithm, I would not qualify it as especially fast, as the title suggests.
It definitely is fast enough for small primes, but try running this one for example:

Test.expect(isprime(1734822086675357441), "1734822086675357441 is prime")

Here an output of the timing for this test on my machine:

$ time python3 kumite-quick-prime.py
1734822086675357441 True

real    1m24.664s
user    1m24.610s
sys     0m0.010s

I wrote up an alternative version, which is able to produce output pretty fast for larger numbers as well.
Here the timing of an example run using this code:

$ time python3 kumite-quick-prime.py
1734822086675357441 True
1734822086675357442 False
1734822086675357443 False

real    0m0.038s
user    0m0.030s
sys     0m0.000s

So let's say that there is room for improvement ;-)

Kind regards,
Maurice

Ah, I forgot to remove firstUnsolvedFieldOf(), that one wasn't needed anymore.