Mailing-List: contact user-help@mahout.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@mahout.apache.org
Received-SPF: pass (athena.apache.org: domain of jake.mannix@gmail.com
 designates 209.85.212.42 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=I6C+7M6qEnXAovKbxh7S7KP879yS0EnCIrMc/J3kfGsx3vhHts2khXs58VkdHT9tfE
         ua4OxjkyDcM5qvMQRDf7Ra/cI4v91JOlKCtOvO4krL9WNwhu8U7bAVj+x9Af8F0iBh7+
         9wB9A3i2sD3SD4oaTJDoVWXlaQqgHdOTNgvyI=
MIME-Version: 1.0
In-Reply-To: <AANLkTil1oup38jFQ5DH4NMkdkdNCY0XNAd06XXGD0XF3@mail.gmail.com>
References: <AANLkTinFkP-k1uPkojE9KggXsgSujt3-axqWt8oT3Ryz@mail.gmail.com>
	<AANLkTimk61KEApkj_VmAm5hNjbrzniO5fGrrF5dVrRuX@mail.gmail.com>
	<AANLkTilcnNbgq5ItrAdIF92gGJB06kF-sHyfpSDvOc_a@mail.gmail.com>
	<AANLkTil1oup38jFQ5DH4NMkdkdNCY0XNAd06XXGD0XF3@mail.gmail.com>
From: Jake Mannix <jake.mannix@gmail.com>
Date: Thu, 3 Jun 2010 23:09:52 -0700
Message-ID: <AANLkTin-IQzdXF01A6RCGsCHvRfr8lg9Zl20dfT9CsFh@mail.gmail.com>
Subject: Re: Understanding the SVD recommender
To: user@mahout.apache.org
Content-Type: multipart/alternative; boundary=000fea893762064bdb04882e2d55

--000fea893762064bdb04882e2d55
Content-Type: text/plain; charset=ISO-8859-1

This reminds me: I never moved over the "folding-in" code from decomposer.
Not that it's particularly complex, but it would probably be useful in
"utils" at
least.

  -jake

On Thu, Jun 3, 2010 at 10:48 PM, Ted Dunning <ted.dunning@gmail.com> wrote:

> You are correct.  The paper has an appalling treatment of the folding in
> approach.
>
> In fact, the procedure is dead simple.
>
> The basic idea is to leave the coordinate system derived in the original
> SVD
> intact and simply project the new users into that space.
>
> The easiest way to see what is happening is to start again with the
> original
> rating matrix A as decomposed:
>
>   A = U S V'
>
> where A is users x items.  If we multiply on the right by V, we get
>
>   A V = U S V' V = U S
>
> (because V' V = I, by definition).  This result is (users x items) x (items
> x k) = users x k, that is, it gives a k dimensional vector for each user.
>  Similarly, multiplication on the left by U' gives a k x items matrix
> which,
> when transposed gives a k dimensional vector for each item.
>
> This implies that if we augment U with new user row vectors U_new, we
> should
> be able to simply compute new k-dimensional vectors for the new users and
> adjoin these new vectors to the previous vectors.  Concisely put,
>
> ( A     )     ( A V     )
> (       ) V = (         )
> ( A_new )     ( A_new V )
>
> This isn't really magical.  It just says that we can compute new user
> vectors at any time by multiplying the new users' ratings by V.
>
> The diagram in figure one is hideously confusing because it looks like a
> picture of some kind of multiplication whereas it is really depicting some
> odd kind of flow diagram.
>
> Does this solve the problem?
>
> On Thu, Jun 3, 2010 at 9:26 AM, Sean Owen <srowen@gmail.com> wrote:
>
> > Section 3 is hard to understand.
> >
> > - Ak and P are defined, but not used later
> > - Definition of P has UTk x Nu as a computation. UTk is a k x m
> > matrix, and Nu is "t" x 1. t is not defined.
> > - This only makes sense if t = m. But m is the number of users, and Nu
> > is a user vector, so should have a number of elements equal to n, the
> > number of items
> > - Sk * VTk is described as a k x "d" matrix but d is undefined
> > - The diagram suggests that VTk are multiplied by all the Nu, which
> > makes more sense -- but only if Nu are multiplied by VTk, not the
> > other way. And the diagram depicts neither of those.
> > - Conceptually I would understand Nu x VTk, but then P is defined by
> > an additional product with Uk
> >
> > In short... what?
> >
> >
> > On Thu, Jun 3, 2010 at 4:15 PM, Ted Dunning <ted.dunning@gmail.com>
> wrote:
> > > Fire away.
> > >
> > > On Thu, Jun 3, 2010 at 3:52 AM, Sean Owen <srowen@gmail.com> wrote:
> > >
> > >> Is anyone out there familiar enough with this to a) discuss this paper
> > >> with me or b) point me to another writeup on the approach?
> > >>
> > >
> >
>

--000fea893762064bdb04882e2d55--