LOL that is the truth! XD Most of the tests pass but the ones with extremely large numbers are returning smaller values than expected. I am scouring my code to find where any number might be cast to a type that is truncating it. Still no luck. I shouldn't be running into any problems with the coefficients or exponents themselves. I would have thought that the too-big-for-types would only crop up when solving for x. Maybe I am wrong about that or maybe there is a long somewhere that is implicitly casting one of the results that I have when using BigInteger. It's late. I'm tired. I'll poke at it tomorrow. I am super happy that the code is working fine for all test cases that don't try to return the size of the cosmos in cubic milliliters. XD

Edit (next day): Yup yup! I found that I had one long in my calculation that was implicitly casting a subcalculation to the maximum value of a long. Swapped that to a BigInteger and it's working like a champ now... but I am getting errors (mine, not with the kata) on resolving a "-" that is being passed in with no context. lol That is a problem I'd much rather be working out than digging for casting problems. XD

Actually IntStream.of() calls Arrays.stream()
From IntStream.java :

<...>
/**
 * Returns a sequential ordered stream whose elements are the specified values.
 *
 * @param values the elements of the new stream
 * @return the new stream
 */
public static IntStream of(int... values) {
    return Arrays.stream(values);
}
<...>

Is this solution better than solution with Arrays.stream()?

A.I.

nice

^this plus

what if map changes? you have to analyse every field one by one

booooring

Thank you.

boooooooooooooooooring

how come everyone's multiplications didn't time out. I had to come up with golden ratio solution which will certainly fail for lower n's...

me too that's interesting

Nice, however var i could be moved to for loop.

I like it!

For Java:
Use BigInteger everywhere