Yes. bitwise-or of the modulo(remainder). It is only zero if both modulos are zero.
When using it on bools you have to be a bit careful, as (1 | 2) is 0011, and that is stored in boolean. true is 0001, so while (1 | 2) evalutes to true, it's not equal to true in some way. Here it's fine, but be aware. Negating with ! (boolean not) "normalizes" it to 0000 or 0001 though. ~ would be the bitwise not.

bitwise-or may be faster as it does not branch (both sides are always evaluated), as opposed to boolean or. But don't rely on that.

yeah it is inefficient (and unreadable). Just wanted to make it weird

I agree that it was quite difficult to understand. It only really made sense to me once I looked up chords in circles on wikipedia.
Other that, I like the approach of this kata, to not force me to use a specific algorithm, but instead throw this equation at me and let me decide how I want to solve it.

And actually, the test is not even an edge-case which causes weird floating point rounding in typical implementations. The test-case is actually simply wrong:

w = 86.7000000000000028421709430404007434844970703125
h = 1.6999999999999999555910790149937383830547332763671875

so w>86.7, h<1.7, so w/(h* h) > 86.7/(1.7^2) = 30. So Obese is actually correct, given the input.

Unexpectedly, I've done it now already.
The changes break all current solutions, now longer require a reference-solution during testing, and the reference-solution is now my public solution.

I've republished it and marked this issue as resolved. I hope that I addressed the issue well enough.

EDIT: After writing this comment, I found another weakness in my solution, that is, if the function diverges first in a close range around the pole, and only starts converging quite late. I added it as a test, and adjusted my algorithm so it can deal with it. With all these extra cases, the kata does seem to get quite hard, especially because of potential rounding errors. I'd be glad if you'd give it another shot.

You are probably right.

The reference-solution used in the tests is "more correct". I've published the kata before with that solution (which still had flaws at that time though), and it just got copied and posted as the solution. The visible solution is imperfect on purpose.

Anyways, the criticism is valid, and I should probably engineer some test-cases that expose hacky solutions like that one.
I've disabled the kata for now and will only activate it again if i get some time to engineer those test-cases.

I made this kata, and this looks a lot like my solution.
Did you somehow base this on mine? Or were you forced to do so due to some weird edge cases that require exactly this solution (since I compare results to mine)?

If this came to you naturally, then I guess the description and tests work as intended, but since it is too similar I am not sure if there is a mistake on my side. If so I'd like to improve it. If I have the time for it I might try to remove my reference solution from the tests altogether to avoid any chance of this issue.

Any other feedback (and rating) is also welcome.

Thanks!

EDIT: After having a second look, it seems to contain the same bug that my solution had initially. Wasn't an issue due to relatively low precision requirements, but I guess that answers my question.

Doesn't this read out of bounds (in front of the string) if ending is longer than str?