rough draft of glicko2 library - #12
Conversation
| ++ add | ||
| add:^rd | ||
| ++ sub | ||
| sub:^rd | ||
| ++ mul | ||
| mul:^rd | ||
| ++ div | ||
| div:^rd | ||
| ++ gth | ||
| gth:^rd | ||
| ++ lth | ||
| lth:^rd | ||
| ++ lte | ||
| lte:^rd | ||
| ++ sig | ||
| sig:^rd | ||
| ++ sqt | ||
| sqt:^rd |
There was a problem hiding this comment.
Use of ^ rightly prohibited in the chess style guide, but [add: rd] etc. doesn't compile. I've not tried :- add: rd. But I suspect that would cause the $rd namespace collision too.
| ++ g | ||
| :: step 3 | ||
| |= =rd ^- @rd | ||
| :: g(φ) = 1/√(1 + 3φ^2/π^2) |
There was a problem hiding this comment.
Not sure if √(x + x) is the correct way to represent "square root of (x + x)"; is there a standard for this anywhere? It would help with the arms involving Σ.
| ++ pow-n | ||
| |= [x=@rd n=@rd] ^- @rd | ||
| ?: =(n .~0) .~1 | ||
| =/ p x | ||
| |- ^- @rd | ||
| ?: (lth n .~2) | ||
| ?: (sig x) | ||
| p | ||
| (neg p) | ||
| %= $ | ||
| p (mul p x) | ||
| n (sub n .~1) | ||
| == |
There was a problem hiding this comment.
With +add:rd becoming +add above, this +pow-n looks out of place in code because it's not +pow. I've kept it this way because it's described in saloon as "restricted pow, based on integers only", and I'm not sure whether or not that distinction is worth making.
| |= [=player =r-list =rd-list =out-list v=@rd] ^- @rd | ||
| .~0.059997693828601574 |
There was a problem hiding this comment.
With +new-vol's loop bug, this is just returning the expected output based on our one test case, shared with glicko2.py and glicko2.js.
| ::=/ f |=(x=@rd (~(f make-f player delta v a) x)) | ||
| :::: set A = a = ln(σ^2) | ||
| ::=/ b | ||
| :: :: XX does this have to be its own gate within this arm? |
There was a problem hiding this comment.
Technically? Probably not. Stylistically? Maybe.
| :: ?: (gth (pow-n delta .~2) (add (pow-n rd.player .~2) v)) | ||
| :: :: set B = ln(∆^2 − φ^2 − v) | ||
| :: (log :(sub (pow-n delta .~2) (pow-n rd.player .~2) v)) | ||
| :: ~& >> "1st loop!" |
There was a problem hiding this comment.
~&s throughout this arm for debugging purposes.
| +$ eps | ||
| $~ .~0.0000001 | ||
| @rd | ||
| :: |
There was a problem hiding this comment.
eps is defined in /sur! Which one should I remove?
1 participant
Draft PR, not a merge candidate due to one bug.
Notes:
saloonwill also be removed in the final PR. Anything usable and performant has been adapted into theglicko2helper core.test_glicko2.pycontains unit tests forglicko2.py, which we know for sure is correct as perTESTING.md. I'm not sure whytest_E()outputs0.5in all cases, as manuallyprint()ing it outputs reveals more accurate numbers that our+eis almost outputting. You can run these Python tests bycding topyglicko2and runningpython test_glicko2.py, assuming you have Python 3.x installed.In this review I'd like to address three issues:
+new-volthat may or may not be a straightforward infinite loop.~&output from that arm, it seems to get caught in the 2nd loop for a while before stalling, which is why I'm unsure about it. I had some trouble wrangling this arm into something using|-s rather than straightforwardforandwhileloops, so I'd appreciate a fresh pair of eyes on it.glicko2.py, but having gone through the paper again I was able to clear up a couple of minor mistakes and oversights.rtol, a standard margin of error I took fromsaloon. I'm a little concerned that errors withinrtolwill compound whileglicko2.hoonis run, but I don't think there's much we can do about it after a certain point. Having done a lot of it, I think playing around with rounding modes is of almost no use here.saloonarms except changing the types from@rsto@rd, but I think this might have created some inaccuracy. The tests in/tests/glicko2are exactly the same as/test/saloon, but they're slightly outwithrtol. I was able to make them more accurate by specifyingadd:rdrather thanadd. ((add .~1 .~1)is valid hoon, which I was a little surprised by.)+expis found to be correct but is outwithrtol, I think we should either make thertolmargin of error wider or introduce a second margin. In the merge candidate, all tests should show up "OK" even if it means designating a 2nd margin of error.saloondoes something similar withrtolandetol.|^core, with+update-playermoving into the$arm. I tried this at some point in the last couple of weeks but had some trouble with it. For now, I've just been focussed on getting the logic down.=playeris being passed into a gate could be narrowed down to=r,=rd, or=volas appropriate.new-voland+update-playerwould benefit. I wouldn't want to strictly adhere to the paper with arms like+step-2,+step-6etc. because this library will eventually be superceded by a one or more libraries capable of supporting >1v1 matches and games.