Hi Craig, On Wed, Aug 18, 2010 at 11:15 AM, Craig Taverner <cr...@amanzi.com> wrote: >> >> Limit meaning in this run? Or at all times? The first is ok, the >> second not. I guess you mean exiting after I have computed already 10 >> new relationships right? >> > > Well, actually I was aiming for an algorithm that would converge on a stable > state. This means, if no new information is being added to the graph, with > enough runs of randomly adding relationships and trimming low weighted ones, > the graph would stabilize with a fixed set of reasonably high weighted > relationships. This would provide fast answers to your queries. If you > always add 10 new ones, the convergence would be to a complete graph with > everyone related to everyone, which would hit query performance badly (and > make for a very, very big graph containing mostly low value information).
Mmm we cannot limit the number of relationships in this app. One the most important features is that we'll keep looking for good matches for the user. Sure we can avoid storing low value relationships to avoid having an almost complete graph. We'll also limit the calculation of the score to users that match some factors, like age, geographical region, language, etc. In this way the graph might get dense but it won't really grow into a complete graph. What do you think? > > Then as new information is added (new users added), the graph automatically > adjusts to a new stable state (now including relationships of high value to > those new users). > > This might be interesting to keep the density low but I have to look >> at it since they way it works is that people see suggestions of other >> users that have a good match. I can't probably make them disappear >> suddenly. >> > > The trimmer should only remove low value relationships. These are > relationships that have been scored as not being a good match, so the user > should not see anything disappear, since they would presumably be looking at > good matches. In principle I guess a user could look through all their > matches, and it is possible they might see low scoring ones which are then > trimmed away. I do not see a problem with this, based on my limited > understanding of what you are after. We can choose not to store relationships with a score under N. In this we could end up calculating a possible match that we have already discarded. This would mean sacrificing CPU in favor of a less dense graph, but I think it might make sense. _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
