```On Thu, Jun 10, 2004 at 02:33:41AM +0900, Bret Jolly wrote:
> Michael Neumann <mneumann / ntecs.de> wrote in message news:<20040605102959.GA2225 / miya.intranet.ntecs.de>...
> > On Sat, Jun 05, 2004 at 07:03:03PM +0900, Mark Sparshatt wrote:
> > > Try this
> > >
> > > >>> 1/2
> >  0
> > > >>> from __future__ import division
> > > >>> 1/2
> >  0.5
> > > >>> 1//2
> > > 0
> > >
> > > That's using version 2.3.3
> >
> > Ah thanks.... would be great to see this in Ruby too (without breaking
> > existing code).
>
> It would *not* be great to see this in Ruby: the quotient of two integers
> should be a rational, not a float.  The behavior given by the mathn library
> is the correct one.  If the quotient of two rationals is a float, you get
> severe errors using the matrix standard library with ill-conditioned matrices.
> The Hilbert matrix, which arises in the the theory of least-square fits, is
> a good example.
>
> [...]
>
> irb(main):004:0> ((m=hilbert_float(15))*m.inv).biggest_offdiag
> -569.0       # INCREDIBLY WRONG!
>
> The quotient of two integers is an exact rational.  To make the
> quotient default to (inexact) floats can lead to appalling numerical
> errors as I have just shown.

I'm not sure I understand you correctly, or you me.  My "suggestion"
was, to make / a floating point division regardless of it's arguments
unless "mathn" is required. But // would always be integer division.

Or to describe it in a little example:

1 / 2   # => 0.5
1 // 2  # => 0

require 'mathn'
1 / 2   # => 1/2

This would break less existing code, as the result of a rational
division compared to a floating point division is more exact, whereas
ration vs. integer division yields very different results (up to 0.5).
Don't get me wrong, now it would break very much code, but if the
applications would use // as integer div, then it would break less code
when they start using mathn.

Regards,

Michael

```