RE: As a rule of thumb, the optimal voting time is before 5 minutes
Interesting. Here's the convergent_square_root function from the code:
Along with the marginal changes for that curve:
And here is the mvest / rshares ordered by time of vote from this post.
Noteworthy: the lowest mvest/rshares was the last voter: @steemcurator01 with 0.00077932..., and the highest was the 3rd voter, @curx, who voted after about 4 minutes and received 0.005784... mvests per rshare. So, the 3rd voter received 7x the reward ratio as the last voter. Voters around 5 minutes were scoring around 0.0035. Even the two voters at about 2 & 3 minutes beat the 5 minute score.
Presumably, the zeroes didn't commit enough rshares to get above the rounding threshold.
(The X axis is ordered by time of vote, but it's not properly scaled, due to the concentration of voters near the beginning of the voting period.)
So, yeah, I don't know how it happens in the code, but the order of voting definitely seems to make a difference.
Do you have an easy way to see what the actual curator payouts were for the post? I'm trying to see if my understanding of how it works maps to reality.
Not really. It took me quite some time this morning. The only way I know to do it is to get the rshares from the post, itself, using the condenser_api/get_content call, and get the curation rewards from the virtual operations in condenser_api/get_ops_in_block, then marry them up using a spread-sheet or script/program.
It's probably easier to start from the curation rewards and work backwards to the post. I did it post then curation rewards and finding the right block number with the curation rewards was a real chore.
Having trouble figuring out how to get the info I want from the standard API. But in case this is helpful for you, here's how you can get some useful info about that post from SDS:
https://sds0.steemworld.org/posts_api/getPost/remlaps/programming-diary-24-the-steem/true
I believe the "weight" parameter in the votes represents the share of curation rewards, and seems pretty close to the actual payouts (I think the differences are based on the .001 resolution). Haven't figured out why that number doesn't match what I think it ought to be yet.
I had seen that a couple years ago when @cmp2020 was building his AI voting bot, but it totally slipped my mind. Thanks! Not sure if I'll have time to look at it again before next weekend, but that does look like it might be a time saver.
OK. I made some progress but am still kind of bewildered. I now think the convergent square root curve is used (in the vote operation itself, I didn't notice at first that it picked the "curation" curve since I was so used to seeing the other curve in the rewards code). I think it sets the curation-payout-weight based on the delta between the new convergent-sqrt of rshares and the old convergent-sqrt of rshares. But my numbers aren't lining up with the actual payouts on the post. I'm wondering if maybe the data structure my script is getting for the votes isn't in order.