removed

The description addresses this scenario:

Given an expression, figure out the value of the rune represented by the question mark. If more than one digit works, give the lowest one.

yeah that's pretty crappy tbh, I basically had to write two solutions because it wasn't clear from the description that BigInteger wasn't allowed.

It made it a more interesting problem without BigInteger, so I'm not complaining about that, but it should definitely say "no BigInteger" up-front.

same problem

Regarding the probability of encountering this negative number case:

I hope my math is right here; my probability studies were about 30 years ago. Note that all of my decimal numbers are approximate. For the random floating point numbers in [0,1], the probability of one of them causing a result of e^(44*x) that does NOT exceed the maximum long value is 43.668 / 44 == 0.9925 (i.e., 99.25%). The probability that all 200 random generated numbers were in [0,2^63] (i.e., none of them exceeded 2^63, the maximum long value) is therefore 0.9925^200 == 0.22, or about 22 percent. In other words, there is a better than 3/4 case that the c# and java translations were fed negative numbers in any given test-submission. This seems intuitively correct and IMHO warrants my surprise that we didn't see this sooner.

BTW, should be fixed now.

Thanks for your interest in this kata. I believe that I've isolated the issue and I'm surprised this didn't manifest itself sooner. This should be a problem for both c# and java. To share the diagnosis of the problem, the random test uses the following expression to generate a wide range of 64-bit numbers:

java

  long n = (long)Math.exp(44 * Math.random());

c#

  long n = (long)Math.Exp(44*rnd.NextDouble());

The challenge is in the expression e^x; when x > approx 43.67, e^x will exceed a signed 64-bit integer and wind up generating negative input. Oops! I haven't verified whether this is a problem for javascript as well; however, I would like these to use the same data generation algorithm (and therefore the same range of input data), so I will drop each from 44 to 43 to maintain the same range of input data.

BTW, I calculated the 43.67 number by taking the natural log of 2^63. So, 43 should push us close to the range of a long without the magnitude forcing a cross-over into negative numbers.