rational times vs time ranges

[meshula]

        # TODO: Don't we want to enforce integers here?

I am encoding astronomical data in my current program and the stars aren't recognizing a framerate. I am storing Julian date at double precision in my timelines and so far that is working out okay for me :)

Alternatively, if TimeRange could accept other time kinds other than Rational, that would work for me too.

[quelsolaar]

On the Json side my plan is to re implement all numbers to be represented by a 64 integer and a 8 bit comma position. This way you wont get rounding errors. The main reason for not using integers, is half frames, and 29.97FPS. You could obviously do this using a 2997 integer but that reduces readability. I'm working on my implementation of this and the plan is to make a number of functions where you can query the time and the library will merge each frame rate separately, and then figure out a lowest common denominator. I also think its useful to be able to query any point in the structure using a specific frame rate.

[meshula]

That sounds fine. For reference, the julian time values in question look like -

2457986.936921296

Your scheme will work for this, although it's arguably not readable since I have any number of digits following the decimal. Another time in my database looks like this -

2457986.936923

so the encoding would look like this.

2457986936921296
9
2457986936923
6

I won't be human-reading the OTIO file, so I don't really care too much. In any case, it does suggest that the answer to the TODO in the Python code is "no"...

[jminor]

Supporting floating point value and rate in RationalTime is intentional. (Although we named it wrong, it should probably be FractionalTime instead...) We've been trying to draw out a real-world use case that illustrates rounding problems, but so far no one has come forward with one. At the same time, several people have found having floating point values useful. If we do need both, then making another time class could allow both to coexist.

@quelsolaar we should be careful to keep this decision and the C/C++ port separate. The timing of when we move ahead with either change won't necessarily coincide.

[meshula]

FWIW, python floating point values are IEEE-754 double precision.

https://docs.python.org/2/tutorial/floatingpoint.html

You've got 53 bits of precision to play with. In the case of a fractional value, unless I am remembering my error analysis class wrong, you'll be able to rely on 52 bits of the result.

[jminor]

Lets move the discussion about int/int vs float rates to here: #190