On May 5, 2006, at 5:11 PM, Mark Volkmann wrote:

> On 5/5/06, Robert Klemme <shortcutter / googlemail.com> wrote:
>> 2006/5/5, Logan Capaldo <logancapaldo / gmail.com>:
>> >
>> > On May 5, 2006, at 4:44 PM, Robert Klemme wrote:
>> >
>> > > The most notable exception I am aware of is this:
>> > >
>> > > irb(main):060:0> 2.eql? 2.0
>> > > => false
>> > > irb(main):061:0> 2 == 2.0
>> > > => true
>> > >
>> > > A Hash uses eql?
>> > >
>> > > HTH
>> > >
>> > > robert
>> >
>> > Based on this I would amend your explanation with
>> >
>> > #eql?   -- Equivalence with structure and type
>> > #==     -- Equivalence with structure
>> > #equal? -- Identity
>>
>> I'd leave it at "equivalence" for == and eql? because for most types
>> they behave the same. Basically every class's author is free what she
>> considers "equivalence". Equivalence is a mathematical term with  
>> clear
>> cut meaning and all implementations that satisfy these criteria are
>> compatible with the std lib (Hash, Enumerable methods etc.)
>
> So why is it useful to have both == and eql?
> Are there cases where you want them to behave differently?
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>

Well the post that sparked my response and "clarification" is one  
such case.

2.eql? 2.0 is false, 2 == 2.0 is true

I imagine the major difference is == potentially calls coerce