[Python-3000] Math in Python 3.0

Tim Peters tim.peters at gmail.com
Sat May 13 00:08:09 CEST 2006


[Fredrik Johansson]
> The information "n is odd" appears once as "n&1" and once in the name
> of a function. The point is that any if statement has the following
> form:
>
>     if conditionX:
>         consequence of conditionX
>
> So the if statement *inevitably* references conditionX twice, although
> it may do so in form of a function or variable explicitly named
> "conditionX" or implicitly in terms of code that the reader interprets
> as "conditionX"/"consequence of conditionX".
>
> Raymond's example code says "consequence of conditionX" explicitly
> ("handle_odd"). That's what I think is rare.

I'd say it's non-existent.  I'm sure Raymond meant "handle_odd()" to
be _read_ as "whatever code you want to do in case it's odd", not as
"call the function named 'handle_odd'".

> Your code illustrates my point:
>
>     if a & 1:
>         a = b-a
>
>     while a & 1 == 0:
>         a >>= 1
>
> Here the heads read "conditionX" ("a is odd/even"), but "a = b-a" and
> "a >>= 1" certainly aren't as trivial as "handle_odd", so in this case
> the repetitiveness Raymond speaks about doesn't exist.

Except Raymond didn't say anything about repetitiveness.  What he did say:

    IMO, functions like is_even() and is_odd() are clutter.  Also, the
    performance of &1 is unlikely to be matched function calls.

> The version
>
>     if isodd(a):
>         a = b-a
>
>     assert iseven(a)
>
>     while iseven(a):
>         a >>= 1
>
> seems more readable to me. The advantage is perhaps questionable in
> the context of any code that does bit manipulation (in which my mental
> model of integers automatically turns them into bit strings), but not
> all code that is concerned with whether a number is odd does that.

Eh -- pretty much the same to me.  "n & 1" is so obvious and easy to
write & to read that I wouldn't waste a new builtin (let alone two
;-)) on it either.

> Anyway, the particular example of isodd/iseven wasn't the intended
> topic of this thread. Better go ahead with that library so people can
> try it to decide if there's anything in it they like instead of
> arguing over trivialities on a mailing list :-)

But that's what mailing lists are for :-)


More information about the Python-3000 mailing list