MathCookie17

This probably comes from the way break_eternity handles negative exponents in strings. To ensure that, say “(e^100)-1” can be written to mean the reciprocal of “(e^100)1” (because that’s more useful...

About your first point: 10^^1e308 is an example of tetration, which is pretty much the defining feature of this library - I feel it can be safely assumed that users...

Note: This is not resolved. I mentioned the issue in that pull request as an example of why I wanted to make ssqrt not rely on lambert-w; all I did...

Okay, NOW this one's resolved.

This is not a bug - at least, I don’t think it is. Interpreted correctly, “ee-9996” would just be 1, as it’s so close to 1 that break_eternity wouldn’t be...

I'm not sure if this one is fixable. Floating point numbers are naturally going to be somewhat imprecise - it's like how 0.1 + 0.2 = 0.3000000000000001. break_eternity implements pow...

> wouldnt a valid fix be to just round the values if both the exponent and base are integers (and final val < 9e15). Not the cleanest solution, sure, but...

> n is a integer _very slightly_ larger than floor(n), so that n != floor(n) That doesn't make sense. floor(n) is always equal to n when n is an integer.