Re: [jira] Commented: (MAHOUT-165) Using better primitives hash for sparse vector for performance gains

[Grant Ingersoll <gs...@apache.org>]

On Sep 30, 2009, at 4:34 PM, Jake Mannix wrote:

> I didn't say that equals() should ignore name, I said the opposite -  
> equals
> and
> hashCode() should *only* take into account the contents and the  
> name, and
> not
> implementation (which means that hashCode() needs to stay in one  
> place and
> not get monkeyed with in subclasses.
>

Right, that is my understanding

> On Wed, Sep 30, 2009 at 1:18 PM, Sean Owen <sr...@gmail.com> wrote:
>
>> No I don't hear anyone wanting to make equals() ignore the name.
>> (Otherwise, hashCode() would have to ignore it as well.)
>>
>> JIRA also seems pretty laggy to me.
>>
>> On Wed, Sep 30, 2009 at 9:03 PM, Jake Mannix <ja...@gmail.com>
>> wrote:
>>> If we are not going to break the contract between equals() and
>> hashCode(),
>>> and we're having equals() *only* take into account the mathematical
>> contents
>>> and the name, then I'd say what we need to do is implement hashCode 
>>> () in
>> a
>>> top level class like AbstractVector.
>>>
>>> (Is something funny going on with JIRA?  Seems broken...)
>>

Re: [jira] Commented: (MAHOUT-165) Using better primitives hash for sparse vector for performance gains

[Sean Owen <sr...@gmail.com>]

(PS yeah that was my fault for misreading the original message.)

On Thu, Oct 1, 2009 at 11:39 AM, Grant Ingersoll <gs...@apache.org> wrote:
>
> On Sep 30, 2009, at 4:34 PM, Jake Mannix wrote:
>
>> I didn't say that equals() should ignore name, I said the opposite -
>> equals
>> and
>> hashCode() should *only* take into account the contents and the name, and
>> not
>> implementation (which means that hashCode() needs to stay in one place and
>> not get monkeyed with in subclasses.
>>
>
> Right, that is my understanding