[Architecture] Ensuring the statistical matchmaker works before Luxembourg

Kasper Markus kasper at markus.dk
Tue Jan 13 15:21:04 EST 2015


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/20150113/e0479c17/attachment-0001.html>


More information about the Architecture mailing list