Ad
  • Default User Avatar

    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

  • Custom User Avatar

    Thank you.

  • Custom User Avatar
    • Java int is 32 bit.
    • Conveniently the alphabet A-Z has only 26 letters.
    • So each letter can be represented. 'B'=bit2, 'I'=bit9, 'N'=bit14, ...- result is magic number 49796.
    • The loop just gathers them all up (in variable x) to check they are all set or not.