[ruby-core:25677] Re: [Bug #2121] mathn/rational destroys Fixnum#/, Fixnum#quo and Bignum#/, Bignum#quo

On Sun, Sep 20, 2009 at 3:51 PM, brian ford <[e-mail]> wrote:
> Hi,
>
> On Sun, Sep 20, 2009 at 9:19 AM, Rick DeNatale <[e-mail]> =
wrote:
>>
>> Actually in most languages which I've encountered, and that's quite a
>> few. Mixed mode arithmetic has been implemented by having some kind of
>> rules on how to 'overload' arithmetic operators based on the
>> arguments, not by having different operator syntax.
>>
>> And those rules are usually based on doing conversions only when
>> necessary so as to preserve what information can be preserved given
>> the arguments,
>>
>> So, for example
>>
>> =A0 =A0integer op integer - normally produces an integer for all of the
>> 'big four' + - * /
>> =A0 =A0integer op float =A0 =A0- normally produces a float, as does floa=
t op integer
>>
>> As new numeric types are added, in languages which either include them
>> inherently or allow them to be added, this pattern is usually
>> followed.
>
> This is a distinctly different issue. Mixed-type arithmetic in Ruby is
> handled by the #coerce protocol.

Not sure why it's distinctly different, what happens when a new
numeric class is introduced, e.g. Rational, is what we seem to be
talking about.

And #coerce is just an implemention detail whose motivation seems to
be in line with what I'm saying.

>
>>>
>>> As for which symbol to select, what about '/.' for real(a)/real(b).
>>
>> Well, first the problem we are talking about is Rationals, not Floats,
>> and second, what happens as more numeric classes are introduced.
>
> The mathn library aliases Fixnum and Bignum #quo to #/. By default
> #quo returns a Float. Rational redefines #quo to produce a Rational
> rather than a Float.
>
> But what class of object is not the point. It could be Complex. The
> point is that integers are not closed under division so you *must*
> choose one of the options if you expect a value when dividing any two
> integers.

Right, and Ruby like most other languages made a choice to use integer
division, rather than converting.

Smalltalk made another choice, to return a Fraction when dividing two integ=
ers.

In both cases, the / operator is effectively overloaded, and can
return other kinds of numbers given different pairs of arguments.

>
> The division operation is so fundamental that assumptions about it
> should not change under your feet. Having a separate operator that
> returns a different type when integral division would be undefined
> allows both normal algorithms and mathy stuff to coexist nicely. In my
> algorithms, I *never* want my integral division to suddenly return
> something non-integer. In my math codes, I almost never want my
> quotient truncated or rounded.

Yes, I agree that I don't want the rules to change under my feet.  I
want a / b to give me the same integer as Ruby 1.8 sans mathn gives me
when a and b are integers, and I expect 1 / 1.2 to give me the same
float etc.  I'm not sure I see the need for additional operators, but
that's a side issue.

 Run Paint Run suggested that 1.9 SHOULD produce a Rational or maybe a
float as the result of dividing two integers, because "that what Guido
would do."

The brutal facts are that there's is lots of code written in Ruby, and
lots of that code uses integer divide, and would be broken if this
change were made, it would be the same as silently including mathn in
every existing ruby program, which seems like a bad idea.

Guess what! I did some experimentation with irb1.9 and was pleasantly
surprised to find that 1.9 seems to be doing quite the opposite, it
acts just like the "thought experiment" proposal I suggested here.

$ irb1.9
irb(main):001:0> Rational
=3D> Rational
irb(main):002:0> 1/2
=3D> 0
irb(main):003:0> Rational(1)
=3D> Rational(1, 1)
irb(main):004:0> 1.to_r
=3D> Rational(1, 1)

Which I guess indicates that "that's what Matz would do."


--=20
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale