From: jweirich@...
Date: 2001-07-29T13:27:12+09:00
Subject: [ruby-talk:18723] Re: Ruby as opposed to Python?

    Paul> For those who don't know, the Python world is currently
    Paul> engaged in a heated argument about whether to change
    Paul> division from 5/2==2 to 5/2==2.5 Ruby has the same int/int
    Paul> behaviour and I have a feeling that you'll have the same
    Paul> argument someday.

>>>>> "Kent" == W Kent Starr <elderburn@mindspring.com> writes:

    Kent> Sorry, but I don't see the 'problem' here. Both Ruby (1.63)
    Kent> and Python (1.52) exhibit the following behaviour:

    Kent> 5 / 2 == 2
    Kent> 5.0 / 2 == 2.5

    Kent> So where's the 'problem'? Is this not 'correct' behavior?

Depends upon your definition of 'correct'.  I've somewhat followed
this debate on the python group and there is a lot of people on both
sides of the fence.  Those who "grew up" in statically typed languages
have no problem with integer division between integers.  However, a
dynamically typed language (e.g. Ruby and Python) suffer a particular
problem in this regard (see below).

    Kent> Is it not right to 'assume' that integer objects will do
    Kent> 'integer arithmetic' whilst floating point objects do
    Kent> 'floating point' arithmetic?

Integers and reals are more or less interchangable in most any
mathematical formula involving +, - or *.  I can write

    def f(a,b,c)
      (a+b)*c
    end

and get the a reasonable result no matter the numeric type of a, b or
c.  Division, however, is quite different.

    def g(a,b,c)
      (a+b)/c
    end

will either do truncating division or floating division, depending
upon the type of the argument.  I have a hard time imagining a formula
designed for floating division that would yield reasonable results
when given integers.

The key is that integer and float division are two separate
mathematical operations, and it makes more sense for the formula
(rather than the operands) to choose the type of division.

This isn't a problem with statically typed languages because the type
of the operands are know statically at compile time.

Currently, to guarantee the correct semantics for division, one must
hope the correct types are passed to your formula, or do something
along the lines of the following.

    a.to_i / b.to_i      (when you want truncating division)
    a.to_f / b           (for non-truncating division)

Guido describe the problem (and his proposed solutions for Python)
much better than I do.  See PEP 238 for his take on things
(http://python.sourceforge.net/peps/pep-0238.html).

Of all the recent changes to Python, this is the only one that I've
seen that may need addressing in Ruby someday.  

    Kent> After all, the way of the world is that neurons do 'neuron
    Kent> things' and T-cells do 'T-cell things'. So the floating
    Kent> point vs integer arithmetic seems 'right' to me. Perhaps I
    Kent> am being too simplistic. If so, please forgive me.

Does this make sense?

-- 
-- Jim Weirich     jweirich@one.net    http://w3.one.net/~jweirich
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct, 
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)