site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com On Sep 2, 2009, at 8:29 PM, Bruce Sharpe wrote: Example: Expected value: <duration>1234567</duration> Exported value: <duration>1.23457e+06</duration> Regards Marshall Bruce _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/tme%40multicasttech.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.ap... 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. 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? Single precision has 24 bits of precision, or about 6 x 10^-8 fractionally. So, that would be 0.07 for your example, and should be marginally OK. However, in dealing with Julian Dates (about 2,500,000 days since the initial epoch, or an error of 0.15) we found that this is dangerous. With even a little bit of manipulation (subtract this value from that, and add to a third), you run the risk of being off by a day (or, in this case, a frame). So, in my opinion, these really should be double precision if they are going to be real numbers. This email sent to tme@multicasttech.com This email sent to site_archiver@lists.apple.com