Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add auto-recalibrator #9

Open
ThePianoDentist opened this issue Feb 24, 2019 · 0 comments
Open

add auto-recalibrator #9

ThePianoDentist opened this issue Feb 24, 2019 · 0 comments
Labels

Comments

@ThePianoDentist
Copy link
Collaborator

need to add to db fields:

  • recalibration interval (how often to recalibrate)
  • first recalibration timestamp(obviously dont want to try recalibrating before league kicked off)
  • last recalibration timestamp? (need some way for server to know that it hasnt recalibrated for x long and should do it now)
  • recalibrate after every match option?
  • recalibrate on end period option?
  • num matches user in calibration
    assume costs were calculated by working out average points per game of pickees leading up to tournament.

with that in mind, if we recalibrate after 3 matches, and we said we calibrated originally on 150 matches. then the new value should be (old value * 150 + mean_cost * pickee_points / mean_pickee_points) / 153

having to calculate mean_cost and mean_pickee_points means maybe need to think about indexes to set up so it is not expensive to get these values

all these fields should be ignorable by api user, if they want to do their own recalibration/have none

also could have 2nd recalibration option where prices change when bought/sold by someone

could add

  • price_shift_on_transfer
    people put 0.1 in there, and every-time a user buys price increases by 0.1, every sale decreases by 0.1

these recalibration options should sort of work independently. could have either active, or even both

(have to think about locking/concurrent updates if someone buys, as points recalibration in progress.
think postgresql will just try both at same time, and reject the later transaction when find inconsistent. would be nice to be able to test this (can manually test it with begin, query and commits in psql))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant