Avatar of erzoolander
 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?  :)


Avatar of undefined
Last Comment
Ray Paseur

8/22/2022 - Mon
Ray Paseur

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.
Ray Paseur

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.
See Pricing Options
Start Free Trial
Ask your own question & get feedback from real experts
Find out why thousands trust the EE community with their toughest problems.

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 ;)

Ray Paseur

Thanks for the points and thanks for using -E -- it's a great question! ~Ray
Experts Exchange has (a) saved my job multiple times, (b) saved me hours, days, and even weeks of work, and often (c) makes me look like a superhero! This place is MAGIC!
Walt Forbes

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.
Ray Paseur

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.