Understanding the working mechanis of python unary arithmetic operators.

[dn]

On 06/10/2021 10.10, Chris Angelico wrote:
> On Wed, Oct 6, 2021 at 7:52 AM hongy... at gmail.com <hongyi.zhao at gmail.com> wrote:
>>
>> On Saturday, October 2, 2021 at 4:59:54 PM UTC+8, ju... at diegidio.name wrote:

This thread seems to have been very one-sided. Either I've forgotten
selective use of the DEL-key, or the above contributor has been
forgetting to reply to the list (or didn't intend contribution?) Please
share your knowledge with all!


>>> On Saturday, 2 October 2021 at 10:34:27 UTC+2, hongy... at gmail.com wrote:

> If bool(a) is True, then ~bool(a) is exactly the same as writing
> ~True, and a has become irrelevant. That is simply how expression
> evaluation works.

@Chris and I presented at a recent PUG meeting on the subject of
'operators'.
(I was the 'warm-up act', @Chris the 'star'...)

I covered unary operators
(https://docs.python.org/3/reference/expressions.html#unary-arithmetic-and-bitwise-operations)
- and very briefly, because that's proportional to their application 'in
the real world'. Negation is sometimes used, binary inversion very
occasionally, but the 'unary plus' almost never!

Thus:

>>> a = 3
>>> +a
3
>>> -a
-3

Why would one use the plus operator?

Particularly when it confuses some, ie if negation changes the sign,
won't the unary-plus?

>>> b = -3
>>> +b
-3
>>> -b
3

What has the unary-plus achieved in either/both of these cases? Not
much, but may not be doing something that was 'expected'!

The bitwise inversion (~) is also widely misunderstood (just like the
story of my life). It is not "bit inversion", as in, a single bit being
inverted:
(values here are expressed in base-2!)

~0 -> 1
~1 -> 0

Instead, it involves the inversion of every bit. Thus, if we are talking
about a nibble/nybble (because I'm too lazy to type more binary digits):

~0000 -> 1111
~0001 -> 1110

which accounts for the problem discussed earlier in the thread.

To make things work the way you seemed to imagine:

~1111 -> 0000 # and thus, is False
~0000 -> 1111 # and thus, is True

ie a bitwise inter-change that works binary ints and booleans.


Where some (other) thinking may have come-adrift from Python's model, is
the mixing of objects/types, eg the 'truthiness' of any integer other
than 0. Also, whilst coercion from one type to another may work
satisfactorily in one 'direction', it may not be so amenable in reverse.


Another bemusing (OP) point was the concept of "-+~1". I'd never, ever,
think of doing that! Hey, maybe that says something about me?

The term "unary operator" involves the word "one". Rather than
"operator", the "one" is the number of "operands". (yes, you know this)
However, having already talked about the infrequency with which
unary-operators are employed, the idea of nesting (is that the word?) a
series of unary-operators, almost blew my mind. Why? Please show an
example scenario...


Finally, there is the process of "over-loading" operators. Thus, "1 + 2"
translates to "add the value 2 to 1"; whereas "a" + "b" means
"concatenate" the two strings. In both cases, the result becomes a third
value. When we choose the correct terminology, the words for "+" are
different - as are the resultant processes!

We could also code "instance_a + instance_b". What does this mean?
Addition? Concatenation? Bitwise?

If I tell you that both are instances of MyClass, does that answer the
question?

The only way to work-out what craziness I hold in store, is to find
where MyClass is defined and look for the __add__() 'magic method'*. At
which point, you discover that the instance-attributes are split into
components, and the components merged together in a random sequence,
with today's date mixed-in for (no) good measure.

* or you could ask me
(although neither explanation will have a +impact on your mental health)


So, the fact that two object instances, eg an integer and a
floating-point number, both utilise the same operator-symbol, enables us
to draw analogies (and in this case, probably get it 100% correct), but
this does not imply a complete equivalence across-the-board
(particularly when crazy-people are let-loose with custom classes! Thus
"a" + "b" should not be pronounced "add", even though the operator looks
very much like the one we use to add two numbers!

For fun, and quickly now, what happens here:

2 + 2
2 + 2.0
2.0 + 2
2.0 + 2.0
"2" + "2"
2 + "2"
"2" + 2

(they're all 'the same', except the last two?three - aren't they???)

-- 
Regards,
=dn