negative integer division

[Jive Dadson]

Mike Meyer wrote:
> 
> Jive Dadson <jdadson at yahoo.com> writes:
> 
> > Python does it right.  C is allowed to do it anyway it likes, which was
> > a stupifyingly horrible decision, IMHO.
> 
> C only does it wrong if you think that C is a high level language. 

I didn't say it does it wrong.  I said it does it anyway it likes --
maybe right, maybe wrong.  There *is* a right way, IMHO.  Python does it
that way.

> [C] isn't - it's a portable assembler.

I've heard that many times, but it makes no sense to me.  By definition,
the syntax of an assembly language closely resembles the format of
individual hardware instructions for a particular processor.  An
assembler assembles individual hardware instructions.  Back in the day,
Unix (written largely in C) and Steve Johnson's pcc (the *portable* C
compiler) together constituted a big leap forward.  Implementing Unix on
new processors was infinitely easier than porting OS's written in
assembly language.  So I disagree on two counts: C code is not entirely
portable, (for example, division and mod may not work the same on two
different machines), and a C compiler is most certainly not an
assembler.


> Now, I'll agree with you if you want to argue that some machines do
> negative integer division in stupifyingly horrible ways.

That's why I think it was a stupifyingly horrible decision. 
Understandable, but in the end an s.h.d. nonetheless.  It would have
been okay to define / and % correctly, in the mathematical sense, but
also provide functions quick_div() and quick_mod() that were guaranteed
to work correctly only when both arguments were positive.  The way they
did it is just too error prone, akin to early optimization.  It's bitten
me before, when I was called on to port code (which I did not write)
from one machine to another.  Having standard operators with
under-defined behavior is just inviting trouble: long debugging
sessions, or worse, unexplained failures in the field.  Of course you
and I would avoid all the pitfalls at the start. :-)

... and now back to your regularly scheduled Python newsgroup.