I've found this with the Java solutions as well. A test for Long.MAX_VALUE fails for many of the solutions and the description doesn't specify an upper limit for prod.

    @Test
    public void testMaxLong() {
        long[] r = new long[] {2971215073L, 4807526976L, 0};
        assertArrayEquals(r, ProdFib.productFib(Long.MAX_VALUE /* 9223372036854775807 */));
    }

removed => isinstance is now allowed

Alright, alright! Be patient! These things take some time.

Approved.

i added the following to the description:

If you get a frequency list with one or less elements, return null/None/Nothing, depending on your language.

Please reraise your issue.

Not gonna happen. The kata's specs are adapted from Haskell, where None is perfectly idiomatic - you can read the example tests to find out what is expected.

I'm not saying it's ideal, but in an imperfect world specs are sometimes adapted from other languages. Broaden your horizons.

Closing.

Added a clear remark about the wrapping nature, plus the "lfl" test suggested by monadius.

Thank you for addressing these.
I've mereged your fork.

Hexagoku Solver published.

Big thank you for your note! Indeed, arithmetic overflow is what I should keep in mind when I do multiplication. I rewrote my solution - replaced multiplication with division and modulo operations. Seems working for extremal cases.

Approved, thanks! 👍

Yeah, looks okay to me :)

Thanks for the Rust translation, @mjpieters. It looks okay to me and the tests pass fine, but I'm not familiar with the Rust language.

@stɛffan153, would you mind taking a look at the Rust translation to see if it's okay? If it looks good to you, I can go ahead and approve it.

BTW I've got another hexagon-based challenge coming up, so stay tuned.