If Mahout were to use http://bit.ly/poisson-llr it would tend to favor new events in calculating the LLR score for later use in the threshold for whether a co or cross-occurrence iss incorporated in the model. This is very interesting and would be useful in cases where you can keep a lot of data or where recent data is far more important, like news. This is the time-aware G-test your are referencing as I understand it.

But it doesn’t relate to popularity as I think Ted is saying.

Are you looking for 1) personal recommendations biased by hotness in Greece or 2) things hot in Greece?

1) create a secondary indicator for “watched in some locale” the local-id uses a country-code+postal-code maybe but not lat-lon. Something that includes a good number of people/events. The the query would be user-id, and user-locale. This would yield personal recs preferred in the user’s locale. Athens-west-side in this case.
2) split the data into locales and do the hot calc I mention. The query would have no user-id since it is not personalized but would yield “hot in Greece”

Ted’s “Christmas video” tag is what I was calling a business rule and can be added to either of the above techniques.

On Nov 11, 2017, at 4:01 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:

So ... there are a few different threads here.

1) LLR but with time. Quite possible, but not really what Johannes is
talking about, I think. See http://bit.ly/poisson-llr for a quick
discussion.

2) time varying recommendation. As Johannes notes, this can make use of
windowed counts. The problem is that rarely accessed items should probably
have longer windows so that we use longer term trends when we have less
data.

The good news here is that this some part of this is nearly already in the
code. The trick is that the down-sampling used in the system can be adapted
to favor recent events over older ones. That means that if the meaning of
something changes over time, the system will catch on. Likewise, if
something appears out of nowhere, it will quickly train up. This handles
the popular in Greece right now problem.

But this isn't the whole story of changing recommendations. Another problem
that we commonly face is what I call the christmas music issue. The idea is
that there are lots of recommendations for music that are highly seasonal.
Thus, Bing Crosby fans want to hear White Christmas
<https://www.youtube.com/watch?v=P8Ozdqzjigg> until the day after christmas
at which point this becomes a really bad recommendation. To some degree,
this can be partially dealt with by using temporal tags as indicators, but
that doesn't really allow a recommendation to be completely shut down.

The only way that I have seen to deal with this in the past is with a
manually designed kill switch. As much as possible, we would tag the
obviously seasonal content and then add a filter to kill or downgrade that
content the moment it went out of fashion.

On Sat, Nov 11, 2017 at 9:43 AM, Johannes Schulte <
[EMAIL PROTECTED]> wrote:
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB