You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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))
The text was updated successfully, but these errors were encountered:
need to add to db fields:
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
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))
The text was updated successfully, but these errors were encountered: