Integer division (was: Case-sensitivity... (was: Damnation!))

[François Pinard]

> François Pinard <pinard at iro.umontreal.ca> writes:

> > Mathematicians' opinion surely has stronger value than mine here, but I do
> > remember having written any generic algorithm in which it is meaningful
> > that `i / j' sometimes mean truncating, sometimes not, depending on the
> > type of the operands.  So spelling `int()' would not be a problem for me.

Serious typo above, sorry.  I wanted to write "... but I do NOT remember
...".  This because I never felt the need of a generic `/' operator which
sometimes truncate AND sometimes do not, that specifying that I want
truncation, through using `int()' or a special operator, would not hit me.

Bernhard Herzog <herzog at online.de> écrit:

> It just occurred to me that with the also planned unification of ints
> and long ints the sematics of i / j where both are ints will have to be
> carefully chosen.  If you just cast them to floats before the division
> you might end up with inaccurate results or overflows even if j is a
> divisor of i.

Very true.  Automatic casting to float is not an attractive solution.

> If i/j does not do integer division, the only real solution seems to be
> what Moshe Zadka proposed: introduction of a rational type with (long)
> int numerator/denominator pairs.  I'm not sure I'd like that. It sounds
> like a serious performance hit.  You could easily end up carrying around
> a lot of precision that's not needed in many applications.

This is _so_ right.  The memory and CPU requirements might easily get out of
bounds, to the point of insanity.  The cure would be worse than the illness.

> This could be alleviated by introducing a special integer division
> operator.

Yes.  I feel that deep discussions on these things is a bit premature.
However, it might be useful to recognise now that changing the meaning of
i/j opens many difficult problems, and should be pondered with extreme care.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard