At 2025-09-17T15:58:45-0400, Mark Manning wrote: > But I have been wrong before and probably will be again.... > > In man 5 terminfo for the documentation for the "+-%*/" format specifiers > your documentation says these are all push(pop op pop). > This implies something like the following... > pop A, > pop B, > push (A op B)
Let's see. What does terminfo(5) actually say?
terminfo(5):
%+, %-, %*, %/, %m
arithmetic (%m is mod): push(pop() op pop())
So I would not say "+-%*/" but "+-m*/". The percent sign is a prefix,
suspiciously reminiscent of printf(3) conversion specifiers.
> which I believe to be wrong. I say this because I am writing my own
> curses library (not a replacement for ncurses) and my code for parsing
> the %/ specifier for example is as follows...
> n2 = fs_pop();
> n1 = fs_pop();
>
> (n1 != 0)
> ? fs_push(n1 / n2)
> : fs_push(0);
>
> Which works in every terminal I use it in. Reverse the order of the
> operation and it does not work anywhere. The same happens when I
> reverse the order of operations with the other specifiers documented
> here..
>
> Pop B
> Pop A
> Push(A op B)
>
> works push (B op A) messes things up greatly
I've run into ambiguities like this when studying stack-based languages
like Forth.[1] It appears to be a convention in applied computer
science that, even if a mathematical expression notation is explicitly
identified as "reverse Polish" (RPN),[2] operands to binary operators
are pushed onto the stack in the "wrong" order so that when the
expressions are read left-to-right, their expected values align with
those of traditional algebraic notation for humans. (This matters only
for non-commutative operators, of course.)
I've never before seen anyone else complain about this; I figured I was
uniquely perverse in assuming that the multiplier or divisor would or
should occupy a position in the stack closer to the top than the
multiplicand or dividend.
Because not everybody who reads terminfo(5) is necessarily going to be
familiar with this IMO under-documented convention in arithmetic
expression evaluators,[3] a sentence could perhaps be added to the man
page. Maybe I can work something up.
Regards,
Branden
[1]
https://www.forth.com/starting-forth/2-stack-manipulation-operators-arithmetic/
[2] http://h20331.www2.hp.com/Hpsub/downloads/35_02_RPN_Mode.pdf
[3] I've never actually seen an arithmetic evaluator that _wasn't_
stack-based, but many use a somewhat more complex implementation to
support the PEMDAS rules of schoolhouse arithmetic because that is
what is familiar to almost all casual users.[4] On the other hand,
a generation or two of EEs swore by their HP 48 calculators
_because_ RPN is simple and elegant.
[4] These sometimes get called "algebraic" evaluators in contrast to
"stack-based" ones; you can see that both are abuses of terminology.
Even people who have had a semester of linear algebra and therefore
should know better seem to speak as if there exists only one
algebra. There are many algebras, just as there are many logics.
Subscribe to my "Complaining about Mathematics Education"
podcast![5]
[5] I have no podcast.
signature.asc
Description: PGP signature
