On 2021-04-03 12:07 a.m., John wrote:
The fundamental point I made up front was that reading the stuff back
and auditing it is much more difficult with complex equations in
algebraic notation than in postfix. Writing equations is only
difficult as a side effect of it being difficult to keep track of
them, which is wholly dependent on if it's difficult to read them
since you have written notes as you go along. There's a reason I
sometimes break down an equation into something that looks more like
LISP than anything else with a bunch of lines that are empty except
for an open or close parenthesis: it's the only way it's possible to
read back more than the most basic algebraic notation.
Which is all not providing any new arguments, except to rebut your
attempt to argue that I'm only thinking about how easy/hard it is to
write, as the ENTIRE POINT was readability of highly-complex equations
(for some definition of highly-complex that seems to appear really
fast). I only casually commented that it's easier to revise later
because I thought that was obvious? I do recall writing the
following:
This is a bit less ambiguous and simpler to write (and easier to read,
caveat you have to know *how* to read it) when dealing with
complicated expressions with a lot of parenthesis
Perhaps I should have been more clear than just mentioning "order of
operations" here:
From my perspective, one of these is harder to read than the other,
and no amount of carefully-placed white spaces is going to replace a
piece of scrap paper to untangle the order of operations. You can
break it down to intermediate steps, but that can make it difficult to
follow a complex calculation.
The best thing you can say for readability of infix is if it breaks
down okay, you can see parts of it, e.g. (x+6) - (3x+2) has two
components. This fails when it's like b*((x*2^(3-a))-(7*c)), since
you now have to look back and forth and get a handle on what each of
the terms is. b x 2 3 a - ** * 7 c * - * is pretty much a set of
steps (3 - a, raise 2 to that, multiply x by that, multiply 7 by c and
subtract from the former results, multiply all that by b). A quick
glance at the groups in that whole thing extracts this syntax error:
((x*2^(3-a)) …it's not a syntax error; it just stands out because of
the way the parenthesis visually group and looks wrong, just like all
the hours every programmer has spent hunting for that mismatched
parenthesis.
All of this means it's easier to add steps to the calculation, as
well, without getting out the white boards and drawing a flow chart of
your basic mathematical computation. That makes it easier to revise
later:
* While it's easier to revise complex calculations and at times more
readable, infix exists for a reason. RPN is built from the outside in
for nested computations (although often that also involves going back
and forth to add extra parenthesis while writing infix, rather than
simply typing it out left to right in one go)
And of course the other thing I said:
Visually this means I can identify each particular operation and its
relationship with the next term, then ignore it (visually track parts
that no longer matter for understanding the equation) and look at the
next parts:
1: b c f + d % e * g h - 2 / ** /
2: b ____ d % e * g h - 2 / ** /
3: b ________ e * g h - 2 / ** /
4: b ___________ g h - 2 / ** /
5: b ___________ ___ 2 / ** /
6: b [___________ _____ **] /
Along the way, I've understood each part, and its relationship with
the rest of the computation.
b/((((c+f)%d)*e)**((g-h)/2)))
The fundamental point you seem to miss is that Python code (or other
languages) is READ a hundred times as often as it is written.
Readability counts!
From my point of view, you're omitting a big factor in your readability
argument, namely that you don't *have* to use single-letter variables
and a single expression to compose your equation.
Your very long postfix equation may or may not be more readable than the
infix version with parentheses, but I'd argue that neither is more
readable than a version decomposed in bite-sized operations over
multiple statements, each using a self-documenting variable name. That,
to me, is much more readable and fits much more within the philosophy of
Python code
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/P36TJSMSDDDISZUD7NBSXY5ZH376NRZC/
Code of Conduct: http://python.org/psf/codeofconduct/
