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
[gjm] I wonder whether it would be an improvement to make use of the prior information we already have: most networks are similar in strength to previous ones, or some simple extrapolation from previous ones. So why not plot a graph that takes a prior based on other recent networks, updates on evidence from games played, and shows something like the 2.5, 50, 97.5 percentiles of the posterior?
[lightvector] Right now it does show the posterior already, it's just that the prior is very weak. The nice thing about having only a very weak prior that current network = previous network is that the entire thing is essentially unbiased. I know you tried to cover that by mentioning "simple extrapolation", but then you start having additional parameters relating to how to do that, and it gets messy, particularly since the optimization algorithm currently doesn't handle priors like "assume things continue in straight line log-scale trends" or whatever.
It seems a lot simpler to just move the "strongest confident" algorithm to be 3 sigma instead of 2 and let things continue to be nearly-unbiased.
Which is still a (simple) open task.
First, why we need to compute that value ?
We need the lower confidence ( log_gamma_lower_confidence) to select best network (so katrain can download it for example).
We need the upper confidence ( log_gamma_upper_confidence) to select a network worth spending rating game on it. That way, we eliminate false good network (high elo and high uncertainty).
We need to store in db log_gamma_lower_confidence = log_gamma - <some_factor> * log_gamma_uncertainty and log_gamma_upper_confidence = log_gamma + <some_factor> * log_gamma_uncertainty because we are going to sort by log_gamma_lower_confidence or log_gamma_upper_confidence and without database indexes the queries are going to be slow. But without relying on sql dark magic, we need the result to be precomputed to be indexed.
Which is good as we don't need to care for old network, they would be updated anyway :slight_smile:
How to change ?
As you can see there is some coupling (two identical magic constant, so maybe the 2 can be extracted in run model with an integer field (or maybe float field) such as
people relying on log_gamma_upper_confidence from API will now have really different value
=> we can just notify potential users here for now,
=> ideally we shouldn't expose log_gamma_lower_confidence or log_gamma_upper_confidence but let people calculate it from exposed log_gamma and log_gamma_uncertainty
UI (network page, elo graph) needs update if we wantit to be coherant with the internal changes ( @lightvector#3657 do we ?) :
=> django generated view uses
(issue after discord discussion)
First, why we need to compute that value ?
We need the lower confidence (
log_gamma_lower_confidence
) to select best network (so katrain can download it for example).We need the upper confidence (
log_gamma_upper_confidence
) to select a network worth spending rating game on it. That way, we eliminate false good network (high elo and high uncertainty).We need to store in db
log_gamma_lower_confidence = log_gamma - <some_factor> * log_gamma_uncertainty
andlog_gamma_upper_confidence = log_gamma + <some_factor> * log_gamma_uncertainty
because we are going to sort bylog_gamma_lower_confidence
orlog_gamma_upper_confidence
and without database indexes the queries are going to be slow. But without relying on sql dark magic, we need the result to be precomputed to be indexed.Then, when we need to compute that value ?
We set the field first on upload which is indeed
katago-server/src/apps/trainings/serializers/network.py
Lines 53 to 66 in e2d3909
We also update network every 10 min here
katago-server/src/apps/trainings/tasks/update_bayesian_rating.py
Lines 14 to 37 in e2d3909
katago-server/src/apps/trainings/managers/network_pandas_manager.py
Lines 51 to 52 in e2d3909
Which is good as we don't need to care for old network, they would be updated anyway :slight_smile:
How to change ?
As you can see there is some coupling (two identical magic constant, so maybe the
2
can be extracted in run model with an integer field (or maybe float field) such askatago-server/src/apps/runs/models/run.py
Lines 165 to 169 in e2d3909
katago-server/src/apps/runs/admin/run_admin.py
Line 16 in e2d3909
Will it break anything ?
people relying on
log_gamma_upper_confidence
from API will now have really different value=> we can just notify potential users here for now,
=> ideally we shouldn't expose
log_gamma_lower_confidence
orlog_gamma_upper_confidence
but let people calculate it from exposedlog_gamma
andlog_gamma_uncertainty
UI (network page, elo graph) needs update if we wantit to be coherant with the internal changes ( @lightvector#3657 do we ?) :
=> django generated view uses
katago-server/src/apps/trainings/models/network.py
Lines 237 to 238 in cdf1b31
=> elo graph uses
katago-server/src/frontend/templates/run_stats_head.html
Line 380 in cdf1b31
X * network["elostdev"]
, eg for graph axis min elo and max elokatago-server/src/frontend/templates/run_stats_head.html
Lines 171 to 172 in cdf1b31
unit tests will maybe break (if they are good they will)
The text was updated successfully, but these errors were encountered: