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 <ros...@gmail.com> wrote: > > On Sat, Apr 3, 2021 at 3:49 AM John <john.r.mo...@gmail.com> wrote: > > > > 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) > > > > 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. > > >>> from collections import Counter > >>> c = Counter(a=1, b=2, c=-4) > >>> +c > Counter({'b': 2, 'a': 1}) > >>> c > Counter({'b': 2, 'a': 1, 'c': -4}) > >>> 0+c > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > TypeError: unsupported operand type(s) for +: 'int' and 'Counter' > > 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 > _______________________________________________ > 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/FMFPVANZY4XTXSJAYNUY4UTUXPFNINUF/ > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ 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/QGSY5OWTKXEQ26EVADIBRXPISJFZ4RGX/ Code of Conduct: http://python.org/psf/codeofconduct/