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