Hey Mark, The query isn't actually used anywhere on the site just yet. For the time being you draft against 7 rudimentary rules-based bots that aren't very good. I'm looking to take their AI to the next level!
The concept of adding a person is interesting. At the moment I'm relying on sheer volumes of data to get something useful. So for example the relationship between the cards Entomb and Exhume currently has a pickCount of 34 and a passCount of 12. By determining the strength of the relationship as 34/12 we can see that these two cards have a lot of Synergy. Therefore a bot can work out that if it's already got Entomb it should probably pick Exhume no matter what other cards are offered to it. So the data isn't really surfaced anywhere on the site. It is used in an algorithm that is approximately the following: 1) Look at all of the cards I've already chosen, and the cards that I'm being offered to choose from. 2) Find the "strength" of each relationship between the cards I've chosen and the cards I'm being offered, expressed as pickCount/passCount. 3) Use this strength in conjunction with a number of other rules to determine what the "correct" pick is and make that pick. It seems that by introducing the concept of 'Person' we'd have a lot more traversal to do to get the strength of the relationship between any two given cards? I'm trying to think of how else this information could be programatically useful for the alogorithm. I suppose that you could "weight" drafters based on their skill and ignore the less skilled drafters to ensure that you have better quality information. At the cost of inserting the extra data, do you expect that this extra node type could save us some query time somehow? Thanks again! Ben. On Thursday, June 5, 2014 11:47:29 AM UTC+1, Mark Needham wrote: > > Ben, > > Cool, liking the site! > > I think I roughly understand. One question though: is the query you > included here used on the home page? http://www.cubetutor.com/draft/1 Or > is that for another page? How do you display that data? > > I think you want to introduce the concept of a 'Draft' so you'd have > something like this: > > [image: Inline images 1] > > By having that concept I think you'd start to see other interesting > queries that you can write rather than just aggregates on card counts. > > What do you think? > > Mark > > > > On 5 June 2014 11:23, Ben Titmarsh <benti...@gmail.com <javascript:>> > wrote: > >> Hey Mark, >> >> Thanks for your continued help. The output does include Schema Index as >> follows: >> >> >> - ==> Filter(pred="(any(-_-INNER-_- in >> Collection(List(Literal(Oblivion Ring), Literal(Lightning Bolt), >> Literal(Mana Leak), Literal(Mulldrifter), Literal(Llanowar Elves), >> Literal(Counterspell), Literal(Rancor), Literal(Ponder), Literal(Doom >> Blade), Literal(Preordain), Literal(Evolving Wilds), Literal(Incinerate), >> Literal(Bonesplitter), Literal(Brainstorm), Literal(Vampire Nighthawk), >> Literal(Terramorphic Expanse), Literal(Acidic Slime), Literal(Path to >> Exile), Literal(Eternal Witness), Literal(Duress), Literal(Porcelain >> Legionnaire), Literal(Journey to Nowhere), Literal(Swords to Plowshares), >> Literal(Lingering Souls), Literal(Faith's Fetters), Literal(Hymn to >> Tourach), Literal(Qasali Pridemage), Literal(Sakura-Tribe Elder), >> Literal(Magma Jet), Literal(Lightning Helix), Literal(Rakdos Cackler), >> Literal(Shriekmaw), Literal(Cultivate), Literal(Bloodbraid Elf), >> Literal(Fact or Fiction), Literal(Faithless Looting), Literal(Birds of >> Paradise), Literal(Electrolyze), Literal(Man-o'-War), Literal(Kodama's >> Reach), Literal(Keldon Marauders), Literal(Flametongue Kavu), >> Literal(Dismember), Literal(Yavimaya Elder))) where >> Property(toCard,name(0)) == -_-INNER-_-) AND hasLabel(toCard:Card(0)))" >> , _rows=45, _db_hits=1034) >> - ==> PatternMatch(g="(fromCard)-['r']-(toCard)", _rows=45, _db_hits= >> 201894) >> - ==> SchemaIndex(identifier="fromCard", _db_hits=0, _rows=1, label= >> "Card", query="Literal(Ultimate Price)", property="name") >> >> >> Does this indicate that my initial query should be modified somehow to >> include the index? >> >> On the general point about the domain not feeling graphy, I understand >> what you are saying. I'll explain my problem space a bit and perhaps you >> can see something that I've missed. >> >> What I'm doing here is collecting data on cards that people are >> "drafting". The process is very similar to when you were in P.E. at high >> school and the teacher put you and another person at the front of the class >> to pick players for your football team one at a time. What people do >> through my app is pick cards instead of football players. >> >> There are 30,000 possible cards that they can choose from but rather than >> offering all 30,000 at once the player is asked to make a choice from just >> 15 of the available card pool. Once they've made a choice they are asked >> again to make a decision from a DIFFERENT 14 cards, then 13, then 12 and so >> on. This process of picking from 15 to 1 cards is repeated 3 times until >> they end up with 45 cards. >> >> Each time the player makes a choice I increment the 'pickCount' on the >> relationship for the card that has been chosen against all of the cards >> that were previously chosen. In addition I increment the passCount for >> each card that was not chosen, against each card that has already been >> chosen, >> >> From this I can infer the strength of the relationship between any two >> cards from the card pool. The data is coming from real "drafts" that are >> taking place on my site: www.cubetutor.com/draft/1. The idea behind >> gathering this data is to build an advanced AI that can draft cards using >> this relationship strength metric as one facet of a card picking algorithm. >> >> I hope that makes sense? So I'm gathering all of this data from real >> life drafts. I just can't fathom any other potential entities from my >> domain? It's entirely possible that a graph database just isn't >> appropriate for a domain where you have one node type and each node has one >> relationship type to potentially every other node. I suppose it would be >> sort of equivalent to a PERSON -[:KNOWS]-PERSON model if you assumed that >> every person knew almost every other person in the world! >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Neo4j" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to neo4j+un...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to neo4j+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
