On Sat, Apr 3, 2021, 12:34 AM Greg Ewing
> 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.
>
When I first saw the original post, I honestly believed
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
On 3/04/21 5:07 pm, John wrote:
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
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
___
Python-ideas mailing list
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
On 3/04/21 3:51 pm, John wrote:
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.
In my experience, RPN is always harder to read than infix. A slew of
parens can be confusing, but a bunch of
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
On Fri, Apr 2, 2021, 10:52 PM John 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
Study was in calculators, yeah.
https://vdocuments.mx/electronic-calculators-which-notation-is-the-better.html
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
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 wrote:
> 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
>
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
Dear pythonistas,
I was wondering if we could add a clarification to PEP 394? I'm trying to
get some visibility on this.
There's a bullet in the PEP that states:
*For scripts that are only expected to be run in an activated virtual
environment, shebang lines can be written as #!/usr/bin/env
On Sat, Apr 3, 2021 at 3:49 AM John 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
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
I assume it's always April 1 somewhere on Earth. :-)
On Fri, Apr 2, 2021, 12:13 PM Jonathan Goble wrote:
> On Fri, Apr 2, 2021 at 11:58 AM Richard Damon
> wrote:
>
>> I think python only has 3 unary operations, + - and ~ and only + and -
>> can also be binary operations.
>>
>> unary + has
On Fri, Apr 2, 2021 at 11:58 AM Richard Damon
wrote:
> 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
On 2021-04-02 16:55, Richard Damon wrote:
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
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
True. It gets ambiguous when doing n*(-(x + y)) i.e. n x y + - *
(fail). The simplest solution is n 0 x y + - *
I can't actually think of any other unary operators.
On Fri, Apr 2, 2021 at 10:54 AM Richard Damon wrote:
>
> One problem with trying to mix RPN with in-fix is that some operators,
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
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
21 matches
Mail list logo
