Ska göra en internetapplikation som ska visa listor med diverse saker. Man ska kunna rösta på varje objekt i listan, och till varje objekt finns x antal stjärnor beroende på röstsnittet ( YouTube-liknande med poängskala 1-5). Listan ska sedan sorteras sedan efter det mest populära.
I nuläget räknas rösterna på följande sätt - väldigt simpelt:
De variabler som finns är "total_votes" och "total_points" för varje objekt man kan rösta på. Så röstar jag t.ex. 5 på något, adderas 1 till "total_votes" och sedan 5 till "total_points".
För att få ut snittet och hur många stjärnor som ska visas tar man inte helt oväntat "total_points" delat på "total_votes" och får på så sätt fram snittet.
MEN...
Det är som sagt för simpelt. Jag måste även ta hänsyn till antal röster / tiden samt även poängskalan 1-5
Röstar 100 personer på samma objekt på 1 dag måste den få högre poäng än om 100 personer röstar samma objekt på t.ex. 1 månad. Samtidigt om dessa 100 pers ger 5 poäng var under en månad (eller vecka etc.), måste det ge mer poäng än om 100 pers röstar på 3 poängaren under en dag.
Det går ju få tag på alla möjliga tider, som t.ex. registrera när objektet lades till listan, när senaste rösten lades osv, samt få ut skillnaden i tid i sekunder, minuter, timmar, dagar, veckor etc. Förstår att man måste använda sig av dessa siffror på något sätt men vet inte hur man ska utveckla en användbar funktion av det.
Det svåra är ju även hur man ska räkna ut snittet för hur många stjärnor som ska visas.... ger man mer än 5 poäng så kommer ju tillslut snittet ligga på t.ex 5.7 på en skala 1-5.
Det slog mig... Finns det någon redan utarbetad algortim för hur en bra lista ska rankas och poängsättas?!
Jag skulle personligen använda en algoritm som ger en viss vikt till varje röst, och denna vikt minskar exponentiellt med tiden. En sådan algoritm skulle minska relevansen av en röst med tiden, men ändå hålla nuvarande medelvärde konstant tills det kommer en ny röst. Sen gäller det förstås att skriva algoritmen på rätt sätt.
I praktiken så gäller det att hitta en bra avvägning mellan prestanda och noggrannhet. I praktiken skulle jag nog ha valt ut tre-fyra tidsintervall, t ex nu-a dag sedan, 1 dag sedan-1 vecka sedan, 1 vecka sedan-1 månad sedan, 1 månad sedan-oändligheten, och sedan viktat de närmare tidsperioderna högre.
En fråga som jag ställde förut som inte innehåller någon viktning, men visar hur man räknar ut medelbetyg med hjälp av en SQL-fråga finns här: http://www.webforum.nu/showthread.php?t=145971
Det kanske kan vara något att utgå från åtminstone.
Tack för tipset, det är nog en bra bit åt rätt håll.
Är riktigt seg i huvudet såhär på måndagskvällen men gör ett försök. Om du har något mer konkret exempel på hur du tänkte hur man skulle kunna applicera denna vikt på ett vettigt sätt så är det mycket välkommet! (som du sa; skriva algoritmen på rätt sätt hehe)
Om jag förstår dig rätt så skulle man kunna göra något i denna stil:
röst på något inom
1 dag, vikt: 10
1 vecka, vikt: 6
1 månad, vikt: 3
1 månad < oändlig,vikt: 1
Gör man detta absolut enklaste vägen dvs. multiplicerar röstpoängen(1-5) med vikten, skulle det alltså innebära att en länk som röstas 5p inom 1 dag, får 50 poäng gentemot en som legat ett år som då bara får 5poäng. Hmm fan du det kanske inte e så dumt det här ändå. Väldigt simpelt mitt ex. men som sagt... något åt det hållet
Det här får jag det till:
Varje term ser ut så här:
$rating_avg**$rating_count**$weight
*rating_xxx plockar du ut ur databasen med lämpliga SQL-funktioner (select count, avg) $rating_avg är alltså medelrating för en viss tidsperiod och $rating_count är antalet personer som har röstat för nämnda period. weight är en fördefinierad vektor som definierar vikten för varje tidsperiod.
Du summerar termerna, och delar sedan med (sum($rating_count)*sum($weight))
Om inte måndagströttheten har även mig i sitt grepp har du då en funktion som alltid ger tillbaka ett värde mellan [0,5] om databsen inte är korrupt. Dock har denna metod egenheten att ratingen ändras när röster glider över från en period till en annan. Och så får tidsperioderna inte överlappa varandra heller.***
266 ms totalt · 4 externa anrop · v20260731065814-full.86ec41c2
