ddsnowboard / FantasyStocks

A website where you play a game of fantasy stocks.
http://fantasystocks.herokuapp.com
Apache License 2.0
0 stars 1 forks source link

Write algorithm for calculating scores #11

Closed ddsnowboard closed 8 years ago

ddsnowboard commented 8 years ago

First, I need to figure out what the algorithm should even do. The most weighted term should be the percentage change of the stock. There should also be a term that looks at the past performance of the stock. I'm not sure how I should quantify "past performance" though. My current idea involves making a custom database field called PerformanceIndex, and then putting the last 10 or so percentage changes into it. It would be used in Python as just a list of ints of a set length, but behind the scenes, it would just be a string of comma-separated numbers (but the field class would take care of all of that stuff for me).

Anyway, so the algorithm will take in a performance index and the percentage change. I don't know what else, but that might be good. I could implement it with this and then change the actual algorithm later, if I do it correctly. NB that it also has to be set up such that running it on ten one-percent changes is identical to one ten-percent change, so that it's immune to not being refreshed for awhile.

Technical note: For the same reason as above, make sure that the percentage change is calculated from the last stored price and the newest downloaded price and not the percentChange field or whatever in the price request.

I was planning on adding the points to every player in the system whenever a stock is loaded. Regular SQL databases are pretty fast, so maybe it won't be an issue, but I would have to search through the whole Player table looking for people with a certain stock, which could take some time. I'd have to do some more stressful testing than just ddsnowboard and JoeSchmo to really know though. If it is, in fact, an issue, I could try to launch a separate thread and do it in the background. That might complicate things, and I think it would cause a race to update the player who triggered the update before his screen got sent, but maybe it would be OK. Or just do it the regular way. That would be nice.

So, in a nutshell, here's what we've got, roughly in order:

ddsnowboard commented 8 years ago

There is evidence that this is not actually working in practice unless you do a "Force Update" on the admin site. I should do some testing and check.

EDIT: Fixed in dd61fd5d8f8ee11f39447e032cd84556afc61043

ddsnowboard commented 8 years ago

This isn't 100% done, but I want to close it so that I can get the alpha out the door. I'll keep iterating the algorithm in production. What do they say? A bad product that ships is better than a perfect one that doesn't? Something like that.