Re: Big integers exported in scientific notation in XML
Re: Big integers exported in scientific notation in XML
- Subject: Re: Big integers exported in scientific notation in XML
- From: Bruce Sharpe <email@hidden>
- Date: Wed, 2 Sep 2009 19:31:24 -0700
Eryk, thanks for the confirmation. Is there any value in re-submitting it as a bug just to emphasize that someone cares about it?
For posterity, here are some more details about this. Suppose you have a project element (clip, sequence, etc.) that is longer than 1 million frames. What happens if you export via XML and then re-import?
The good news is that FCP will re-import the XML without crashing. So it is not counting on frame units being expressed in fixed-point notation. As expected though, big numbers lose precision so the imported project will not be identical to the project that was exported.
More good news: if the XML contains seven-digit integers, they get imported without any problems.
One real-world consequence of all this is that if you are working on a project with a long timeline and you do something via XML to modify the project, various project elements could end up being out of sync with each other by up to five frames.
Bruce
On Wed, Sep 2, 2009 at 6:38 PM, Bruce Sharpe
<email@hidden> wrote:
Frame counts are inherently integers, so there's no reason for using real numbers at all. Even with 24 hours of video at 60 fps, the number of frames is well under 10 million. It fits comfortably into a 32-bit integer and needs only seven digits.
What we are seeing is probably just a consequence of FCP code using a C++ default string formatter for a double.
Bruce
On Wed, Sep 2, 2009 at 6:03 PM, Marshall Eubanks
<email@hidden> wrote:
On Sep 2, 2009, at 8:29 PM, Bruce Sharpe wrote:
I have just discovered that if a project contains a clip that has more than a million frames (4.6 hours at 60 fps would do it), then numbers like duration, in, out, etc. will be exported in the XML in scientific notation.
Example:
Expected value: <duration>1234567</duration>
Exported value: <duration>1.23457e+06</duration>
Aside from the fact that it messes up everyone who is expecting an integer there is a loss of precision. The difference between 1234567 and 1234570 frames could be important in some contexts.
Is this a known bug?
So, in my opinion, these really should be double precision if they are going to be real numbers.
Regards
Marshall
Bruce
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (
email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden