Repository navigation
Suprising behavior with start_seconds constrution due to floating point #61
Description
Activity
Testing this more thoroughly, short of removing
.floatin favor of a rational getter returning aFraction, a small epsilon is the only robust way to smooth over this behavior.- added a commit that references this issue
on Jul 9, 2025 I quite like the idea of using Decimal in place of float to be honest. But this is a major change and on top of my head I can't evaluate how much work it requires.
I wanted to modernise this library already, so maybe we can do a new major release that is not concerned about being backwards compatible etc.
Using the smallest
Decimalpatch (as above) under default settings, the results of theinttruncation later on work out much worse for some framerates:Percentage incorrect float roundtrip by implementation across 00:00:00:00-24:00:00:00
Frame Rate Decimal Implementation Float Implementation 23.976 13.6% 0.0% 23.98 13.6% 0.0% 24 13.6% 0.0% 25 0.0% 6.8% 29.97 10.0% 2.0% 30 10.0% 2.0% 50 0.0% 6.8% 59.94 2.9% 2.0% 60 2.9% 2.0% ms 0.0% 0.9% Example: frame 8 under 60fps is at time 8/60, or 0.1333... seconds. There is no amount of finite precision that can avoid the truncating step of
int(seconds * framerate)returning 7 instead of 8, so theDecimalimplementation will exhibit this problem no matter what:timecode = Timecode(60, "00:00:00:07") float_roundtrip = Timecode(60, start_seconds=timecode.float) print(float_roundtrip) # 00:00:006This case (and many others, per the table) happen to work with
floatdue to built in round-to-nearest behavior. So the ways to avoid problems with this strange behavior, in order of disruptive-ness:- Document and warn in the constructor doc string
- Add an epsilon to the float returned by the getter (Shift timecode floats forward a few picoseconds #63).
- Add an epsilon during construction from a float. About the same, but it would have the effect of correcting sketchy float iteration like in Construction using seconds is not accurate #22, which could theoretically be bad if someone relied on it.
- Discourage the use of the float representation of a timecode, e.g. by removing the
floatproperty, and instead providing a rational representation likeFraction. It'd be easy to manipulate for many use cases, helping users avoid loss of precision until they absolutely need to. Construction from the Fraction would be exact, but users with floats from other sources would still need to be warned. - Change from truncating to rounding. A big change in the library's semantics that would break many valid uses, while technically fixing this behavior as a side effect.
I think 1,2, and 3 might all be okay and worthwhile without a major release. 4 requires a bit more thought to see what the value in use would be, but clearly removing
.floatwould be a major change. 5 does not seem worth considering.3: unacceptable because it goes against the user intent by changing the value behind their back.
5: does not solve the issue, as a truncation may be desirable too (#48 ...)I have no strong opinion on 4. Internally the library should generalize the usage of fractions... but you are screwed the moment the user goes with a non-standard decimal framerate. 1 is fair as SMPTE documents also warns about possible rounding issues.
- added a commit that references this issue
on Dec 31, 2025 - added a commit that references this issue
on Jan 27, 2026
Confusion about construction from floats is common enough that in the past the generally incorrect solution of simply rounding up has been proposed:
#22
It's especially unfortunate when it comes from floats produced by the library itself though. Since these issues are inherent to floating point arithmetic, what do you think about modifying/removing the
.floatgetter in favor of e.g. aDecimalrepresentation? That results in expected behavior for the above snippet. Users can unwrap the Decimal into a float at their own peril, but then it should be less surprising when they encounter strange behavior.There may also still be the need to use the fractional frame representation when available (#36).Happy to send a PR.