Mailing-List: contact user-help@mahout.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@mahout.apache.org
Received-SPF: pass (nike.apache.org: domain of srowen@gmail.com designates
 209.85.214.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4D42776F8E08814BB499E724E294A4950628FFF4@EX-MB-02.vancloa.cn>
References: <4D42776F8E08814BB499E724E294A4950628FFF4@EX-MB-02.vancloa.cn>
Date: Tue, 20 Sep 2011 11:37:21 +0100
Message-ID: 
 <CAEccTywAxzK2MLb-a6nSvGiOeQyV1W6bBWHfvr2xE8CR+G2oww@mail.gmail.com>
Subject: Re: why use the job 'itemIDIndex' to convert the itemid to index?
From: Sean Owen <srowen@gmail.com>
To: user@mahout.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

It is a problem -- but should be are. IDs are hashed to 31-bit
integers, so the probability of collision is small. However you don't
have to have too many items before it's probable that some two have
collided. (IIRC, that's about 2 ^ (31/2) ? )

In practice it doesn't hurt much. It just means that data from two
different items has been mixed up and treated as if it was all from
one item. That's not ideal, but has a tiny overall effect on
recommendations.

Another practical tip: if your item IDs all fit into an unsigned int
already, then the hash function won't mix them up at all as all of
them will hash to themselves.

2011/9/20 =E5=BC=A0=E7=8E=89=E4=B8=9C <zhangyudong@vancl.cn>:
> I am trouble with this problem, if two itemids are mapped to the same ind=
ex, then how to compute the similarity between them?
>
>
>