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! On Fri, Apr 2, 2021 at 11:33 PM David Mertz <me...@gnosis.cx> wrote: > > On Fri, Apr 2, 2021, 10:52 PM John <john.r.mo...@gmail.com> wrote: >> >> Study was in calculators, yeah. >> >> https://vdocuments.mx/electronic-calculators-which-notation-is-the-better.html > > > So in 1980, accountants using ticker tape calculators found suffix syntax > less error prone?! > > The fundamental point you seen to miss is that Python code (or other > languages) is READ a hundred times as often as it is written. Readability > counts! > > A ticker tape accounting calculator is almost by definition "write only" > (yes, technically tapes can be reviewed... But even when they are, it is > almost always for individual numbers being correct, not for algebraic form of > combinations). > > There's a reason that every beginning algebra class throughout the world uses > infix notation, and has for 200 years (perhaps with a small exception of > Poland in the 1920s). Heck, there's even a reason why when John McCarthy > introduced S-expressions in 1958 it was with a promise to flesh out > M-expressions as a more readable variant (albeit, that never really happened, > Dylan programming notwithstanding). > > The main reason that RPN is useful on ticker tape adding machines isn't > really the postfix per-se. It's that the most common operation is implicit > commutivity of many numbers (more than 2) under addition. I.e. add all these > 20 receipts together without needing 19 "+" signs, but just one at the end. > > It doesn't seem to be in the original proposal, but I suppose Python could do > that too. But it's a terrible idea to try. > > We have the 'sum()' function which covers 98% of the actual advantage of RPN > in a bookkeeping context. _______________________________________________ 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/WBQFXMPC722DOIUDJ3NE7E3HV7FRFYUU/ Code of Conduct: http://python.org/psf/codeofconduct/
