David has said it all - here are some additional remarks.

"Michael Neumann" <mneumann / ntecs.de> schrieb im Newsbeitrag
news:20040602165312.GA25813 / miya.intranet.ntecs.de...
> Hi,
>
> I know that introducing new syntax into Ruby is probably far from being
> accepted by matz....
>
> Every now and then I accidentially pass an integer to a method and am
> surprised than I get a wrong result. The reason is that the method
> expected floats as arguments and not integers. These kind of bugs are
> very hard to find, IMHO.
>
> Imagine the following method:
>
>   def meth(a, b)
>     a / b
>   end
>
> It works if a, b or both are floats, but not if both are integers.
>
> Instead you have to write:
>
>   a.to_f / b
>
> or
>
>   a / b.to_f
>
> or
>
>   1.0 * a / b
>
> ..

You might better use Kernel#Float because of this:

>> Float 1
=> 1.0
>> Float "1"
=> 1.0
>> Float "1.0"
=> 1.0
>> Float nil
TypeError: cannot convert nil into Float
        from (irb):8:in `Float'
        from (irb):8
>> nil.to_f
=> 0.0

> My proposal is to add a /. operator, that treats both arguments as
> floats, so that
>
>   1 /. 2        # => 0.5
>
> Or alternatively:
>
>   class Float
>     alias fdiv /
>   end
>
>   class Integer
>     def fdiv(divisor)
>       self.to_f / divisor
>     end
>   end
>
>   a.fdiv(b)
>
> Any comments?
>
> IMHO, even better would be if / would always mean floating point
> division and an extra // operator would mean integer division, but it's
> to late to change now (even for Ruby 2.0) :-)

I strongly oppose that one: Operators are overloaded and if I have two
int's I want integer division, if I have to floats I want float division.
And I don't want that changed, because often code is written with integer
divisions in mind.  All sorts of indexing calculations depend on int math.

Kind regards

    robert