3 ms·
I'm not following here - if it is not a typo, why would you expect someone to solve a+b here? But if we are using calculators, then depending on the make and m
by mannykannot 5y ago
I'm not following here - if it is not a typo, why would you expect someone to solve a+b here?
But if we are using calculators, then depending on the make and model, you might do a b * c d * +, Which achieves the goal your second paragraph is aiming for: getting rid of (or at least abstracting away) any explicit use of incidental or intermediate state (which takes the form of memory operations in conventional calculators.)
RPN calculators (and programming languages), however, never became popular, and I strongly suspect that is because their expressions are often objectively harder for humans to comprehend, no matter how elegant RPN seems.
- qsort 5y agoIt's a typo, I meant a * b. I agree on RPN, that was the point I was trying to make. RPN is more powerful, but is stateful and uses a rather complicated and unintuitive form of state (a stack). In my experience it's not true that people find it more intuitive to work with arbitrary mutable state of the kind imperative programming languages traditionally have.