[Bug] Time distribution intervals shift and have duplicates due to rounding

[GoldenWolf5]

Describe the bug Times don’t always go in the right time slot after solves and my max or minimum solve distribution is always the same, even though I don’t get my max solves anymore

https://user-images.githubusercontent.com/128649237/227660953-be89f635-852a-41ff-b34b-f01a5d93d041.MOV

To Reproduce Steps to reproduce the behavior:

1. Start and complete a solve
2. Click on data section
3. Scroll down to time distribution
4. See error

Expected behavior I expect for the solve time to go into the right section and not for the min or max solve to always be the same.

Screenshots or screen recordings See attached image

Crash log if applicable N/A

Smartphone (please complete the following information):

• Device: [e.g. iPhone14]
• OS: [e.g. iOS16.2]
• App version [e.g. 2.1.1]

Additional context N/A

[pdtxie]

I'm not quite sure I follow this error, the time distribution will show the distribution of your times throughout the entire session, and by how it's currently written now, will dynamically readjust the column widths depending on your solves. When you do a solve, each bar interval won't be the same as before the solve as to produce a nice looking graph.

Could you explain in a bit more detail what you should expect when you had finished the solve in the video (the 1.320)?

[GoldenWolf5]

In the video before the solve, the increment of below 31 is 276. After the solve, of 1.320, which is under 31, the counter is still at 276. But instead, 31+ went down by 4, the 34+ went up by 4, the 37+ went down by 2, and so on. Shouldn’t 1 just be added to the <31, making it 277 and everything else stays the same?

On Fri, Mar 24, 2023 at 4:51 PM Tim Xie @.***> wrote:

I'm not quite sure I follow this error, the time distribution will show the distribution of your times throughout the entire session, and by how it's currently written now, will dynamically readjust the column widths depending on your solves. When you do a solve, each bar interval won't be the same as before the solve as to produce a nice looking graph.

Could you explain in a bit more detail what you should expect when you had finished the solve in the video (the 1.320)?

— Reply to this email directly, view it on GitHub https://github.com/CubeStuffs/CubeTime/issues/152#issuecomment-1483602399, or unsubscribe https://github.com/notifications/unsubscribe-auth/A6VQQFIH7NLZBW3RBX2FFOTW5YXRJANCNFSM6AAAAAAWHELC7Y . You are receiving this because you authored the thread.Message ID: @.***>

[pdtxie]

yeah... I think what happened is it cascaded down, so the 1.3 got added to the first increment, but changed the bracket decimal (so <31 stays <31 but probably changed from like 31.4 to 31.2 as an example), which kicked out one solve (31.[2-3]x) keeping the number of <31 the same, but then causing a cascade shift for all the other intervals.

I know this is probably frustrating to hear - but this was initially implemented as just a small widget for a rough graph - a more detailed interactive chart is in the works

[pdtxie]

Mentioned in https://github.com/CubeStuffs/CubeTime/issues/207

[pdtxie]

Mentioned in https://github.com/CubeStuffs/CubeTime/issues/158