Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 21DDD200D43 for ; Tue, 21 Nov 2017 10:29:05 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 20616160BFC; Tue, 21 Nov 2017 09:29:05 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 73645160BED for ; Tue, 21 Nov 2017 10:29:03 +0100 (CET) Received: (qmail 85833 invoked by uid 500); 21 Nov 2017 09:29:02 -0000 Mailing-List: contact user-help@predictionio.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@predictionio.apache.org Delivered-To: mailing list user@predictionio.apache.org Received: (qmail 85818 invoked by uid 99); 21 Nov 2017 09:29:02 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Nov 2017 09:29:02 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 87E14C35F5 for ; Tue, 21 Nov 2017 09:29:01 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.179 X-Spam-Level: *** X-Spam-Status: No, score=3.179 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, KAM_LIVE=1, KB_WAM_FROM_NAME_SINGLEWORD=0.2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=vicomtech-org.20150623.gappssmtp.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id DowoGgWCL44W for ; Tue, 21 Nov 2017 09:28:54 +0000 (UTC) Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id EF4F55FDE0 for ; Tue, 21 Nov 2017 09:28:53 +0000 (UTC) Received: by mail-wm0-f49.google.com with SMTP id y82so9278286wmg.1 for ; Tue, 21 Nov 2017 01:28:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vicomtech-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5fNiGO6DYxfqcLx6bTBJZT4hP65XBgjfq4165LC2W8k=; b=Jel60cBGA/uc2Cnt7RlLZ6gdo79imVUcZYuFKbBgblxGbfHLxisHLR4+eYSypMo03A G1UVPkHlQyNGT4bMjSJj53KfXvcLmxFrSQnqjl4yHDpOW+yFFeses2UH48J+taqwxHYP bEd07L369MMP81F8hYm364+aLc6cEYsr7JRHurgMFyW5VwBHLQnLdMVdfYFzaYraMcUr 8U/aO/y1dbdOdMPT2Pz4dJT7v2uiWt6tanc1DV4R2hiRiAwxt+artHQaseWMH3YAKhIe WHD6nfiFDjScccr/IVbhYEWUJ06joChIJPQPu/c58jjkJ0lZPpGhaDrMqPCPGRbJeVdI C81Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5fNiGO6DYxfqcLx6bTBJZT4hP65XBgjfq4165LC2W8k=; b=feo9lydAWUUYtGHSHuGhHFRtj4rHvcRc5Lhxi4fy/1sR1fOqmKBvPVomDfyK0WClqM e1025d6tqnliCA4Wx4kaU38rl/aoF4ghQaJMZL8YmzUsSqs8QnQYVIxi2dxkYevaueWP 7fW09h6hB4/gdyFgUpxVVe2kbHBBnnRhwumbF8WFmFrHOsqT5gr554ZvqgbK1vn82ur4 ydDNjD84PfN02PF6/yc4LLuG/a1Ngm1lyFMNi7jP9y9116Z40hmLamSQbLtCjcGisyzy f8FlWYUbkM61o1GEuUCIWcHvfCcDgWN9v4xjN9IxHPkmjC2o4Nm6/PsPUWv+blDjlLyk eONg== X-Gm-Message-State: AJaThX7koWgP5aert4pk0/l2aFopX5K+5Cfw9XOCW/PWZUwdLSUAap4J qnLyBj1jaxThnQhHLadg6dIyLV0Kotl9nj30jRjpYQ== X-Google-Smtp-Source: AGs4zMYksV+7ip8AKYD5a+c9Z4ynEBfhHexD6JJpHShiaaVuc2/QyrrHayqShr2xQSmWsnypLb0KTmX6geP+B2S5ybg= X-Received: by 10.28.51.133 with SMTP id z127mr760595wmz.139.1511256533279; Tue, 21 Nov 2017 01:28:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.45.201 with HTTP; Tue, 21 Nov 2017 01:28:52 -0800 (PST) In-Reply-To: <10DDF943-D837-4152-8920-9BC3395C18A4@occamsmachete.com> References: <10DDF943-D837-4152-8920-9BC3395C18A4@occamsmachete.com> From: =?UTF-8?Q?Noelia_Os=C3=A9s_Fern=C3=A1ndez?= Date: Tue, 21 Nov 2017 10:28:52 +0100 Message-ID: Subject: Re: Log-likelihood based correlation test? To: user@predictionio.apache.org Cc: Andrew Troemner , actionml-user Content-Type: multipart/alternative; boundary="001a11442a10d4bfb7055e7ad490" archived-at: Tue, 21 Nov 2017 09:29:05 -0000 --001a11442a10d4bfb7055e7ad490 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Pat, If I understood your explanation correctly, you say that some elements of PtP are removed by the LLR (set to zero, to be precise). But the elements that survive are calculated by matrix multiplication. The final PtP is put into EleasticSearc and when we query for user recommendations ES uses KNN to find the items (the rows in PtP) that are most similar to the user's history. If the non-zero elements of PtP have been calculated by straight matrix multiplication, and I'm assuming that the P matrix only has 0s and 1s to indicate which items have been purchased by which user, then the elements of PtP are either 0 or greater to or equal than 1. However, the scores I get are below 1. So is the KNN using cosine similarity as a metric to calculate the closest neighbours? And is the results of this cosine similarity metric what is returned as a 'score'? If it is, when it is greater than 1, is this because the different cosine similarities are added together i.e. PtP, PtL... ? Thank you for all your valuable help! On 17 November 2017 at 19:52, Pat Ferrel wrote: > Mahout builds the model by doing matrix multiplication (PtP) then > calculating the LLR score for every non-zero value. We then keep the top = K > or use a threshold to decide whether to keep of not (both are supported i= n > the UR). LLR is a metric for seeing how likely 2 events in a large group > are correlated. Therefore LLR is only used to remove weak data from the > model. > > So Mahout builds the model then it is put into Elasticsearch which is use= d > as a KNN (K-nearest Neighbors) engine. The LLR score is not put into the > model only an indicator that the item survived the LLR test. > > The KNN is applied using the user=E2=80=99s history as the query and find= ing items > the most closely match it. Since PtP will have items in rows and the row > will have correlating items, this =E2=80=9Csearch=E2=80=9D methods work q= uite well to find > items that had very similar items purchased with it as are in the user=E2= =80=99s > history. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D that is the simple explanation > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Item-based recs take the model items (correlated items by the LLR test) a= s > the query and the results are the most similar items=E2=80=94the items wi= th most > similar correlating items. > > The model is items in rows and items in columns if you are only using one > event. PtP. If you think it through, it is all purchased items in as the > row key and other items purchased along with the row key. LLR filters out > the weakly correlating non-zero values (0 mean no evidence of correlation > anyway). If we didn=E2=80=99t do this it would be purely a =E2=80=9CCoocc= urrence=E2=80=9D > recommender, one of the first useful ones. But filtering based on > cooccurrence strength (PtP values without LLR applied to them) produces > much worse results than using LLR to filter for most highly correlated > cooccurrences. You get a similar effect with Matrix Factorization but you > can only use one type of event for various reasons. > > Since LLR is a probabilistic metric that only looks at counts, it can be > applied equally well to PtV (purchase, view), PtS (purchase, search terms= ), > PtC (purchase, category-preferences). We did an experiment using Mean > Average Precision for the UR using video =E2=80=9CLikes=E2=80=9D vs =E2= =80=9CLikes=E2=80=9D and =E2=80=9CDislikes=E2=80=9D > so LtL vs. LtL and LtD scraped from rottentomatoes.com reviews and got a > 20% lift in the MAP@k score by including data for =E2=80=9CDislikes=E2=80= =9D. > https://developer.ibm.com/dwblog/2017/mahout-spark-correlated-cross- > occurences/ > > So the benefit and use of LLR is to filter weak data from the model and > allow us to see if dislikes, and other events, correlate with likes. Addi= ng > this type of data, that is usually thrown away is one the the most powerf= ul > reasons to use the algorithm=E2=80=94BTW the algorithm is called Correlat= ed > Cross-Occurrence (CCO). > > The benefit of using Lucene (at the heart of Elasticsearch) to do the KNN > query is that is it fast, taking the user=E2=80=99s realtime events into = the query > but also because it is is trivial to add all sorts or business rules. lik= e > give me recs based on user events but only ones from a certain category, = of > give me recs but only ones tagged as =E2=80=9Cin-stock=E2=80=9D in fact t= he business rules > can have inclusion rules, exclusion rules, and be mixed with ANDs and ORs= . > > BTW there is a version ready for testing with PIO 0.12.0 and ES5 here: > https://github.com/actionml/universal-recommender/tree/0.7.0-SNAPSHOT Ins= tructions > in the readme and notice it is in the 0.7.0-SNAPSHOT branch. > > > On Nov 17, 2017, at 7:59 AM, Andrew Troemner > wrote: > > I'll echo Dan here. He and I went through the raw Mahout libraries called > by the Universal Recommender, and while Noelia's description is accurate > for an intermediate step, the indexing via ElasticSearch generates some > separate relevancy scores based on their Lucene indexing scheme. The raw > LLR scores are used in building this process, but the final scores served > up by the API's should be post-processed, and cannot be used to reconstru= ct > the raw LLR's (to my understanding). > > There are also some additional steps including down-sampling, which scrub= s > out very rare combinations (which otherwise would have very high LLR's fo= r > a single observation), which partially corrects for the statistical probl= em > of multiple detection. But the underlying logic is per Ted Dunning's > research and summarized by Noelia, and is a solid way to approach > interaction effects for tens of thousands of items and including secondar= y > indicators (like demographics, or implicit preferences). > > > *ANDREW TROEMNER*Associate Principal Data Scientist | salesforce.com > Office: 317.832.4404 > Mobile: 317.531.0216 > > > > > > On Fri, Nov 17, 2017 at 9:55 AM, Daniel Gabrieli > wrote: > >> Maybe someone can correct me if I am wrong but in the code I believe >> Elasticsearch is used instead of "resulting LLR is what goes into the AB >> element in matrix PtP or PtL." >> >> By default the strongest 50 LLR scores get set as searchable values in >> Elasticsearch per item-event pair. >> >> You can configure the thresholds for significance using the configuratio= n >> parameters: maxCorrelatorsPerItem or minLLR. And this configuration is >> important because at default of 50 you may end up treating all "indicato= r >> values" as significant. More info here: http://actionml.com/docs >> /ur_config >> >> >> >> On Fri, Nov 17, 2017 at 4:50 AM Noelia Os=C3=A9s Fern=C3=A1ndez < >> noses@vicomtech.org> wrote: >> >>> >>> Let's see if I've understood how LLR is used in UR. Let P be the matrix >>> for the primary conversion indicator (say purchases) and Pt its transpo= sed. >>> >>> >>> Then, with a second matrix, which can be P again to make PtP or a matri= x >>> for a secondary indicator (say L for likes) to make PtL, we take a row = from >>> Pt (item A) and a column from the second matrix (either P or L, in this >>> example) (item B) and we calculate the table that Ted Dunning explains = on >>> his webpage: the number of coocurrences that item A *AND* B have been >>> purchased (or purchased AND liked), the number of times that item A *OR= * >>> B have been purchased (or purchased OR liked), and the number of times >>> that *neither* item A nor B have been purchased (or purchased or >>> liked). With this counts we calculate LLR following the formulas that T= ed >>> Dunning provides and the resulting LLR is what goes into the AB element= in >>> matrix PtP or PtL. Correct? >>> >>> Thank you! >>> >>> On 16 November 2017 at 17:03, Noelia Os=C3=A9s Fern=C3=A1ndez >> > wrote: >>> >>>> Wonderful! Thanks Daniel! >>>> >>>> Suneel, I'm still new to the Apache ecosystem and so I know that Mahou= t >>>> is used but only vaguely... I still don't know the different parts wel= l >>>> enough to have a good understanding of what each of them do (Spark, ML= Lib, >>>> PIO, Mahout,...) >>>> >>>> Thank you both! >>>> >>>> On 16 November 2017 at 16:59, Suneel Marthi wrote= : >>>> >>>>> Indeed so. Ted Dunning is an Apache Mahout PMC and committer and the >>>>> whole idea of Search-based Recommenders stems from his work and insig= hts. >>>>> If u didn't know, the PIO UR uses Apache Mahout under the hood and he= nce u >>>>> see the LLR. >>>>> >>>>> On Thu, Nov 16, 2017 at 3:49 PM, Daniel Gabrieli >>>> salesforce.com> wrote: >>>>> >>>>>> I am pretty sure the LLR stuff in UR is based off of this blog post >>>>>> and associated paper: >>>>>> >>>>>> http://tdunning.blogspot.com/2008/03/surprise-and-coincidence.html >>>>>> >>>>>> Accurate Methods for the Statistics of Surprise and Coincidence >>>>>> by Ted Dunning >>>>>> >>>>>> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=3D10.1.1.14.5962 >>>>>> >>>>>> >>>>>> On Thu, Nov 16, 2017 at 10:26 AM Noelia Os=C3=A9s Fern=C3=A1ndez < >>>>>> noses@vicomtech.org> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I've been trying to understand how the UR algorithm works and I >>>>>>> think I have a general idea. But I would like to have a *mathematic= al >>>>>>> description* of the step in which the LLR comes into play. In the >>>>>>> CCO presentations I have found it says: >>>>>>> >>>>>>> (PtP) compares column to column using >>>>>>> *log-likelihood based correlation test* >>>>>>> >>>>>>> However, I have searched for "log-likelihood based correlation test= " >>>>>>> in google but no joy. All I get are explanations of the likelihood-= ratio >>>>>>> test to compare two models. >>>>>>> >>>>>>> I would very much appreciate a math explanation of log-likelihood >>>>>>> based correlation test. Any pointers to papers or any other literat= ure that >>>>>>> explains this specifically are much appreciated. >>>>>>> >>>>>>> Best regards, >>>>>>> Noelia >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >>> >>> >>> >>> >>> > > -- > You received this message because you are subscribed to the Google Groups > "actionml-user" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to actionml-user+unsubscribe@googlegroups.com. > To post to this group, send email to actionml-user@googlegroups.com. > To view this discussion on the web visit https://groups.google. > com/d/msgid/actionml-user/CAA2BRS%2Boj%2BNYDmsNNd2mYM1ZC5CgWwC71W3% > 3DEhrO9qeOiKyWXA%40mail.gmail.com > > . > For more options, visit https://groups.google.com/d/optout. > > --=20 Noelia Os=C3=A9s Fern=C3=A1ndez, PhD Senior Researcher | Investigadora Senior noses@vicomtech.org +[34] 943 30 92 30 Data Intelligence for Energy and Industrial Processes | Inteligencia de Datos para Energ=C3=ADa y Procesos Industriales member of: Legal Notice - Privacy policy --001a11442a10d4bfb7055e7ad490 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Pat,

If I understood= your explanation correctly, you say that some elements of PtP are removed = by the LLR (set to zero, to be precise). But the elements that survive are = calculated by matrix multiplication. The final PtP is put into EleasticSear= c and when we query for user recommendations ES uses KNN to find the items = (the rows in PtP) that are most similar to the user's history.

<= /div>If the non-zero elements of PtP have been calculated by straight matri= x multiplication, and I'm assuming that the P matrix only has 0s and 1s= to indicate which items have been purchased by which user, then the elemen= ts of PtP are either 0 or greater to or equal than 1. However, the scores I= get are below 1.

So is the KNN using cosine similarity as a m= etric to calculate the closest neighbours? And is the results of this cosin= e similarity metric what is returned as a 'score'?

If = it is, when it is greater than 1, is this because the different cosine simi= larities are added together i.e. PtP, PtL... ?

Thank you for a= ll your valuable help!

On 17 November 2017 at 19:52, Pat Ferrel <pat@occamsm= achete.com> wrote:
Mahout builds the model by doing matrix multipl= ication (PtP) then calculating the LLR score for every non-zero value. We t= hen keep the top K or use a threshold to decide whether to keep of not (bot= h are supported in the UR). LLR is a metric for seeing how likely 2 events = in a large group are correlated. Therefore LLR is only used to remove weak = data from the model.

So Mahout builds the model then it = is put into Elasticsearch which is used as a KNN (K-nearest Neighbors) engi= ne. The LLR score is not put into the model only an indicator that the item= survived the LLR test.

The KNN is applied using t= he user=E2=80=99s history as the query and finding items the most closely m= atch it. Since PtP will have items in rows and the row will have correlatin= g items, this =E2=80=9Csearch=E2=80=9D methods work quite well to find item= s that had very similar items purchased with it as are in the user=E2=80=99= s history.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D that is the sim= ple explanation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
<= div>
Item-based recs take the model items (correlated items b= y the LLR test) as the query and the results are the most similar items=E2= =80=94the items with most similar correlating items.

The model is items in rows and items in columns if you are only using on= e event. PtP. If you think it through, it is all purchased items in as the = row key and other items purchased along with the row key. LLR filters out t= he weakly correlating non-zero values (0 mean no evidence of correlation an= yway). If we didn=E2=80=99t do this it would be purely a =E2=80=9CCooccurre= nce=E2=80=9D recommender, one of the first useful ones. But filtering based= on cooccurrence strength (PtP values without LLR applied to them) produces= much worse results than using LLR to filter for most highly correlated coo= ccurrences. You get a similar effect with Matrix Factorization but you can = only use one type of event for various reasons.

Si= nce LLR is a probabilistic metric that only looks at counts, it can be appl= ied equally well to PtV (purchase, view), PtS (purchase, search terms), PtC= (purchase, category-preferences). We did an experiment using Mean Average = Precision for the UR using video =E2=80=9CLikes=E2=80=9D vs =E2=80=9CLikes= =E2=80=9D and =E2=80=9CDislikes=E2=80=9D so LtL vs. LtL and LtD scraped fro= m rottentomatoes.co= m reviews and got a 20% lift in the MAP@k score by including data for = =E2=80=9CDislikes=E2=80=9D.=C2=A0https:/= /developer.ibm.com/dwblog/2017/mahout-spark-correlated-cross-occurences/

So the benefit and use of LLR is = to filter weak data from the model and allow us to see if dislikes, and oth= er events, correlate with likes. Adding this type of data, that is usually = thrown away is one the the most powerful reasons to use the algorithm=E2=80= =94BTW the algorithm is called Correlated Cross-Occurrence (CCO).

The benefit of using Lucene (at the heart of Elasticsearch)= to do the KNN query is that is it fast, taking the user=E2=80=99s realtime= events into the query but also because it is is trivial to add all sorts o= r business rules. like give me recs based on user events but only ones from= a certain category, of give me recs but only ones tagged as =E2=80=9Cin-st= ock=E2=80=9D in fact the business rules can have inclusion rules, exclusion= rules, and be mixed with ANDs and ORs.

BTW there = is a version ready for testing with PIO 0.12.0 and ES5 here:=C2=A0https://github.com/actionml/universal-recommend= er/tree/0.7.0-SNAPSHOT=C2=A0Instructions in the readme and notice = it is in the 0.7.0-SNAPSHOT branch.


On Nov 17, 2017, at 7:59 AM, Andrew Troem= ner <atroe= mner@salesforce.com> wrote:

I'll echo Dan here. He and I went through the raw Mahout libraries = called by the Universal Recommender, and while Noelia's description is = accurate for an intermediate step, the indexing via ElasticSearch generates= some separate relevancy scores based on their Lucene indexing scheme. The = raw LLR scores are used in building this process, but the final scores serv= ed up by the API's should be post-processed, and cannot be used to reco= nstruct the raw LLR's (to my understanding).

There a= re also some additional steps including down-sampling, which scrubs out ver= y rare combinations (which otherwise would have very high LLR's for a s= ingle observation), which partially corrects for the statistical problem of= multiple detection. But the underlying logic is per Ted Dunning's rese= arch and summarized by Noelia, and is a solid way to approach interaction e= ffects for tens of thousands of items and including secondary indicators (l= ike demographics, or implicit preferences).

ANDREW TROEMNER
Associate Principal Data Scientist |=C2=A0salesforce.com
Office: 317.832.4404
Mobile: 31= 7.531.0216


<= /div>


On Fri, Nov 17, 2017 at 9:55 AM, Daniel Gabrieli=C2=A0= <dgabrieli= @salesforce.com>=C2=A0wrote:
Maybe someone can correct me if I am wrong but in the code I believe= Elasticsearch is used instead of "resulting LLR is what goes into the AB element in matrix PtP or PtL."=

By= default the strongest 50 LLR scores get set as searchable values=C2=A0in E= lasticsearch per item-event pair.

You c= an configure the thresholds for significance using the configuration parame= ters:=C2=A0maxCorrelatorsPerItem or minLLR.=C2=A0=C2=A0And t= his configuration is important because at default of 50 you may end up trea= ting all "indicator values" as significant.=C2=A0 More info here:= =C2=A0http://actionml.com/docs/ur_config


=

On Fri, Nov 17, 2017 = at 4:50 AM Noelia Os=C3=A9s Fern=C3=A1ndez <noses@vicomtech.org> wrote:

Let's see if I'= ve understood how LLR is used in UR. Let P be the matrix for the primary co= nversion indicator (say purchases) and Pt its transposed.=C2=A0

Then, = with a second matrix, which can be P again to make PtP or a matrix for a se= condary indicator (say L for likes) to make PtL, we take a row from Pt (ite= m A) and a column from the second matrix (either P or L, in this example) (= item B) and we calculate the table that Ted Dunning explains on his webpage= : the number of coocurrences that item A=C2=A0AND=C2=A0B have been purchased (or pur= chased AND liked), the number of times that item A=C2=A0OR=C2=A0B have been purchase= d (or purchased OR liked), and the number of times that=C2=A0neither=C2=A0item A nor= B have been purchased (or purchased or liked). With this counts we calcula= te LLR following the formulas that Ted Dunning provides and the resulting L= LR is what goes into the AB element in matrix PtP or PtL. Correct? =C2=A0=C2=A0

Thank you!
=

On 16 Novemb= er 2017 at 17:03, Noelia Os=C3=A9s Fern=C3=A1ndez=C2=A0<noses@vicomtech.org<= wbr>>= =C2=A0wrote:
Wonderful! Th= anks Daniel!

Suneel, I'm still new to the Apac= he ecosystem and so I know that Mahout is used but only vaguely... I still = don't know the different parts well enough to have a good understanding= of what each of them do (Spark, MLLib, PIO, Mahout,...)

Thank you both!

On 16 November= 2017 at 16:59, Suneel Marthi=C2=A0<smarthi@apache.org>=C2=A0wrote:
Indeed so. Ted Dunning is an Apache Mah= out PMC and committer and the whole idea of Search-based Recommenders stems= from his work and insights.=C2=A0 If u didn't know, the PIO UR uses Ap= ache Mahout under the hood and hence u see the LLR.

On Thu, Nov 16, 2017 at 3:49 PM, Daniel Gabrieli=C2=A0<= ;dgabrieli@salesforce.com>=C2=A0wrote:


On Thu, Nov 16, 2017 at 10:26 AM Noelia Os=C3=A9s F= ern=C3=A1ndez <= noses@vicomtech.org> wrote:
Hi,

I've been trying to u= nderstand how the UR algorithm works and I think I have a general idea. But= I would like to have a=C2=A0mathematical description=C2=A0of the step in whi= ch the LLR comes into play. In the CCO presentations I have found it says:<= br>
(PtP) compares column to column using=C2=A0log-likelihood based cor= relation test


However, I have searched for "log-l= ikelihood based correlation test" in google but no joy. All I get are = explanations of the likelihood-ratio test to compare two models.=C2=A0

I would very much appreciate a math explanation of log-likelihood based co= rrelation test. Any pointers to papers or any other literature that explain= s this specifically are much appreciated.

Best regards,
Noelia












--=C2=A0
You received this message because you= are subscribed to the Google Groups "actionml-user" group.
= To unsubscribe from this group and sto= p receiving emails from it, send an email to=C2=A0actionml-user+unsubscribe@= googlegroups.com.
To post to this group, send email to=C2=A0actionml-user@g= ooglegroups.com.
To view this discussion on the web visit=C2=A0= https://groups.google.com/d/m= sgid/actionml-user/CAA2BRS%2Boj%2BNYDmsNNd2mYM1ZC5CgWwC71W3%= 3DEhrO9qeOiKyWXA%40mail.gmail.com.
For more options, visit=C2=A0https://groups= .google.com/d/optout.<= /font>



--

Noelia Os=C3=A9s Fern=C3=A1ndez, PhD
Senior Researcher |
Invest= igadora Senior

noses@vicomtech.org=
+= [34]=C2=A0943=C2=A030=C2=A092=C2=A030
Data Intelligenc= e for Energy and
Industrial Processes | Inteligencia
de Datos para En= erg=C3=ADa y Procesos
Industriales

=C2=A0=C2=A0

member of:=C2= =A0=C2=A0=C2=A0=C2=A0=C2= =A0

<= a href=3D"http://www.vicomtech.org/en/proteccion-datos" style=3D"color:blac= k" target=3D"_blank">Legal Notice - Privacy policy
--001a11442a10d4bfb7055e7ad490--