Bug reported by Maciej Kalisiak on the Debian BTS 6 years ago, still applies to latest xcalc:
It appears there's a horrible (in that xcalc is potentially misleading SO MANY
users with wrong results) bug in the way it does order of operations in the
"infix" mode. Consider:
The solution, if we are to follow order of operations, is +1. xcalc reports
I took a peek at the code, and the problem seems to be in math.c, in equf().
It computes the final solution by performing the remaining calculations (at
this point the multiplications have been performed and the results pushed on
the number stack) from RIGHT TO LEFT, no matter what, which is just plain
wrong. In the specific example it's computing:
Reversing the direction of the final computation is not the correct solution
When the '=' is pressed, the expression that equf() gets to evaluate, I think,
which should be done in right to left order.
Overall the mechanism for doing infix calculation in xcalc seems to be
Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.