2009-06-16 5 views
0

Pour trouver des sujets de tendance, j'utilise le score standard en combinaison avec une moyenne mobile:Les délais pour le score standard

z-score = ([current trend] - [average historic trends])/[standard deviation of historic trends] 

(Thank you very much, Nixuz)

Jusqu'à présent, je le fais comme suit:

Quoi qu'il en soit, pour les tendances historiques, je reviens tout simplement 24h. En supposant que nous avons 12 Janvier, 15:45 maintenant:

current_trend = [11 visites Jan, 3:45 - Jan 12, 03:45]

historic_trends = [10 visites Jan, 3:45 - 11 janv , 3:45] + coups [9 janv., 3:45 - 10 janv., 3:45] + coups [8 jan, 3:45 - 9 janv. 3:45] + ...

Mais est-ce vraiment adéquat? Ne serait-il pas mieux si je commençais toujours à 00:00 heures? Par exemple, cette façon pour les mêmes données (15h45):

current_trend = [11 visites Jan, 0:00 - Jan 12, 0:00]

historic_trends = [10 janvier Tubes, 00h00 - 11 janvier, 0:00] + coups [9 janv., 0:00 - 10 janvier, 0:00] + coups [9 janv., 0:00 - 9 janv., 0: 0] + ...

Je suis sûr que les résultats seraient différents. Mais quelle approche vous donnera de meilleurs résultats?

J'espère que vous avez compris ma question et que vous pouvez m'aider. :) Merci d'avance!

Répondre

1

Je pense que le problème que vous pouvez rencontrer avec votre implémentation actuelle est que les sujets qui étaient chauds il y a 23 heures influencent votre classement en ce moment. Le problème que je vois avec votre nouvelle mise en œuvre proposée est que vous nettoyez l'ardoise à minuit, donc les sujets qui étaient chauds tard la nuit dernière ne sembleront pas chauds tôt le lendemain matin (mais ils devraient le faire).

Je suggère que vous envisagiez de mettre en œuvre un Digg-style algorithm (désolé de lier à Digg) où la chaleur d'un sujet se désintègre avec l'âge. Vous pouvez le faire en comptant les hits/heure pour chacune des dernières périodes de 24 heures puis diviser chaque période-score en combien d'heures la période a eu lieu. Additionnez les 24 périodes pour obtenir le score.

hottness = (score24/24) + (score23/23) + ... + (score2/2) + score1

Où score24 est le nombre de "hits" qu'un sujet par la de un heure qui s'est produite il y a 24 heures (peut-être pas exactement les hits, mais le score normalisé pour cette heure).

De cette façon, les sujets qui étaient chauds il y a 24 heures seront toujours comptés dans votre algorithme, mais pas aussi fortement que les sujets qui étaient chauds il y a une heure.

+0

Merci, Bill le Lézard, pour cette astuce. Je ne connaissais pas cet algorithme simple mais c'est vraiment cool. Malheureusement, cela ne convient pas à mon objectif, c'est-à-dire trouver des sujets tendance. Mon algorithme filtre les sujets qui sont toujours chauds. Votre algorithme ne le fait pas, n'est-ce pas? ;) Mais c'est très utile pour moi, parce que je filtre aussi les liens tendance. Pour ce faire, c'est utile. Mais votre exemple concernant mon algorithme et les périodes de temps est très bon. Alors, recommandez-vous la première approche (tout simplement aller 24 heures au lieu de commencer à 0:00)? – caw

+1

Après être retourné et relisant la question à laquelle vous étiez lié, je vois le problème avec cette suggestion. Vous avez raison, il ne filtre pas les sujets qui sont toujours chauds.Digg et reddit fonctionnent avec cet algorithme car il ne s'applique qu'à un seul lien, pas à un sujet entier, qui pourrait être représenté par de nombreux hits. De vos deux choix, je préférerais revenir en arrière 24 heures, seulement parce que je ne peux pas imaginer comment le système fonctionnera à 1h du matin si vous revenez seulement à 0:00. Peut-être pourriez-vous diviser la différence (d'une certaine manière) et revenir seulement 12 heures en arrière? –

+0

Oui, la seconde approche échouerait probablement si certains sujets étaient chauds peu avant 0:00. Mais l'inconvénient est que je ne peux pas stocker les données des derniers jours quand je reviens toujours 24h ... – caw

Questions connexes