Only when you read the FAQ and click the Generate Points button.
Comment has been collapsed.
Actually, the real answer is "Technically, No".
If the website works the way I think it does, that is.
This is just a hypothesis, but as a developer myself this is how I would handle it to avoid modifying every single member's points every 6 minutes.
Once you log in to the website (or refresh the page for that matter), the website calculates how long it's been since your last connection, and offers you the points accordingly (with the maximum being 400, plus the cancelled giveaways values).
Therefore, until you connect, your number of points hasn't changed.
So, no points are being gained while being offline. They are gained by coming online.
Who would have thought that such a simple question had such an intricate answer? :)
Alright, I'll show myself out...
Comment has been collapsed.
Does that mean that the number of points depend if I enter or not the site?
Reminds me of https://en.m.wikipedia.org/wiki/Schrödinger%27s_cat
Comment has been collapsed.
Rather that your points are in a state of quantum superposition until you attempt to observe them. Until you look you may have points, or you may have been have banned, or SG may have fallen off the internet, or Archi bot may have finally taken over and replaced all points with a system where you bid parts of your soul in an infernal auction system, or so on and so forth...
Comment has been collapsed.
You must be so much smarter. Only reminded me of the eternal question "Is the light in my fridge really out when I close the door" lol.
Comment has been collapsed.
Look closely at the light while slowly closing the door. Most fridges I've seen have the light go off just before the door is closed.
Comment has been collapsed.
I would just hand out the 6 points to every user every 15 minutes. It's far easier and more straightforward, than to remember the state of every deleted GA ad infinitum. And it's the easier solution to program and therefore IMO the better solution in the long run since it's easier to maintain.
UPDATE users
SET points = MIN(400, points+6)
WHERE points < 400🤓
Comment has been collapsed.
The problem with this solution is that if the database has a ton of members, but only 2% of them are active at any given time, that algorithm is still applied for each and everyone of them. It would put a lot of strain on the database and the server, for very little gain.
I actually think the algorithm looks something along these lines:
Variables stored for each User:
Last_Connection : Time of the last connection
Points : Amount of points the user has
Extra_Points : Points given back to the user following giveaway cancellationsAlgorithm when cancelling a giveaway:
For each User in Giveaway
User.Extra_Points = User.Extra_Points + Giveaway.ValueAlgorithm when connecting or performing an action:
Now = The current time
User.Points = Min ( 400, User.Points + (Now - User.Last_Connection) * 6points / 15mins) + User.ExtraPoints
User.Extra_Points = 0
User.Last_Connection = NowEdited to correct the points attribution, thanks ehzgjohann!
Comment has been collapsed.
I tend to disagree that it would put a lot of strain on the database. All you need is a index over the points column. Since all inactive members have 400 points within a day, only the records for active members are actually updated.
Your solution has of course the benefit of less performance needed. But you can't apply the returned points from GA deletion accordingly to deletion time. Therefore you could get over 400 points even though the GA was deleted while you were still below 400 (had you logged in).
After all this is of course a very academic discussion and neither of us can know for sure, still I have fun doing it.
(AFAIK you get 6 points every 15 minutes not a point every 6 minutes)
Comment has been collapsed.
Still, considering the amount of members active every day, it's still a quite heavy process, even if everyone with 400+ is ignored.
To solve the problem you raised, I think that the algorithm for cancellation could then be improved by doing this:
For each User in Giveaway
Apply the connection algorithm
If(User.Points >= 400)
User.Extra_Points = User.Extra_Points + Giveaway.Value
Else
User.Points = User.Points + Giveaway.Value
If (User.Points > 400)
User.Extra_Points = User.Points - 400
User.Points = 400That way, if under 400, the extra points are not applied as 'extra' points.
Also, you're completely right about the 6 points every 15 minutes, I had a 6 in mind but did not think it out further haha
It does make for great discussions! :D
Thanks for your insight!
Comment has been collapsed.
Thinking about it some more, your solution would work perfectly if you do a pseudo login for every participant of a GA when it's deleted right before giving back the points. That way you wouldn't need a complicated logic and still get perfect results.
That said, I still think (in general) it's better to have a batch job do the work and not have to do it on every page access since response time is the most important figure.
I will check tomorrow at work, how long it takes to update a user table of 1 million rows.
Comment has been collapsed.
I agree for the pseudo-login, it's what I put at the second line of my above solution.
Also, just thought of this, but awarding the points upon connection allows points to be earned even if the server was down.
If the server had a misstep right about the time it was supposed to send the points, then everybody misses on those 6 points.
It could be made up for by having the server keeping track of its last uptime and extrapolate the points, but still.
Comment has been collapsed.
Sorry, I didn't see that you had the pseudo login already included. But then I don't understand why you would keep the extra_points separate instead of applying the at the time of the GA deletion.
Your argument about server downtime is totally valid though and only hardly can be solved automatically in my solution.
I ran my tests now (both on the same server):
| db-type | # of records (total) | # of records (under 400) | percentage (under 400) | runtime | runtime per record modified |
|---|---|---|---|---|---|
| DB2 | 1,048,576 | 523,728 | 49.95% | 10.74 | 20.5µs |
| DB2 | 1,048,576 | 261,634 | 24.95% | 5.34 | 20.4µs |
| DB2 | 1,048,576 | 105,587 | 10.07% | 2.42 | 22.9µs |
| DB2 | 1,048,576 | 52,456 | 5.00% | 1.27 | 24.3µs |
| MyISAM | 1,048,576 | 524,110 | 49.98% | 18.55 | 35.4µs |
| MyISAM | 1,048,576 | 261,723 | 24.96% | 13.19 | 50.4µs |
| MyISAM | 1,048,576 | 104,824 | 10.00% | 2.80 | 26.8µs |
| MyISAM | 1,048,576 | 52,118 | 4.97% | 1.37 | 26.3µs |
Comment has been collapsed.
Indeed, the extra_points make no sense in that new algorithm haha
Functional redundancy, let's say :P
The performance is worse than I would have thought actually.
Thanks for running those tests, it gives a good idea of how strong a simple algorithm can be on a server when applied on enough units.
Maybe we got it all wrong, and actually the points are awarded by leprechauns who can stop time. Half-Life 3 confirmed!
Comment has been collapsed.
I had also expected better runtimes. But to be fair, it's an fairly undersized 8yo development server, so the actual times don't matter that much. What took my by surprise, is the fact that the query engine didn't want to use the index on the points column when doing the update. So there's still the possibility I did something wrong and better runtimes can be achieved.
All in all I must say that the leprechaun algorithm seems to be the most plausible to me now.
Shortly followed by awarding the points at login. 😃
Comment has been collapsed.
at the present time 6 points in 15 minutes? 24 = 1 hour? or is there a change?
Comment has been collapsed.
No, you didn't do anything for them to start with, so you're not earning anything.
Comment has been collapsed.
generating points for solving captchas like a bitcoun faucet would be an idea 🤓
Comment has been collapsed.
That's "the answer to the Ultimate Question of Life, the Universe, and Everything".
So, that's always right!
Edit: I'm not necroing here, I saw this in the top discussions :)
Comment has been collapsed.
Comment has been collapsed.