The REALLY bad thing about Python lists ..

[Greg Ewing]

Russell Wallace wrote:
> 
> a simple
> arithmetic operation on ints will compile into a section of code with
> multiple branch instructions *even in the overwhelmingly most common
> case where negative operands will never occur*.

If you know that the operands will never be negative, declare them
as unsigned so that the compiler has the chance to optimise. Or give
the language another operator that complains about negative numbers.

> different humans
> *disagree* on what the logical thing for negative integer division to
> return is.

Sigh. This is because language designers have big holes in
their heads when they try to map two different operations onto
the same operator. It's not a case of one being more "logical"
than the other -- both are useful, depending on the circumstances.
The *logical* thing to do is to provide two operators (four,
actually, counting the corresponding flavours of division).

> I'd much rather explicitly add 60 and know where I stand.

That only works if you know that you're never going to go
more than once around the clock in the negative direction.
If you don't know that, the correction you have to apply
is hairier still.

I'd much rather have an honest, well-defined "wrap around"
operator that I can rely on, even if I have to look up the
language definition now and then, than have to wade through 
code that's been obfuscated to work around its absence.

-- 
Greg Ewing, Computer Science Dept,
+--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg at cosc.canterbury.ac.nz	   +--------------------------------------+