Inconsistent rightmost numbers in track BPM field

[Sean M. Pappalardo]

v1.11 r3287
To reproduce: Right-click a track, go to the BPM field, type in 10.12345678, click Apply, then go back in and notice that it now shows "10.12345695". Trying also with "10.11111111" results in "10.11111069". Likewise "10.1" results in "10.10000038".

I'm not sure if this is just roundoff error or not. But even if so, then we probably shouldn't allow 8 decimal places if we can't reliably handle that many.

[Owen Williams (ywwg)]

This is classic floating point value behavior. We should definitely be rounding the value in the widget to 2 or 3 places.

[RJ Skerry-Ryan (rryan)]

This isn't a bug.. it's just how floating point numbers work.

[Max Linke (max-linke)]

are these numbers stored with single or double precision in the db? With double precision there shouldn't be a rounding error

[RJ Skerry-Ryan (rryan)]

Yea, the numbers are stored in 8-byte floating point. While messing with the bpm delegate have you noticed anything weird? It's true that 10.12345678 is representable as a double.

[RJ Skerry-Ryan (rryan)]

Sorry Sean -- I was wrong. There were a couple places here and there where we were losing precision by casting the BPM to a single-precision float. Fixed in lp:mixxx/1.11 r3696 by always treating the BPM as a double. Confirmed that the value maintains its full precision across restarts so it's correct in the DB as well.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/6539