Verify correctness
5f271280 exactly matches lines of 776b4ef3 (as verified by @l22mille) containing:
f'μ: {μ}, len(Π): {len(Π)}, len(D[μ]): {len(D[μ])} ({[f"{b.height} ({b.level_min} - {b.level})" for b in D[μ]]})'Now let's verify the variable difficulty (around 32,256 (target decrease) and 56,448 (target increase) heights) behavior and ask @l22mille confirmation once personally verified.
First block score superior to 1: 1.1828995343128408 at height 32256.
Having issue at height 32704 as sanity check score increasing isn't verified.
Maybe it doesn't hold because of float precision... Should use somehow integers instead maybe. I'm right as it prints: score decreasing! previous: 519.9694956860781, newest: 519.969495686078 the difference is about: 1.1368683772161603e-13. We could try to workaround the issue by increasing floating point precision but this would potentially reduce the execution speed, would move away the problem definitely and would need a potentially important code refactoring concerning the scores.
The problem of switching to score integers is that it isn't clear (if even possible) to remain precise and keep our paper notations... Maybe let's use a sanity check only failing if exceeding more than the two Bitcoin nearest targets (divided by the number of Bitcoin blocks as we are summing block scores, this doesn't seem actually useful).
Have now the sanity check failing around height 56456 which takes 1m17 to be triggered contrarily to optimized parameters cf #4 (note that redirecting this output to a file seems to save us a minute here).
Can't upload logs for the 56456 issue, as even zipped their weight is about 85 MB.
Note that still have this issue even with score integers.
Note that the score definition using integers makes the genesis target blocks having a score of zero!
Quite blocked by #4.