OK, then (everything that's available at index time, I'll say it's constant): (Math.log(z) / Math.LN10) (not sure what you mean with Math.LN10) is constant, I'll call it c1
((y * t) / 45000) = (y/4500)*t --> y/4500 is constant, I'll call it c2. c1+(c2 * t) = c1 + (c2 * (CreationDate - now) / 1000) --> c2 / 1000 is also constant, I'll call it c3. Then, your ranking formula is: c1 + (c3 * (creationDate - now)). In solr, this will be: &sort=sum(c1,product(c3,ms(creationDate, NOW))). I haven't tried it but if my arithmetics are correct (I'm a little bit rusty with that), that should work and should be faster than doing the whole thing at query time. Of course, "c1" and "c3" must be indexed as fields. Regards, Tomás On Thu, Jun 2, 2011 at 9:46 AM, Richard Hodsdon <hodsdon.rich...@gmail.com>wrote: > Thanks for the response, > > You are correct, but my pseudo code was not. > this line > var t = (CreationDate - 1131428803) / 1000; > should be > var t = (CreationDate - now()) / 1000; > > This will cause the items ranking to depreciate over time. > > Richard > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/Sorting-algorithm-tp3014549p3014961.html > Sent from the Solr - User mailing list archive at Nabble.com. >
