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/
