Random opdracht met counter

[FloggingHank]

Hi,

Mijn zaak is als volgt: Voor een onderzoek op mijn werk gaan er 3 groepen mensen gemaild worden. Deze mensen uit deze groepen komen via een link in de mail op een voor hun aangepaste pagina (dus 3 pagina's) . maar nu waar het om gaat:

Op deze pagina zal iedere gebruiker uit een groep een random opdracht krijgen (gewoon een tekst-zin). De bak met random opdrachten is 15 stuks. Maar nu loop je met de randomheid natuurlijk het risico dat je in een heel raar geval enkele van de 15 opdrachten niet te zien krijgt (je kunt ook 50 maal achter elkaar 6 gooien met een dobbelsteen).

Het idee is dus dat de pagina weet welke opdrachten reeds getoond zijn en de 'random' opdracht daar op aan past.

Hebben jullie enig idee hoe ik dit kan aanpakken? Het liefste zou ik een database vermijden maar ik gok dat ik hier niet aan ga ontkomen.

[mithras]

Wil je de resultaten van je onderzoek de prullenbak in verwijzen? Random heet niet voor niets random, je moet onder geen enkel beding de selectie laten afhangen van een externe factor. Ik zou eerder kijken naar je power factor en sample size om jezelf van een een bepaalde significantie te verzekeren. Dan hoef je niet te sjoemelen met je data.

Mocht je het toch wel willen: sla de gemaakte testen op in een file (makkelijst: de 1, 2 of 3 met een delimiter bijvoorbeeld een komma of puntkomma). Bij een nieuw request pak je de totale samples, daar haal je alle gemaakte testen uit en uit het restant trek je een nieuw item.

[dotcode]

Je kan toch alle opdrachten in een bak gooien en als opdracht 1 er uit is gaat je volgende trekking over alle opdrachten zonder opdracht 1. De laatste krijgt de overgebleven opdracht.

[FloggingHank]

dotcode schreef op donderdag 01 december 2011 @ 12:06:
Je kan toch alle opdrachten in een bak gooien en als opdracht 1 er uit is gaat je volgende trekking over alle opdrachten zonder opdracht 1. De laatste krijgt de overgebleven opdracht.

Probleem is dat er 15 vragen in de bak zitten en er rond de 400 mensen in ene groep zitten. In ene ideaal geval komen alle 15 opdrachten evenveel aan de beurt.

[TERW_DAN]

Je zult hier wel iets van een database moeten gebruiken (hoe simpel dan ook), of het tenminste serverside opslaan.


Wat je kunt doen is nadat een opdracht gegeven is, deze uit de array gooien met opdrachten, tot die leeg is, die weer vullen met de 15 opdrachten en opnieuw beginnen. Dit is dan niet echt random meer te noemen.

Om eerlijk te zijn, als je 400 mensen hebt met 15 opdrachten, dan is de kans dat er opdrachten niet of nauwelijks tussen zitten niet zo heel groot. Ik zou me er niet druk om maken eigenlijk.

[Acid_Burn]

Tja.. waarom gewoon niet sequentieel uitdelen.. 1..15.. en dan weer 1..15. Als je een uniforme verdeling wilt hebben heeft dat gewoon hetzelfde resultaat.

edit: TERW_DAN zegt hetzelfde geloof ik

[ Voor 12% gewijzigd door Acid_Burn op 01-12-2011 12:13 ]

[TERW_DAN]

@Acid_Burn, daar komt het dan wel op neer inderdaad. Hooguit dat de volgorde anders is op de manier die ik beschreef, maar het resultaat is precies hetzelfde.

[FloggingHank]

TERW_DAN schreef op donderdag 01 december 2011 @ 12:09:
Je zult hier wel iets van een database moeten gebruiken (hoe simpel dan ook), of het tenminste serverside opslaan.


Wat je kunt doen is nadat een opdracht gegeven is, deze uit de array gooien met opdrachten, tot die leeg is, die weer vullen met de 15 opdrachten en opnieuw beginnen. Dit is dan niet echt random meer te noemen.

Om eerlijk te zijn, als je 400 mensen hebt met 15 opdrachten, dan is de kans dat er opdrachten niet of nauwelijks tussen zitten niet zo heel groot. Ik zou me er niet druk om maken eigenlijk.

Ja dit lijkt mij inderdaad de beste oplossing. Nu is het echter alleen wel zo dat ik php en mysql in jaren niet meer heb aangeraakt, heb jij wellicht een term die ik hiervoor het beste kan googlen? voor een tutorialtje ofzo

[OkkE]

Wat mij een vrij simpele oplossing lijkt, zet alle vragen in een database en hou in een veld bij hoe vaak de vraag al getoond is; bij start is dit voor allemaal 0. Selecteer bij openen van de website één vraag waarbij je sorteert op "aantal keer getoond, oplopend". Zodat altijd de vraag die het minst vaak geweest is, geselecteerd wordt. Het is dan niet echt random, elke vraag zal ongeveer even vaak voorkomen, maar dat lijkt niet zo'n probleem te zijn?

TERW_DAN schreef op donderdag 01 december 2011 @ 12:53:
Tja, maar als je dat doet, dan kun je net zo goed die dingen sequentieel uitdelen zoals Acid_Burn al eerder aangaf.

@TS: Een manier is een array of tabel te pakken, die je vult met alle data, en je iedere keer dat je er 1 ding uit selecteert die eruit mikt. De volgende keer wordt je keuze dus met 1 vermindert (je random getal ligt dus iedere keer tussen de 1 en de lengte van je tabel/array). Als die lengte 0 is, dan vul je hem opnieuw en voer je hetzelfde truukje uit.

Hier is overigens niet veel random aan. Als ik zou vragen om iets randoms en ik zou dit krijgen... dan denk ik niet dat ik helemaal blij zou zijn

Mijn idee was ook meer een zetje in de juiste richting en de query ook nog heel simpel houden.

Ik vind de manier van de vraag steeds uit het array gooien zodat je "pool" steeds kleiner wordt ook iets beter. Maar uiteindelijk is het inderdaad op beide manieren niet meer random. Ik zou het gewoon compleet random doen denk ik, 400 deelnemers en 15 vragen, dan is de kans wel héél klein dat er een vraag overgeslagen wordt.

[ Voor 56% gewijzigd door OkkE op 01-12-2011 13:04 ]

[TERW_DAN]

Tja, maar als je dat doet, dan kun je net zo goed die dingen sequentieel uitdelen zoals Acid_Burn al eerder aangaf.

@TS: Een manier is een array of tabel te pakken, die je vult met alle data, en je iedere keer dat je er 1 ding uit selecteert die eruit mikt. De volgende keer wordt je keuze dus met 1 vermindert (je random getal ligt dus iedere keer tussen de 1 en de lengte van je tabel/array). Als die lengte 0 is, dan vul je hem opnieuw en voer je hetzelfde truukje uit.

Hier is overigens niet veel random aan. Als ik zou vragen om iets randoms en ik zou dit krijgen... dan denk ik niet dat ik helemaal blij zou zijn

[FloggingHank]

TERW_DAN schreef op donderdag 01 december 2011 @ 12:53:
Tja, maar als je dat doet, dan kun je net zo goed die dingen sequentieel uitdelen zoals Acid_Burn al eerder aangaf.

@TS: Een manier is een array of tabel te pakken, die je vult met alle data, en je iedere keer dat je er 1 ding uit selecteert die eruit mikt. De volgende keer wordt je keuze dus met 1 vermindert (je random getal ligt dus iedere keer tussen de 1 en de lengte van je tabel/array). Als die lengte 0 is, dan vul je hem opnieuw en voer je hetzelfde truukje uit.

Hier is overigens niet veel random aan. Als ik zou vragen om iets randoms en ik zou dit krijgen... dan denk ik niet dat ik helemaal blij zou zijn

Klinkt als een goede manier, heb echter geen idee hoe ik dit moet gaan aanpakken met php en mysql maar dat moet ik maar gaan onderzoeken dan. Tnx iig!

[RM-rf]

FloggingHank schreef op donderdag 01 december 2011 @ 11:54:

Het idee is dus dat de pagina weet welke opdrachten reeds getoond zijn en de 'random' opdracht daar op aan past.

gewoon met een Cookie ?

mits je zeker weet dat die persoon ook op dezelfde client de pagina bezoekt binnen een bepaalde tijd de opdrachten afloopt is datd e eenvoudigste manier om bij te houden of hij bepaalde elementen al gehad eheft en dubbele 'opdrachten' te vermijden...

als je voorheen geen serverside gegenereerde pagina gebruikt om die opdrachten weer te geven hoef je dat dan ook niet te doen als je de afgehandelde opdrachten via een cookie opslaat.

een cookie kan enkel een string bevatten, maar door die bv op te slaan als "[1,2,3,4,5]" kun je hieruit weer makkelijk een Array met ID's laten genereren

[ Voor 55% gewijzigd door RM-rf op 01-12-2011 13:26 ]

[OkkE]

RM-rf schreef op donderdag 01 december 2011 @ 13:23:
gewoon met een Cookie ?

Ik had het idee dat er 400 verschillende bezoekers zijn die elk maar één random vraag moeten krijgen, maar dat elke vraag wel (minimaal 1x) aan bod moet komen. In theorie kan het natuurlijk gebeuren dat er één van de 15 vragen nooit getoond wordt binnen die 400x, vandaar dat 'het systeem' moet weten welke nog nooit geweest is.