Reverse polish notation
It occurs to me it's a syntax error everywhere to put two potentially-calculable terms in a row with nothing between them, e.g.: ```python a = b c mylist = [x 6 for x in y if "a" in x] ``` Unless I'm missing something, this makes it relatively easy (from a syntax perspective; writing a parser r hard) to detect such: ```python a = b c 6 ** + 5 / mylist = [x 6 + for x in y if "a" in x] ``` 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—a use case I automatically want to dismiss despite always running into this immediately. ```python # tl counts from sleep_us() print(" Iteration: %s\t Correct: %s of 10 (%s/sec)" % (i,c,1000/(tl/(1000*i)) if tl > 0 else 0)) # RPN print(" Iteration: %s\t Correct: %s of 10 (%s/sec)" % (i,c, 1000 tl 1000 i * / / if tl > 0 else 0)) ``` I took the following steps in writing this: * 1000 / * 1000 tl / / * 1000 tl 1000 i * / / The first is the incomplete operation 1000 / <something> The second adds the divisor between the term (1000) and the operator (/), which is again going to be tl / <something>. The third adds the divisor there, 1000 * i, between tl and its operator. Reading it back is easy enough: scan until finding an operator and take the two terms to the left, e.g. u=(1000*i), then v=tl/u, then w=1000/v. You could also read "1000 tl 1000 i * / / gettime() +" by further doing x=w+gettime() ... it's read directly in sequence. 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. Downsides: * Have to actually implement it in the parser * If almost nobody uses it, still have to maintain it until the end of time for compatibility * While it takes all of 30 seconds to learn, it's not obvious what in the heck you're looking at if you've never seen it * 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) Things to not do: * Mix-and-match single expressions e.g. 6 2 (3 * 4) + *, 6 * 2 3 4 * + While the first looks innocent enough, without the parentheses it becomes 6*(2*3 + 4). The second is just unreadable. * Reverse polish function calls e.g. 3 4 + str() no, just no * Prohibit infix in a call e.g. 3 4 getdata(n + 2) + * This isn't ambiguous, nor is it more difficult to read or parse Thoughts?
One problem with trying to mix RPN with in-fix is that some operators, like - can be either a unary or binary operation in the in-fix notations, distinguished by context. In RPN you have lost that context. is x y - - the same as -(x-y) or is it x-(-y) ? or is it waiting for another operator and be x ?? (-(-y)) or is it expecting a previous operand and is ?? - (x-y) (same with +) Typical RPN systems get around this by having unary - be a different symbol/key that binary - -- Richard Damon
I think python only has 3 unary operations, + - and ~ and only + and - can also be binary operations. unary + has less uses, since it normally just passes its argument, if valid, unchanged, but can be used to validate that its argument has the right type. I am not sure if a type could define its own unary+ to do something special, but I thought it could. On 4/2/21 11:19 AM, John wrote:
-- Richard Damon
These are good points. I would suggest the unary - creates serious readability concerns and should only be valid as 0 x -; ~ and unary + raise other considerations. The ~ operator is extremely useful in bitshift and bitmask operations, and has an ugly ~x representation as 0 1 - x ^ in the same way as unary -x is 0 x - (which is elegant). Unary can't be assumed from 0 x +, and it seems inelegant to use things like ~x -x +x (i.e. without white space) On Fri, Apr 2, 2021 at 12:09 PM MRAB <python@mrabarnett.plus.com> wrote:
On Sat, Apr 3, 2021 at 3:49 AM John <john.r.moser@gmail.com> wrote:
That would mean that unary plus is no longer available to any type that isn't strictly a number. Python doesn't make mandates like that.
What's the advantage that you're offering? This is on python-ideas, so I have to assume that you're proposing a change or enhancement to the language here. ChrisA
I haven't figured a way to do unary + in RPN elegantly; I didn't say it had to be removed from the rest of the language. At the moment trying to avoid something silly like placing a _ to indicate the next operator is unary on the next term, which needs to be weighed against the likelihood that the use case for RPN over algebraic notation would involve a given unary operator. I find myself frequently using complicated equations that either break down into 3-5 lines of less-complicated equations or are just unreadable. Sometimes it takes me several tries to enter them, and going back and modifying all that requires…work. RPN is considered less prone to human error to begin with, with technical users approaching 4 times the error rate with infix, and non-technical users 1.5x the error rate with infix, so it seems an answer to the readability/modifiability issue. Math errors can have striking implications, e.g. for encryption, machine learning, and other scientific use cases, in which case users may want to enter a particular equation in a manner more human-auditable. At times I've solved this by other interesting approaches, e.g. ``` a = ( b / ( ( ((c+f) % d) * e ) ** ((g-h)/2) ) ) ``` (I use this for complicated boolean logic, too) …or: b/((((c+f)%d)*e)**((g-h)/2))) …or: b c f + d % e * g h - 2 / ** / The last one is readable, less ugly than the first one, and oddly enough easier to follow. Just reading it, I end up chunking things together as I encounter them: b [[[[c f +] d %] e *] [[g h -] 2 /] **] / 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. (Note the split around step 5: the operation between everything up to there and the next chunk of operations hasn't been encountered by that point, and I know that's hard-delimited at the * so I can see that split at a glance) Some simpler examples: Qn = Q(s[t],a[t]) + al * (r[t] + g * maxQ(s[t+1],a) - Q(s[t],a[t])) Qn = Q(s[t],a[t]) al + r[t] g maxQ(s[t 1 +],a) * + Q(s[t],a[t]) - * Qn = Q(s[t],a[t]) al + r[t] g maxQ(s[t 1 +],a) * Q(s[t],a[t]) - + * # Less readable: more operations stacking up at once Qn = Q(s[t],a[t]) al + r[t] g maxQ(s[t+1],a) * + Q(s[t],a[t]) - * # also sensible, as the term is maxQ(...) The third is harder to read than the second…barely. You might want to check your parenthesis on the first. Syntax highlighting has bigger benefits for the RPN than the algebraic notation, but they are admittedly both similarly difficult to follow without syntax highlighting (does the capacity for syntax highlighting to improve readability under one system or another even provide a useful consideration? Syntax highlighting isn't a component of the language). Less useful on smaller equations, where algebraic is probably more appropriate just because people are used to algebraic: p=e**(r*t) p=e r t * ** Other fun stuff: r1 = -b + ((b**2 - 4*a*c)**0.5 / 2*a) r1 = 0 b - b 2 ** 4 a c * * - 0.5 ** 2 a * / + r2 = 0 b - b 2 ** 4 a c * * - 0.5 ** 2 a * / - r1 = 0 b - sqrt(b 2 ** 4 a c * * -) 2 a * / + These are iffy put next to one another: r1 = b 2 ** 4 a c * * - 0.5 ** 2 a * / b - r2 = 0 b 2 ** 4 a c * * - 0.5 ** 2 a * / - b - The algebraic one is probably wrong: the /2 likely happens before the 2*a term. Almost missed that. Like most things when they start, someone asks a question and a domino either falls off the table or knocks over the other 6,000. It's at least generating interesting discussion. On Fri, Apr 2, 2021 at 12:58 PM Chris Angelico <rosuav@gmail.com> wrote:
Having both RPN and infix in one language seems like a verb as idea to me. But anyway: On Fri, Apr 2, 2021 at 11:22 AM John <john.r.moser@gmail.com> wrote:
Those sound like results from a study of some sort, so I wonder about the context. For me personally, I really loved RPN on my old HP calculators — particularly the one with a multi line screen that could showy the stack. But that’s keying things into a calcular, where adding parens is a pain. When trying to read RPN, I really struggle. Granted, that may because I haven’t practiced it hardly at all, but I’m not so sure. And the fact that most math instruction and use is done with infix and parentheses makes a very strong case. Everyone is familiar with infix, hardly anyone is familiar with RPN. -CHB Less useful on smaller equations, where algebraic is probably more
appropriate just because people are used to algebraic:
No small advantage. Frankly, putting long equations all in one line of code will always be hard to read. -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
Study was in calculators, yeah. https://vdocuments.mx/electronic-calculators-which-notation-is-the-better.ht... Can't argue that long equations are hard to read. The question is which is harder. A slew of parenthesis makes a mess that's difficult to detangle. Practice is a strange thing…I picked it up in under 90 seconds and it made immediate sense (I even tried doing algebraic proofs in it—which required me to invent rules about how to handle that—and found a generalization of a prior simple proof by accident). I'm not much affected by pre-existing knowledge that way, though, which is a distinct habit I've trained in: familiarity with algebraic notation (like all familiarity) naturally causes a conflict where the brain assumes a new thing can be identified as like an old thing, which it is currently able to handle, and (greatly) reduce energy consumption by rejecting this new thing in favor of the old thing; I obsessively consume new knowledge and use prior knowledge to make it accessible by analogy. It does look like a bunch of garble, on the face, requiring intent to take a closer look. Familiarity is no small advantage, in many ways. Transitioning to Dvorak was way, way harder than RPN; as many others have noticed, reports of amazing speed gains have been overstated, but it's a lot more comfortable. This comes with the disadvantage that any keyboard shortcuts organized for spatial logical proximity are now scattered nonsense. The point is salient. On Fri, Apr 2, 2021 at 10:16 PM Christopher Barker <pythonchb@gmail.com> wrote:
On Fri, Apr 2, 2021, 10:52 PM John <john.r.moser@gmail.com> wrote:
Study was in calculators, yeah.
https://vdocuments.mx/electronic-calculators-which-notation-is-the-better.ht...
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.
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:
Perhaps I should have been more clear than just mentioning "order of operations" here:
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:
And of course the other thing I said:
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 <mertz@gnosis.cx> wrote:
I know I'm late to the party but I think what would really help is if we were able to use any Unicode parenthesis characters instead of just (). Consider how much more readable this is: b*(⧼x*2⧽^❪⦅3-a⦆-⟮7*c⟯)❫) --- Bruce
On 3/04/21 5:07 pm, John wrote:
Seems to me you're looking back and forth just as much here. You're starting somewhere in the middle (how did you know to start there?) then looking left for the 2 and right for the **, then left for the x and right for the *, etc. etc. etc. The fact that you have to mentally follow a set of steps is a *disadvantage* of RPN for me. I can look at b*((x*2^(3-a))-(7*c)) and just *see* various things about it. For example, I can see that 2 is raised to the power 3-a. I can see that b is multiplying everything else. None of those things are obvious at a glance to me from the RPN. Sure, I can figure it all out, but it takes work, and I'm not confident that I haven't made a mistake. Which means I'd much rather audit an infix expression than an RPN one. -- Greg
On Sat, Apr 3, 2021 at 1:03 AM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
You know where to start because you stop at the first operator you hit and take the prior two things.
What I see with RPN is a step-by-step operation. What I see above is a number of kernels that need to be separated out and ordered. Sure, you can immediately recognize and extract bits, but can you immediately follow the whole computatio?
I'm never confident I've not made a mistake with anything more than trivial infix. It's like reading perl. Using anzan takes work…at first. Eventually I stopped validating my arithmetic though: {(1,4),(2,3)}, {(1,9),(2,8),(3,7),(4,6),(5,5)} 374 + 297 = ? 3+2=5 7+4 = [(9,1)→7 - 1] 16 → 66 4+7 = [(7,3)→4 - 3] 11 → 671 I guess immediately recognizing addition as subtraction is work, but wow is it fast to just register and accumulate using a look-up table instead of counting up the digits and slowly jumbling them around. (There's a table for 5 because numbers can be represented on a 4/1 abacus and this makes it oddly fast to add single-digit numbers that don't overflow to 10, because they overflow to 5 and you can subitize up to 3) Point taken, but I'll have to mill it over and try and figure out if the perspective is rejection of the unfamiliar or something inherent in the human mind. All evidence I've gathered has indicated all human brains are basically the same—nobody is really smarter than anyone else, just piled up with different experience—so I have a large amount of bias in that kind of evaluation (i.e. if it's inherent, I must have done something in the past that specifically entrained some skill into my brain to make it different).
On 2021-04-03 12:07 a.m., John wrote:
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
Alexandre Brault writes:
On 2021-04-03 12:07 a.m., John wrote:
+1 That was my immediate reaction, too: This is what temp variables like ____, ________, ___________, ___, and _____ are for! Although I prefer giving them less opaque names. :-) I do love RPN for calculations, dc >> bc any day IMO. But for me, RPN is write-only. The advantage is that I can frequently do the calculation twice in dc in the time it takes to do it once and verify correct formula and no typos in bc. Steve
On Sat, Apr 3, 2021 at 5:26 AM Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Helps, but does spread the information out. It also requires finding useful names, and there aren't always meaningful names for intermediate steps.
Interesting that people find it write-only. I find it easier to modify a complicated equation in RPN than algebraic because it's easier to find precisely the part of the calculation I need and insert the extra code. I'd honestly been considering if we should have taught RPN first to give students a way to parse complicated algebraic equations by rewriting them in a less-opaque form, but quickly realized you never encounter anything more complicated than multiplying two polynomials in an educational setting..
John writes:
Here's a question: is it possible to implement this with a Python module, or is that absolutely not a thing that can be done?
Yes, it can, or at least you could use MacroPy (not sure if that's pure Python, if it is then you could implement in a module using the same techniques).
Helps, but does spread the information out.
That's not a problem for reading the expressions themselves -- spreading out the information into meaningful (and thus nameable) chunks is the point of the exercise. *Unless* you've got a pure functional language. In that case you could be 436k away from the beginning of the expression (that's the largest Java class I ever encountered in the wild, and boy, was it wild). I'd be more sympathetic if the issue was spreading out a suite of statements, but even then, not very. I've never encountered code that can't be understood if written in 24x80 chunks of Python, including the relevant def lines and a couple of comments. If efficiency is required (and achievable in pure Python!), inlining those functions isn't hard, although it can be tedious. Very rarely is *naming* those functions difficult. YMMV, of course, but that WFM. (Note, I don't object to the proposal, I'm purely talking about what WFM. I might object to you using it if we were working on the same project, though. Depends on circumstances. :-)
It also requires finding useful names, and there aren't always meaningful names for intermediate steps.
Then those are the "wrong" intermediate steps. If you *really* need to break there, then a meaningless name such as "__" is fine. One practical problem with RPN is that one way to break up and "mark" subexpressions *without* temporary variables is to use (physical) newlines and indentation. With infix notation (minuend # note: parentheses are idiomatic Python line - subtrahend # continuation + multiplicand * multiplier) reads well and parses easily in-brain. But in RPN you have an uncomfortable choice: put the operators at line endings (where you will *not* normally be scanning in Python because syntactic keywords generally come at the beginning of the line) or put them at the beginning of the line (requiring scanning up the page to find the operands and probably giving your brain a bit of WTF). Even a programming language with Arabic or Hebrew keywords wouldn't work well with RPN as far as I can imagine. Yes, you'd be scanning down the right margin for syntax, but the RPN operators would end up at the left margin! Or maybe in the middle of the line, depending on how you interpret "BIDI" (any comments from those fluent in a BIDI language?) Could be "just my [lack of] imagination", of course.
As an applied mathematical economist, I work with obnoxiously complicated equations a lot, but always factor out subexpressions and give them names (to which the policy wonks frequently apply motivated reasoning and conclude I proved exactly what they needed, c'est la vie :-). I am not struck by reasons to dive into a complex expression and modify it. I discover reasons to modify some relevant subexpression instead. That's the way I *think* about such interative refinement processes as well as how I *implement* them (ie, typically notated as functions). Maybe that's why I work that way with Python programs, too. I don't know about your field, but in mine it's *very* unusual to encounter expressions that aren't repeated in other contexts, and therefore idiomatic ~= meaningful. Usually that subexpression is there because it implements a domain concept. If I don't have a good existing name, a neologism will do, and because the expression is an idiom, that neologism has meaning to others in my field -- from the subexpression.
Complicated expressions are just complicated. I don't think it really matters which way you teach. Either way you can't avoid the complexity, and either way you have to parenthesize, either with actual parentheses in the expression itself, or with increasingly long underlines. :-) (I'm laughing at myself, because I think it's true but I'm not 100% sure.) Steve
On Sun, Apr 4, 2021 at 3:17 AM Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Something worth noting - and it's not closely related to this section, but it's near enough and I'm going to quote this as an example - is that complicated expressions can be logically grouped, just like prose can. You have sentences, phrases, words. In the example you give here, "multiplicand * multiplier" needs to be a phrase, since it will be evaluated before the addition and subtraction are. Ideally, the way you lay out the code should correspond to its logical meaning; at very least, it shouldn't contradict it. (minuend - subtrahend + multiplicand * multiplier) Or alternatively: (minuend - subtrahend + multiplicand * multiplier) Algebra gives us a HIGHLY compact notation (far too compact to be truly useful in computing, as it's very blackboard/paper oriented) that does a great job of grouping terms (words) and subexpressions (phrases). Take, for example, this explanation of the Basel problem: https://youtu.be/d-o3eB9sfls?t=881 It's extremely clear that you are summing a series of terms, where each term is the inverse of a square. On the positive side, it's compact and elegant; on the negative side, parentheses group it to make sure you don't negate at the wrong time. But algebra, like shell languages, is ill-suited to general purpose programming. That's why we don't write our code using abuttal to indicate multiplication, or multi-line text with fraction bars inside fraction bars and different sizes of text. Still, the idea of grouping should be the same. Find the parts that logically represent a "phrase" within your "sentence", and gather those together. For instance, here's how I invoke ffmpeg to create a movie clip: subprocess.run([ "ffmpeg", "-i", inputfile, "-ss", str(last_end + int(args.get("trimstart", 0))), "-t", str(start - last_end - int(args.get("trimend", 0))), "-c", "copy", output, "-y", "-loglevel", "quiet", "-stats", ], check=True) Each line is a logical phrase. Run ffmpeg on this file; start at this point; go for this length; copy it to this file; and shut up, I don't need all the noise. Oh, and make sure it succeeds, else bomb. Doing that with RPN doesn't work. It doesn't even make sense. RPN is the assembly code of algebra - it's good at identifying minute steps in a process, it's easy to write an interpreter for it, but it sucks at actually describing someone's intentions. ChrisA
On 3/04/21 4:33 pm, David Mertz wrote:
add all these 20 receipts together without needing 19 "+" signs, but just one at the end.
Um, that's not the way any RPN calculator I've seen works. You still need to press the "+" key 19 times, just in slightly different places. To get by with just one "+" you would need some way to bracket the arguments, then you have something more like backwards Lisp with at least as many parens as infix. -- Greg
It's a long time ago, but I'm pretty sure I used ticker tape adding machines with a big ENTER button to separate numbers... Then the operation, usually +, at the end. Of course, an "enter" delimiter isn't any fewer key presses than a bunch of '+' keys. But that emulates the way arithmetic lessons are usually written, and most people do on paper. E.g. 384 423 827 563 + ---------- ???? Isn't that what you learned in grade school? I vaguely recall as a child using a mechanical one where you pulled a lever between lines as the "enter". Not something I did on a regular basis, but something I had seen as already old fashioned when I was 10 yo. On Sat, Apr 3, 2021, 12:41 AM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
On 3/04/21 6:15 pm, David Mertz wrote:
That seems unlikely. If you don't tell it what to do with the numbers until the very end, it needs a stack big enough to hold all of them. Early RPN calculators typically had a very small stack, usually about 4 items. HP calculators had an ENTER button, but you only used it to separate the first two numbers, then used + or whatever after subsequent ones.
Yes, but there the paper is your stack, and it's big enough to hold quite a few numbers. You were also probably taught to add the numbers up column by column, which is quite different from the way a calculator or computer does it!
I vaguely recall as a child using a mechanical one where you pulled a lever between lines as the "enter".
I wouldn't call that an "enter" lever, rather a "+" lever, since it was almost certainly adding the entered number to its accumulator. There will also have been some kind of mode switch to make it subtract instead of add. -- Greg
On 4/3/21 7:16 AM, Greg Ewing wrote:
Actually, on the traditional tape based adding machine, the key labeled 'Enter' was really a command to add to the running sum. The + key was actually 'Total' and commanded to print the result to the tape. The minus key was sort of the opposite of Enter, it subtracted the entry from the running sum, and depending on the machine, print the current sum. -- Richard Damon
Greg Ewing writes:
You can't invoke Lisp here: (+) 0 (+ 1) 1 (+ 1 1) 2 (+ 1 1 1) 3 and so on. My recollection is the same as David's, except that in the worksheets I used (and the worksheets my daughter used in Japanese school) the operation was implicit. The instructions at the top of the page would say "add all the numbers in each example", and they would be arranged in a column in each example. (Only for addition, though.) Steve
On 3/04/21 3:51 pm, John wrote:
In my experience, RPN is always harder to read than infix. A slew of parens can be confusing, but a bunch of operators piled up at the end of an expression doesn't make it any better for me. I once had the need to write substantial amounts of Postscript by hand (it was for Sun's NeWS window server), and I found it so tedious and hard to get right that I devised an infix language and wrote a compiler to translate it into Postscript. The project went much more smoothly after that! -- Greg
On Sat, Apr 3, 2021, 12:34 AM Greg Ewing
When I first saw the original post, I honestly believed it had to be an April Fool gag. Like Greg, and 99% of other people, I find RPN vastly harder to parse. I have also written or edited Postscript by hand, but much more small hobbyist level than a real work need. It's crazy difficult. I confusedly accept or stipulate that John is in that <1% who process this differently. But the greater difficulty of RPN isn't only my greater familiarity with infix, it's also objectively measurable. The example John gives makes infix capriciously worse by omitting normal spacing (while keeping them by requirement for postfix). But let's bracket that. A reasonable measure of difficulty is simply to count the number of eye movements required to parse each version. In John's example, or any of similar moderate complexity, postfix requires 1.5-2x as many eye movements as infix. You can measure this in a manner similar to Levenshtein distance, as a collection of small atomic actions. It's not so much that moving eyeballs is difficult for most people. Rather, every such movement is a very slight mental pause to redirect attention. Of course, you never need to do anything other than scan left to right if ALL you are trying to understand is the final result. But that's not what we do when reading computer code. Rather, we want to understand the WHY and the WHAT of an expression as a whole.
On 2021-04-02 06:48, John wrote:
My thoughts are: 1) This post is rambling and does not make clear exactly what is being proposed. 2) Python has zero need for RPN and adding RPN to Python (assuming that is what is being proposed here) would be a bad idea in every way 3) There is no point in discussing this further. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown
One problem with trying to mix RPN with in-fix is that some operators, like - can be either a unary or binary operation in the in-fix notations, distinguished by context. In RPN you have lost that context. is x y - - the same as -(x-y) or is it x-(-y) ? or is it waiting for another operator and be x ?? (-(-y)) or is it expecting a previous operand and is ?? - (x-y) (same with +) Typical RPN systems get around this by having unary - be a different symbol/key that binary - -- Richard Damon
I think python only has 3 unary operations, + - and ~ and only + and - can also be binary operations. unary + has less uses, since it normally just passes its argument, if valid, unchanged, but can be used to validate that its argument has the right type. I am not sure if a type could define its own unary+ to do something special, but I thought it could. On 4/2/21 11:19 AM, John wrote:
-- Richard Damon
These are good points. I would suggest the unary - creates serious readability concerns and should only be valid as 0 x -; ~ and unary + raise other considerations. The ~ operator is extremely useful in bitshift and bitmask operations, and has an ugly ~x representation as 0 1 - x ^ in the same way as unary -x is 0 x - (which is elegant). Unary can't be assumed from 0 x +, and it seems inelegant to use things like ~x -x +x (i.e. without white space) On Fri, Apr 2, 2021 at 12:09 PM MRAB <python@mrabarnett.plus.com> wrote:
On Sat, Apr 3, 2021 at 3:49 AM John <john.r.moser@gmail.com> wrote:
That would mean that unary plus is no longer available to any type that isn't strictly a number. Python doesn't make mandates like that.
What's the advantage that you're offering? This is on python-ideas, so I have to assume that you're proposing a change or enhancement to the language here. ChrisA
I haven't figured a way to do unary + in RPN elegantly; I didn't say it had to be removed from the rest of the language. At the moment trying to avoid something silly like placing a _ to indicate the next operator is unary on the next term, which needs to be weighed against the likelihood that the use case for RPN over algebraic notation would involve a given unary operator. I find myself frequently using complicated equations that either break down into 3-5 lines of less-complicated equations or are just unreadable. Sometimes it takes me several tries to enter them, and going back and modifying all that requires…work. RPN is considered less prone to human error to begin with, with technical users approaching 4 times the error rate with infix, and non-technical users 1.5x the error rate with infix, so it seems an answer to the readability/modifiability issue. Math errors can have striking implications, e.g. for encryption, machine learning, and other scientific use cases, in which case users may want to enter a particular equation in a manner more human-auditable. At times I've solved this by other interesting approaches, e.g. ``` a = ( b / ( ( ((c+f) % d) * e ) ** ((g-h)/2) ) ) ``` (I use this for complicated boolean logic, too) …or: b/((((c+f)%d)*e)**((g-h)/2))) …or: b c f + d % e * g h - 2 / ** / The last one is readable, less ugly than the first one, and oddly enough easier to follow. Just reading it, I end up chunking things together as I encounter them: b [[[[c f +] d %] e *] [[g h -] 2 /] **] / 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. (Note the split around step 5: the operation between everything up to there and the next chunk of operations hasn't been encountered by that point, and I know that's hard-delimited at the * so I can see that split at a glance) Some simpler examples: Qn = Q(s[t],a[t]) + al * (r[t] + g * maxQ(s[t+1],a) - Q(s[t],a[t])) Qn = Q(s[t],a[t]) al + r[t] g maxQ(s[t 1 +],a) * + Q(s[t],a[t]) - * Qn = Q(s[t],a[t]) al + r[t] g maxQ(s[t 1 +],a) * Q(s[t],a[t]) - + * # Less readable: more operations stacking up at once Qn = Q(s[t],a[t]) al + r[t] g maxQ(s[t+1],a) * + Q(s[t],a[t]) - * # also sensible, as the term is maxQ(...) The third is harder to read than the second…barely. You might want to check your parenthesis on the first. Syntax highlighting has bigger benefits for the RPN than the algebraic notation, but they are admittedly both similarly difficult to follow without syntax highlighting (does the capacity for syntax highlighting to improve readability under one system or another even provide a useful consideration? Syntax highlighting isn't a component of the language). Less useful on smaller equations, where algebraic is probably more appropriate just because people are used to algebraic: p=e**(r*t) p=e r t * ** Other fun stuff: r1 = -b + ((b**2 - 4*a*c)**0.5 / 2*a) r1 = 0 b - b 2 ** 4 a c * * - 0.5 ** 2 a * / + r2 = 0 b - b 2 ** 4 a c * * - 0.5 ** 2 a * / - r1 = 0 b - sqrt(b 2 ** 4 a c * * -) 2 a * / + These are iffy put next to one another: r1 = b 2 ** 4 a c * * - 0.5 ** 2 a * / b - r2 = 0 b 2 ** 4 a c * * - 0.5 ** 2 a * / - b - The algebraic one is probably wrong: the /2 likely happens before the 2*a term. Almost missed that. Like most things when they start, someone asks a question and a domino either falls off the table or knocks over the other 6,000. It's at least generating interesting discussion. On Fri, Apr 2, 2021 at 12:58 PM Chris Angelico <rosuav@gmail.com> wrote:
Having both RPN and infix in one language seems like a verb as idea to me. But anyway: On Fri, Apr 2, 2021 at 11:22 AM John <john.r.moser@gmail.com> wrote:
Those sound like results from a study of some sort, so I wonder about the context. For me personally, I really loved RPN on my old HP calculators — particularly the one with a multi line screen that could showy the stack. But that’s keying things into a calcular, where adding parens is a pain. When trying to read RPN, I really struggle. Granted, that may because I haven’t practiced it hardly at all, but I’m not so sure. And the fact that most math instruction and use is done with infix and parentheses makes a very strong case. Everyone is familiar with infix, hardly anyone is familiar with RPN. -CHB Less useful on smaller equations, where algebraic is probably more
appropriate just because people are used to algebraic:
No small advantage. Frankly, putting long equations all in one line of code will always be hard to read. -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
Study was in calculators, yeah. https://vdocuments.mx/electronic-calculators-which-notation-is-the-better.ht... Can't argue that long equations are hard to read. The question is which is harder. A slew of parenthesis makes a mess that's difficult to detangle. Practice is a strange thing…I picked it up in under 90 seconds and it made immediate sense (I even tried doing algebraic proofs in it—which required me to invent rules about how to handle that—and found a generalization of a prior simple proof by accident). I'm not much affected by pre-existing knowledge that way, though, which is a distinct habit I've trained in: familiarity with algebraic notation (like all familiarity) naturally causes a conflict where the brain assumes a new thing can be identified as like an old thing, which it is currently able to handle, and (greatly) reduce energy consumption by rejecting this new thing in favor of the old thing; I obsessively consume new knowledge and use prior knowledge to make it accessible by analogy. It does look like a bunch of garble, on the face, requiring intent to take a closer look. Familiarity is no small advantage, in many ways. Transitioning to Dvorak was way, way harder than RPN; as many others have noticed, reports of amazing speed gains have been overstated, but it's a lot more comfortable. This comes with the disadvantage that any keyboard shortcuts organized for spatial logical proximity are now scattered nonsense. The point is salient. On Fri, Apr 2, 2021 at 10:16 PM Christopher Barker <pythonchb@gmail.com> wrote:
On Fri, Apr 2, 2021, 10:52 PM John <john.r.moser@gmail.com> wrote:
Study was in calculators, yeah.
https://vdocuments.mx/electronic-calculators-which-notation-is-the-better.ht...
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.
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:
Perhaps I should have been more clear than just mentioning "order of operations" here:
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:
And of course the other thing I said:
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 <mertz@gnosis.cx> wrote:
I know I'm late to the party but I think what would really help is if we were able to use any Unicode parenthesis characters instead of just (). Consider how much more readable this is: b*(⧼x*2⧽^❪⦅3-a⦆-⟮7*c⟯)❫) --- Bruce
On 3/04/21 5:07 pm, John wrote:
Seems to me you're looking back and forth just as much here. You're starting somewhere in the middle (how did you know to start there?) then looking left for the 2 and right for the **, then left for the x and right for the *, etc. etc. etc. The fact that you have to mentally follow a set of steps is a *disadvantage* of RPN for me. I can look at b*((x*2^(3-a))-(7*c)) and just *see* various things about it. For example, I can see that 2 is raised to the power 3-a. I can see that b is multiplying everything else. None of those things are obvious at a glance to me from the RPN. Sure, I can figure it all out, but it takes work, and I'm not confident that I haven't made a mistake. Which means I'd much rather audit an infix expression than an RPN one. -- Greg
On Sat, Apr 3, 2021 at 1:03 AM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
You know where to start because you stop at the first operator you hit and take the prior two things.
What I see with RPN is a step-by-step operation. What I see above is a number of kernels that need to be separated out and ordered. Sure, you can immediately recognize and extract bits, but can you immediately follow the whole computatio?
I'm never confident I've not made a mistake with anything more than trivial infix. It's like reading perl. Using anzan takes work…at first. Eventually I stopped validating my arithmetic though: {(1,4),(2,3)}, {(1,9),(2,8),(3,7),(4,6),(5,5)} 374 + 297 = ? 3+2=5 7+4 = [(9,1)→7 - 1] 16 → 66 4+7 = [(7,3)→4 - 3] 11 → 671 I guess immediately recognizing addition as subtraction is work, but wow is it fast to just register and accumulate using a look-up table instead of counting up the digits and slowly jumbling them around. (There's a table for 5 because numbers can be represented on a 4/1 abacus and this makes it oddly fast to add single-digit numbers that don't overflow to 10, because they overflow to 5 and you can subitize up to 3) Point taken, but I'll have to mill it over and try and figure out if the perspective is rejection of the unfamiliar or something inherent in the human mind. All evidence I've gathered has indicated all human brains are basically the same—nobody is really smarter than anyone else, just piled up with different experience—so I have a large amount of bias in that kind of evaluation (i.e. if it's inherent, I must have done something in the past that specifically entrained some skill into my brain to make it different).
On 2021-04-03 12:07 a.m., John wrote:
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
Alexandre Brault writes:
On 2021-04-03 12:07 a.m., John wrote:
+1 That was my immediate reaction, too: This is what temp variables like ____, ________, ___________, ___, and _____ are for! Although I prefer giving them less opaque names. :-) I do love RPN for calculations, dc >> bc any day IMO. But for me, RPN is write-only. The advantage is that I can frequently do the calculation twice in dc in the time it takes to do it once and verify correct formula and no typos in bc. Steve
On Sat, Apr 3, 2021 at 5:26 AM Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Helps, but does spread the information out. It also requires finding useful names, and there aren't always meaningful names for intermediate steps.
Interesting that people find it write-only. I find it easier to modify a complicated equation in RPN than algebraic because it's easier to find precisely the part of the calculation I need and insert the extra code. I'd honestly been considering if we should have taught RPN first to give students a way to parse complicated algebraic equations by rewriting them in a less-opaque form, but quickly realized you never encounter anything more complicated than multiplying two polynomials in an educational setting..
John writes:
Here's a question: is it possible to implement this with a Python module, or is that absolutely not a thing that can be done?
Yes, it can, or at least you could use MacroPy (not sure if that's pure Python, if it is then you could implement in a module using the same techniques).
Helps, but does spread the information out.
That's not a problem for reading the expressions themselves -- spreading out the information into meaningful (and thus nameable) chunks is the point of the exercise. *Unless* you've got a pure functional language. In that case you could be 436k away from the beginning of the expression (that's the largest Java class I ever encountered in the wild, and boy, was it wild). I'd be more sympathetic if the issue was spreading out a suite of statements, but even then, not very. I've never encountered code that can't be understood if written in 24x80 chunks of Python, including the relevant def lines and a couple of comments. If efficiency is required (and achievable in pure Python!), inlining those functions isn't hard, although it can be tedious. Very rarely is *naming* those functions difficult. YMMV, of course, but that WFM. (Note, I don't object to the proposal, I'm purely talking about what WFM. I might object to you using it if we were working on the same project, though. Depends on circumstances. :-)
It also requires finding useful names, and there aren't always meaningful names for intermediate steps.
Then those are the "wrong" intermediate steps. If you *really* need to break there, then a meaningless name such as "__" is fine. One practical problem with RPN is that one way to break up and "mark" subexpressions *without* temporary variables is to use (physical) newlines and indentation. With infix notation (minuend # note: parentheses are idiomatic Python line - subtrahend # continuation + multiplicand * multiplier) reads well and parses easily in-brain. But in RPN you have an uncomfortable choice: put the operators at line endings (where you will *not* normally be scanning in Python because syntactic keywords generally come at the beginning of the line) or put them at the beginning of the line (requiring scanning up the page to find the operands and probably giving your brain a bit of WTF). Even a programming language with Arabic or Hebrew keywords wouldn't work well with RPN as far as I can imagine. Yes, you'd be scanning down the right margin for syntax, but the RPN operators would end up at the left margin! Or maybe in the middle of the line, depending on how you interpret "BIDI" (any comments from those fluent in a BIDI language?) Could be "just my [lack of] imagination", of course.
As an applied mathematical economist, I work with obnoxiously complicated equations a lot, but always factor out subexpressions and give them names (to which the policy wonks frequently apply motivated reasoning and conclude I proved exactly what they needed, c'est la vie :-). I am not struck by reasons to dive into a complex expression and modify it. I discover reasons to modify some relevant subexpression instead. That's the way I *think* about such interative refinement processes as well as how I *implement* them (ie, typically notated as functions). Maybe that's why I work that way with Python programs, too. I don't know about your field, but in mine it's *very* unusual to encounter expressions that aren't repeated in other contexts, and therefore idiomatic ~= meaningful. Usually that subexpression is there because it implements a domain concept. If I don't have a good existing name, a neologism will do, and because the expression is an idiom, that neologism has meaning to others in my field -- from the subexpression.
Complicated expressions are just complicated. I don't think it really matters which way you teach. Either way you can't avoid the complexity, and either way you have to parenthesize, either with actual parentheses in the expression itself, or with increasingly long underlines. :-) (I'm laughing at myself, because I think it's true but I'm not 100% sure.) Steve
On Sun, Apr 4, 2021 at 3:17 AM Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Something worth noting - and it's not closely related to this section, but it's near enough and I'm going to quote this as an example - is that complicated expressions can be logically grouped, just like prose can. You have sentences, phrases, words. In the example you give here, "multiplicand * multiplier" needs to be a phrase, since it will be evaluated before the addition and subtraction are. Ideally, the way you lay out the code should correspond to its logical meaning; at very least, it shouldn't contradict it. (minuend - subtrahend + multiplicand * multiplier) Or alternatively: (minuend - subtrahend + multiplicand * multiplier) Algebra gives us a HIGHLY compact notation (far too compact to be truly useful in computing, as it's very blackboard/paper oriented) that does a great job of grouping terms (words) and subexpressions (phrases). Take, for example, this explanation of the Basel problem: https://youtu.be/d-o3eB9sfls?t=881 It's extremely clear that you are summing a series of terms, where each term is the inverse of a square. On the positive side, it's compact and elegant; on the negative side, parentheses group it to make sure you don't negate at the wrong time. But algebra, like shell languages, is ill-suited to general purpose programming. That's why we don't write our code using abuttal to indicate multiplication, or multi-line text with fraction bars inside fraction bars and different sizes of text. Still, the idea of grouping should be the same. Find the parts that logically represent a "phrase" within your "sentence", and gather those together. For instance, here's how I invoke ffmpeg to create a movie clip: subprocess.run([ "ffmpeg", "-i", inputfile, "-ss", str(last_end + int(args.get("trimstart", 0))), "-t", str(start - last_end - int(args.get("trimend", 0))), "-c", "copy", output, "-y", "-loglevel", "quiet", "-stats", ], check=True) Each line is a logical phrase. Run ffmpeg on this file; start at this point; go for this length; copy it to this file; and shut up, I don't need all the noise. Oh, and make sure it succeeds, else bomb. Doing that with RPN doesn't work. It doesn't even make sense. RPN is the assembly code of algebra - it's good at identifying minute steps in a process, it's easy to write an interpreter for it, but it sucks at actually describing someone's intentions. ChrisA
On 3/04/21 4:33 pm, David Mertz wrote:
add all these 20 receipts together without needing 19 "+" signs, but just one at the end.
Um, that's not the way any RPN calculator I've seen works. You still need to press the "+" key 19 times, just in slightly different places. To get by with just one "+" you would need some way to bracket the arguments, then you have something more like backwards Lisp with at least as many parens as infix. -- Greg
It's a long time ago, but I'm pretty sure I used ticker tape adding machines with a big ENTER button to separate numbers... Then the operation, usually +, at the end. Of course, an "enter" delimiter isn't any fewer key presses than a bunch of '+' keys. But that emulates the way arithmetic lessons are usually written, and most people do on paper. E.g. 384 423 827 563 + ---------- ???? Isn't that what you learned in grade school? I vaguely recall as a child using a mechanical one where you pulled a lever between lines as the "enter". Not something I did on a regular basis, but something I had seen as already old fashioned when I was 10 yo. On Sat, Apr 3, 2021, 12:41 AM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
On 3/04/21 6:15 pm, David Mertz wrote:
That seems unlikely. If you don't tell it what to do with the numbers until the very end, it needs a stack big enough to hold all of them. Early RPN calculators typically had a very small stack, usually about 4 items. HP calculators had an ENTER button, but you only used it to separate the first two numbers, then used + or whatever after subsequent ones.
Yes, but there the paper is your stack, and it's big enough to hold quite a few numbers. You were also probably taught to add the numbers up column by column, which is quite different from the way a calculator or computer does it!
I vaguely recall as a child using a mechanical one where you pulled a lever between lines as the "enter".
I wouldn't call that an "enter" lever, rather a "+" lever, since it was almost certainly adding the entered number to its accumulator. There will also have been some kind of mode switch to make it subtract instead of add. -- Greg
On 4/3/21 7:16 AM, Greg Ewing wrote:
Actually, on the traditional tape based adding machine, the key labeled 'Enter' was really a command to add to the running sum. The + key was actually 'Total' and commanded to print the result to the tape. The minus key was sort of the opposite of Enter, it subtracted the entry from the running sum, and depending on the machine, print the current sum. -- Richard Damon
Greg Ewing writes:
You can't invoke Lisp here: (+) 0 (+ 1) 1 (+ 1 1) 2 (+ 1 1 1) 3 and so on. My recollection is the same as David's, except that in the worksheets I used (and the worksheets my daughter used in Japanese school) the operation was implicit. The instructions at the top of the page would say "add all the numbers in each example", and they would be arranged in a column in each example. (Only for addition, though.) Steve
On 3/04/21 3:51 pm, John wrote:
In my experience, RPN is always harder to read than infix. A slew of parens can be confusing, but a bunch of operators piled up at the end of an expression doesn't make it any better for me. I once had the need to write substantial amounts of Postscript by hand (it was for Sun's NeWS window server), and I found it so tedious and hard to get right that I devised an infix language and wrote a compiler to translate it into Postscript. The project went much more smoothly after that! -- Greg
On Sat, Apr 3, 2021, 12:34 AM Greg Ewing
When I first saw the original post, I honestly believed it had to be an April Fool gag. Like Greg, and 99% of other people, I find RPN vastly harder to parse. I have also written or edited Postscript by hand, but much more small hobbyist level than a real work need. It's crazy difficult. I confusedly accept or stipulate that John is in that <1% who process this differently. But the greater difficulty of RPN isn't only my greater familiarity with infix, it's also objectively measurable. The example John gives makes infix capriciously worse by omitting normal spacing (while keeping them by requirement for postfix). But let's bracket that. A reasonable measure of difficulty is simply to count the number of eye movements required to parse each version. In John's example, or any of similar moderate complexity, postfix requires 1.5-2x as many eye movements as infix. You can measure this in a manner similar to Levenshtein distance, as a collection of small atomic actions. It's not so much that moving eyeballs is difficult for most people. Rather, every such movement is a very slight mental pause to redirect attention. Of course, you never need to do anything other than scan left to right if ALL you are trying to understand is the final result. But that's not what we do when reading computer code. Rather, we want to understand the WHY and the WHAT of an expression as a whole.
On 2021-04-02 06:48, John wrote:
My thoughts are: 1) This post is rambling and does not make clear exactly what is being proposed. 2) Python has zero need for RPN and adding RPN to Python (assuming that is what is being proposed here) would be a bad idea in every way 3) There is no point in discussing this further. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown
participants (12)
-
Alexandre Brault -
Brendan Barnwell -
Bruce Leban -
Chris Angelico -
Christopher Barker -
David Mertz -
Greg Ewing -
John -
Jonathan Goble -
MRAB -
Richard Damon -
Stephen J. Turnbull