asked on
Alternatives to Rand() or mt_rand() - interested in perspectives.
I have an app that I'm developing. It's essentially a voting app - where user submissions are reviewed/voted upon/etc.
On the server side, when I originally began developing it, I figured the most democratic way of approaching submission selection would be through a randomized function like rand() or mt_rand(). In practice, however, both are turning out to be pretty crappy solutions since it's not true randomization. We currently have about 300 submissions - and as we're doing testing it seems like 40-50 of those entries are disproportionately "randomly" selected relative to all of the other ones.
So I'm thinking about approaching it a different way - each of which has it's potential pitfalls.
#1 - return to the app an array of all possible submissions - and have the app just iterate through them.
Pros of this: Every entry - provided the user keeps progressing - has a shot of being reviewed.
Cons of this: The array could potentially get quite large...which would mean at some point I'd have to segment it up (maybe only return a list of 100 possible candidates for review later on).
#2 - Instead of returning the list of possible candidates - handle the selection via sessions.
Pros of this: Every entry - provided the user keeps progressing - has a shot of being reviewed.
Cons of this: A huge number of open sessions possible.
What would you do in such a scenario? I've read that large numbers of sessions being open simultaneously can cause memory problems... How big of a concern ought that be? Or - is there a different way you can picture to approach this issue? :)
Thanks!
On the server side, when I originally began developing it, I figured the most democratic way of approaching submission selection would be through a randomized function like rand() or mt_rand(). In practice, however, both are turning out to be pretty crappy solutions since it's not true randomization. We currently have about 300 submissions - and as we're doing testing it seems like 40-50 of those entries are disproportionately "randomly" selected relative to all of the other ones.
So I'm thinking about approaching it a different way - each of which has it's potential pitfalls.
#1 - return to the app an array of all possible submissions - and have the app just iterate through them.
Pros of this: Every entry - provided the user keeps progressing - has a shot of being reviewed.
Cons of this: The array could potentially get quite large...which would mean at some point I'd have to segment it up (maybe only return a list of 100 possible candidates for review later on).
#2 - Instead of returning the list of possible candidates - handle the selection via sessions.
Pros of this: Every entry - provided the user keeps progressing - has a shot of being reviewed.
Cons of this: A huge number of open sessions possible.
What would you do in such a scenario? I've read that large numbers of sessions being open simultaneously can cause memory problems... How big of a concern ought that be? Or - is there a different way you can picture to approach this issue? :)
Thanks!
PHP
Last Comment
Ray Paseur
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Actually that's a really good idea (the counting of the number of times each element has been presented - and then just using the select order (by the number) to pick. I got so wrapped up in the predictability of rand()/etc that this didn't even occur to me.
Gracias - you rock ;)
E
Gracias - you rock ;)
E
Thanks for the points and thanks for using -E -- it's a great question! ~Ray
ASKER
As an addendum in the event anyone else uses this type of solution - it occurred to me that new entries need to be "caught up" with their view number...else they will get extraordinary precedent/priority. Think where everyone else has received 100 impressions and the new one sits at zero.
If there's only one person using the app they'll see that same entry 100 times.
What I've done is on new entries just given it an initial view count as the highest one so far. That way they're caught up.
If there's only one person using the app they'll see that same entry 100 times.
What I've done is on new entries just given it an initial view count as the highest one so far. That way they're caught up.
If there's only one person using the app they'll see that same entry 100 times.A common design for something like this is a junction table that allows clients to see all the resources, but when the client has already voted, the entry is marked as "read" or similar. Most email uses this sort of design. This allows the client to ask, "What's new?" and get a good answer without having to look at the same entry many times.
Let me put together a little script to show some ways of thinking about randomization. If you're getting too much predictability from the PHP rand() and mt_rand() functions you may want to consider using shuffle() instead.