Mailing-List: contact dev-help@mahout.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@mahout.apache.org
Received-SPF: pass (nike.apache.org: domain of dmcennis@gmail.com designates
 209.85.216.42 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=FgS2LEhp3WslCu4R8iLQ2FvJna1GnEcsey0AN24jUzlaUElPnn4gNFUCwDLL/nhKUU
         DXKMwVKRRHF0TmBhLX8luUJOLsl6soogVFe8pXwOXG+NoTf85wFBAyXdjqYIia3fbiMS
         aexPx3+Vafb0iqihuLNoj7bcpIa4VILzAhK4Y=
MIME-Version: 1.0
In-Reply-To: <4D92C13F.8030101@apache.org>
References: <AANLkTi=UtVcfDGD+ezHkuqVAFPvsuDrVWYk6kA5_sPmS@mail.gmail.com>
	<AANLkTinFDQ5LHsVTj5cdht_KT6OXs8tUii+Ei+NXUNNY@mail.gmail.com>
	<4D92C13F.8030101@apache.org>
Date: Wed, 30 Mar 2011 10:55:29 -0400
Message-ID: <AANLkTik0-DC2s4VRaNhOQGR58aJOE84OaYTi3UwQti2e@mail.gmail.com>
Subject: Re: new distance metric
From: Daniel McEnnis <dmcennis@gmail.com>
To: dev@mahout.apache.org, ssc@apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Sebastion,

It will be in the next patch.  Thanks for the heads up.

Daniel.

On Wed, Mar 30, 2011 at 1:35 AM, Sebastian Schelter <ssc@apache.org> wrote:
> Hi Daniel,
>
> We would also need a "distributed" implementation of this new metric. Cou=
ld
> you do that too?
>
> Shouldn't be too hard, just have a look at the other implementations in
> org.apache.mahout.math.hadoop.similarity.vector.
>
> --sebastian
>
>
> On 30.03.2011 00:40, Sean Owen wrote:
>>
>> Great, the best place for this would be a JIRA issue:
>> https://issues.apache.org/jira/browse/MAHOUT
>> I think it needs a bit of style work. For example, it ought to be very
>> much like TanimotoCoefficientSimilarity. If you copied that and edited
>> a few key methods, you'd be a lot closer I think.
>> I guess I find the core computation a little quirky:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 double distance =3D preferring1+preferring2 - 2*=
intersection;
>> =A0 =A0 =A0 =A0 =A0 =A0if(distance< =A01.0){
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0distance=3D1.0-distance;
>> =A0 =A0 =A0 =A0 =A0 =A0}else{
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0distance =3D -1.0 + 1.0 / distance;
>> =A0 =A0 =A0 =A0 =A0 =A0}
>>
>> distance is an int, so I think it's
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 int distance =3D preferring1+preferring2 - 2*int=
ersection;
>> =A0 =A0 =A0 =A0 =A0 =A0if(distance =3D=3D 0){
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0distance=3D1;
>> =A0 =A0 =A0 =A0 =A0 =A0}else{
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0distance =3D -1.0 + 1.0 / distance;
>> =A0 =A0 =A0 =A0 =A0 =A0}
>>
>> The resulting values are a little odd then -- it can return values in
>> [-1,0], or 1.
>>
>> By default I'd go with something more like "1.0 / (1.0 + distance)" I
>> suppose, though that's not somehow the one right way to map a distance
>> to a similarity -- though it would be consistent with
>> EuclideanDistanceSimilarity.
>>
>>
>> I'd actually welcome you to expand this idea and not just make a
>> "boolean pref" version of this but one that computes an actual
>> city-block distance for prefs with ratings too, for completeness.
>>
>>
>> I know this as "Manhattan distance". Is that an Americanism or is that
>> actually the more common name to anyone?
>>
>>
>>
>> On Tue, Mar 29, 2011 at 10:16 PM, Daniel McEnnis<dmcennis@gmail.com>
>> =A0wrote:
>>>
>>> Dear,
>>>
>>> Here is a patch of a new distance metric for the collaborative
>>> filtering modules - CityBlockDistance. =A0With the 0 - 1 binary split o=
n
>>> preference. KLDistance, AHDistance, and Symmetric KLDistance don't
>>> make sense.
>>>
>>> Daniel McEnnis.
>
>