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!
The array could potentially get quite large...That would seem to be a good problem, indicative of high popularity, right?
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.
This one is on us!
(Get your first solution completely free - no credit card required)
UNLOCK SOLUTION
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
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.
Join our community and discover your potential
Experts Exchange is the only place where you can interact directly with leading experts in the technology field. Become a member today and access the collective knowledge of thousands of technology experts.
*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.