From: Michael Neumann Date: 2004-06-05T18:32:09+09:00 Subject: Re: [RCR] Floating point division operator /. (or fdiv method) 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