FIXED: RFE: revert to value ladder rounding from pre-2022

I’m noticing that the value ladder is showing the full float as I drag at .1 or lower increment. For example, this would show 0.8 after I release the mouse, but is showing .799999 while dragging:

image

Possible to get back the old behavior where it would always round to the actual increment, assuming a starting point on the increment as well?

3 Likes

Can’t reproduce this, what is your starting value?

Oh wow, yeah, this one’s a doozie. Didn’t notice cause all my projects are still on 15800.

It looks like it’s just an issue between the rounding of the float being displayed as you are dragging value ladder vs the rounding displayed at rest, but also it might be a combination of exact values of 0.1 being subtracted or added to inexact existing values or vice versa (since 0.8 should be represented as 0.8000000000000000444089209850062616169452667236328125 in a floating point double).

Regardless of what’s happening behind the scenes, very easily reproduceable for me in 2022.25370 in Windows 10 using the Limit CHOP as matijaerceg shows:

TD-vLadBug-25370

This is a Limit CHOP dropped into a new empty toe file. Switch to “Loop” type and then drag “Maximum” down at 0.1 increment to 0.4 and then back up to 0.8 and you should see it. Also when you hover over the value it shows it’s unrounded floating point value that matches what it shown while dragging.

This is not the behavior in pre 2022 releases (maybe related to the new slug library being used for all UI text?) as shown here in 2021.15800 on same Windows 10 machine:

TD-vLadBug-15800

Obviously, no one is expecting the value to actually be 0.8 since floating point can only represent 0.1, 0.2, 0.3, 0.4, 0.6, 0.7, 0.8, 0.9 as inexact, but for regular usage in these parameters where the difference between 0.7999999999999999 and 0.8 doesn’t matter, showing us the extremely exact value in this case makes it harder to quickly value-ladder to another value if your brain is looking for 0.8 and sees the 7 in 0.799999999 as you’re scrolling through.

I’ve found this super helpful website to show what floating point values can be represented exactly or inexactly:

That’s where I got the “exact” representation of “inexact” 0.8 above - assuming TD uses doubles to store floats. If TD stores floats as a single I guess 0.8 would be 0.800000011920928955078125…

1 Like

Can’t reproduce

Sometimes it shows properly rounded numbers for the first few increases/decreases, and then after several, it starts to show many decimal places, so make sure you’re dragging far enough.

Happens on many different OPs’ float parameters regardless of starting values, so much so that I’ve started just using my keyboard to input the values instead of using the value ladder.

If you’re unable to reproduce at all, I wonder if there’s something about the system/setup/drivers/hardware that’s causing the issue on our end, versus what your setup us @ben. Let me know if I can provide any info in that regard. I’m on 2022.25370 Win10, and this has been happening on all the 2022 builds I’ve tried. Core i5 10600kf, recent nVidia drivers.

@ben Are you really not able to reproduce this? It’s been happening to me on multiple computers now and is pretty noticable / annoying - to me at least :sweat_smile:

maybe I should be past the point in my TD career where I’m still using the value ladder anyways :grimacing: :grimacing: :grimacing:

Apologies, haven’t been able to get back to this since matijaerceg replied, will try to reproduce and log it this week.

Can confirm, thanks for your patience.

1 Like

This should be improved in the next build we post. Thanks for the report!

1 Like