[Architecture] Ensuring the statistical matchmaker works before Luxembourg

Andreas Stiegler stiegler at hdm-stuttgart.de
Wed Jan 14 04:27:31 EST 2015


Heyho Kasper,

 

Sorry for keeping it short, in a meeting atm:

The smm does not cover all the features we need. We only produced training data for the two smm scenarios.

With “smm as default”, I ment setting the SMM as the dispatch target in the gpii-default namespace and adding separate contexts for the rbmm scenarios.

 

It might be easier to just have 2 vlad pref sets with RBMM and SMM as the dispatch target in gpii defaut and switching between them for the senarios.

 

Best regards,

Andy

 

From: Kasper Markus [mailto:kasper at markus.dk] 
Sent: Wednesday, January 14, 2015 10:23 AM
To: Andreas Stiegler
Cc: architecture at lists.gpii.net
Subject: Re: [Architecture] Ensuring the statistical matchmaker works before Luxembourg

 

Hi Andy,

There is nothing in the system that allows identifying the device by ID and I think we're too late in attempting to implementing it seeing how it's less than 1 week until we're live in Luxembourg. We have talked about the ability to manually set contexts via the PCP, but that was never in scope for the review (and wouldn't have worked out in this case anyway, as the PCP in it's current shape wouldn't work on DTV nor Kiosk).

I think the idea of making the SMM default might be the best option - but this does mean that you would need to ensure that the SMM works in all the scenarios where we need matchmaking and SMM isn't specifically set as active (ie. when demoing the PMT, security, etc). In either case, we need to find a solution to this as soon as possible - the reason for preaching early integration for the past 6 months is to avoid being in situations like this 1 week ahead of the review...

~Kasper 

On 1/13/15 10:40 PM, Andreas Stiegler wrote:

Here is an example on how it should look or the dispatcher, but we need respective conditions.

https://www.dropbox.com/s/5i39u0yu59vkmyf/vladimir.json?dl=0 

 

Sorry for that. My information was that we manually set those context blobs to be always active (similar to the GPII-Default) for the sake of the review. Hence the context desc.

 

Best regards,

Andy

 

From: architecture-bounces at lists.gpii.net [mailto:architecture-bounces at lists.gpii.net] On Behalf Of Andreas Stiegler
Sent: Tuesday, January 13, 2015 10:26 PM
To: 'Kasper Markus'
Cc: architecture at lists.gpii.net
Subject: Re: [Architecture] Ensuring the statistical matchmaker works before Luxembourg

 

Heyho Kasper,

 

Oh, I’ve been  told that we would manually set that those context blobs are active. If not, we should add conditions to those two blops identifying that we are on the dtv or the vending machine. I sadly don’t know how we could tell that (and it somehow spoils the idea of those two scenarios with him not having any pref set entries for them). If there are conditions with something like “device ID” or so, that should do.

 

Other option: make the SMM default and add dispatcher overrides for the RBMM, but that would requiring altering the conditions and context blobs in the vlad profile, as then gpii-default would have to be SMM.

 

I think we should go with the first option: a condition for device-id or something equivalent that allows us to tell that we are on the DTV or the vending machine. If somebody could add that to those two context blobs along with a priority, all should be fine.

 

The two context blobs just serve the purpose of dispatching the call to the SMM, they are not required in any other regard.

 

Best regards,

Andy

 

From: Kasper Markus [mailto:kasper at markus.dk] 
Sent: Tuesday, January 13, 2015 9:21 PM
To: Andreas Stiegler
Cc: architecture at lists.gpii.net
Subject: Re: Ensuring the statistical matchmaker works before Luxembourg

 

Hi Andy,

Thanks for your reply!

The one thing I'm still not quite understanding is the "log in with the pref set and the respective context active". The decision of the active context is up to the minimatchmaker and based on the 'condition' blocks along with any priority on the context blocks. I might be missing something obvious, but I just wanted to make sure that this will work with Andres' work merged in as well.

Good luck on your Glasgow lectures,

Cheers,
~Kasper



On 1/13/15 3:00 PM, Andreas Stiegler wrote:

Hi Kasper,

 

The blocks in the pref set are only to ensure that the SMM I used (given the dispatcher is included in the Luxemburg version).

The idea behind those two SMM scenarios is, that both are scenarios where vlad encounters devices that he never used before (ticket machine, hotel screen), but were used by many other people already. So what the SMM does is searching through its database for users that have similarity to the other settings that vlad used in the past and infer settings for it (and magically, our training data for the review covers both the vending machine and the dtv well).

We did tests with the SMM here covering both scenarios. So unless vlads pref set changed, all should be fine. We were never able to test it with the actual vending machine or screen hardware of course.

 

Testing should be rather simple as the SMM is being deployed on the IDRC cloud. Once that’s done you should just be able log in with the pref set and the respective context active. The dispatcher will forward to the SMM and apply the settings.

 

The whole call chain works and was tested over here, but I don’t know if the dispatcher is already in.

 

If you want to install the SMM locally, just go to https://github.com/REMEXLabs/GPII-Statistical-Matchmaker , and follow the instructions (npm install and delete duplicate infusion inclues).

 

I’ll only be available very sporadically this week, as I’m giving guest lectures in Glasgow.

 

Best regards,

Andy

 

From: Kasper Markus [mailto:kasper at markus.dk] 
Sent: Tuesday, January 13, 2015 11:45 AM
To: Andreas Stiegler
Cc: architecture at lists.gpii.net Architecture
Subject: Ensuring the statistical matchmaker works before Luxembourg

 

Hi Andy,

Hope you've had a nice christmas and new year!

We're getting scarily close to the review meeting and in that connection I have some questions/requests for you:

*	For the vladimir scenario - there are some blocks describing that the STMM should be used (https://github.com/kaspermarkus/universal/blob/review3/testData/preferences/vladimir.json#L76-L87). These are modeled as context blocks, but it's not clear to me how the system would evaluate these blocks to be active.. Could you clarify this?
*	We have not yet tested any of the ST MM scenarios and it would be good to have done so as soon as possible. Since the ST MM is used in the scenarios of the Kiosk and DTV, the only people really able to test it properly pre-luxembourg would be Jasmin and Thomas respectively. So, would you be able to write up instructions to them on how to set everything up, deploy the ST MM and run the tests so they can try it out and we can find any potential issues before meeting up in luxembourg?

Cheers,
~Kasper

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gpii.net/pipermail/architecture/attachments/20150114/2fcd9523/attachment-0001.html>


More information about the Architecture mailing list