X.Com
I’d like to give my two cents on this X conversation:
https://x.com/ScienceGuys_/status/1793278657454047610?t=iljNQofKd8oQRfNAt5ESyA&s=19
As the developer of a scientific calculator app for over a decade, I can tell you this type of conversation comes up every few years. First, let me say if you follow PEMDAS (or similar acronyms), multiplication is multiplication regardless of whether it’s explicit or implied. Both would have the same precedence. Following that, then the answer is 9.
This is how my own app is coded, along with how WolframAlpha and most other calculators (physical or otherwise) interpret the input. I also will say I haven’t received any complaints on this in over a decade.
However, PEMDAS does NOT cover everything. It’s a starting point…and leaves any more advanced operations up to the platform (i.e. Mod, nPr, etc). This is why you should always check your manual, or simply add your own clarification parenthesis if you’re unsure.
On the other hand, it’s also perfectly acceptable for a calculator to implement a higher precedence for implicit multiplication (like that older Casio)…or give the user the option in these ambiguous situations.
I choose not to, because it doesn’t follow strict PEMDAS as I mentioned, and it has other downsides. If you wanted to enter two-thirds PI squared, then you would have to press two additional keys for the parentheses (2/3)π² = 6.579 as opposed to just typing 2/3π² = 6.579
Lastly, another common option is to implement vertically integrated equations (i.e. MathML) rather than just linear ones. These remove the ambiguity, but they end up slower to use, because they force the user to spend more time arrowing around.