Backstory: I've been programming an RPN calculator for a long while now; recently, due to countless memory leaks and poor optimazions, I had to rewrite it from the ground up. If you do not know how an RPN calculator works, it's fine for this post.

Pitfall:


What you need to know is that ʟRPNR(1 is a value that is normally 0, but it could be other values, too. And these functions grouped together only affect that specific variable. And the letter variable "R" denotes whether no prior key, 2nd, or Alpha has been pressed beforehand.

Why it is a pitfall: Default value is 0; doing e^(, sin(, cos(, or even tan⁻¹( on that value would cause a Divide by 0 error. Same concept applies for some other values out side of one function's domain(s).

Thanks for letting us know

What? You want me to remove the thread?

We are just slightly confused as to what this post is for. The rather clickbaity title makes it seem like the problem is a bigger deal than it is. This seems like a problem with your specific implementation, rather than "the biggest coding pitfall ever". It's also unclear as to whether you are asking for help or just complaining.

If I were writing this, I probably would have used expr( or eval( (I can never tell them apart). I would have listed operators by number of arguments and the operator ordering (e.g. whether it's a+b or f(a,b)). Then, I would generate a string, probably something like A(token)B or (token)A,B, and evaluate it. That way you only calculate the operators you want to run rather than all of them each keypress.

It's not really a big deal; I did it for the lolz.
commandblockguy, I'll look into what you mentioned.
If threads like these are frowned upon by the community, I will not post another like this. (Sorry)

I'm a little lost,
but I liked it ShinyGardevoir