On Sat, Jun 05, 2004 at 09:24:28AM +0900, Jim Weirich wrote:
> Paul Brannan wrote:
> >On Fri, Jun 04, 2004 at 09:48:00AM +0900, Jim Weirich wrote:
> >>The truth is that Ruby's / operator is broken.
> >
> >I strongly disagree.  It is mathn that is broken, not the / operator.
> 
> Hi Paul!  I still think / is broken, even without considering mathn.
> There are two separate operations intdiv and floatdiv with different 
> semantics.  / will do one or the other, but you don't know which one it 
> is unless you know the exact types of the operands.  I don't know of a 
> single algorithm where this polymorphism is useful.  And *every* use of 
> / must process (check or convert) any operand that comes from outside 
> your local code.  This is broken in my opinion.

That's exactly what I tried to express in this RCR... polymorphism in
this case is not that good. Thanks for your good explanation.  

There wouldn't be a problem if // would be the integer division
operator, then mathn would work correctly, because it doesn't matter
whether float_div or rational_div is used for / (except for precision
and speed).

> This is one area where (IMHO) Python took the right choice.  (I can't 
> believe I said that).

Well, I believed that's how Python works as well. But in Python (2.3):

  >>> 1 / 2
  0

  >>> 1 // 2
  0

  >>> 1.0 // 2
  0.0

  >>> 1.0 / 2
  0.5

  >>> 1 / 2.0
  0.5

So they have the same "problem" as we in Ruby. But AFAIK, they can
better control the impacts than Ruby can (limited to module scope?).

IMO, Ruby 2.0 "should" behave this way:

  1 / 2     # => 0.5 or Rational(1/2)
  1 // 2    # => 0
  1.0 // 2  # => 0 (any good reason to return 0.0 here?)

With selector namespaces in Ruby 2.0 (?), and the addition of the //
operator, we could go this way. Old libraries could overload / to behave
as is Ruby < 2.0, whereas new libraries could use the new behaviour.

Regards,

  Michael