Closed ouuan closed 3 years ago
@ouuan, this is nice thank you for catching it. But now that I see your PR I think it might be a good Idea to set the graph length to 100//len(blocks)
or something similar? This way for blocks like yours (numbers from 0 to 10) will have more logic to have 10 blocks instead of 25 (is somehow miss leading) . But, this will mean that the length will vary from one repo to another, and I don't know if this is something that is in line with the vision of @athul and @joe733 . Let me know what y'all think 😊
@ouuan, this is nice thank you for catching it. But now that I see your PR I think it might be a good Idea to set the graph length to
100//len(blocks)
or something similar? This way for blocks like yours (numbers from 0 to 10) will have more logic to have 10 blocks instead of 25 (is somehow miss leading) . But, this will mean that the length will vary from one repo to another, and I don't know if this is something that is in line with the vision of @athul and @joe733 . Let me know what y'all think 😊
We can add another input for the length.
@ouuan can you please show a screenshot or something where the graph is morphed.
I'm still trying to figure out the effect of change in block length.
@ouuan can you please show a screenshot or something where the graph is morphed.
/ 4 + 1 / 6
and % 4
works correctly only when the length of the BLOCKS
input is 4. One example is the test of 87.334
and ⚪⚫
.
The bug fix is completed. However, @malkam03 requested for an option (an input of the GitHub Actions) of the graph length (which is 25 now), which is not very related to this bug fix, and could be handled in another issue/PR.
Trusting on your skills for this one @ouuan 😉
The graph was incorrect when the length of the blocks is not 4. This fixes it.