--- Comment #22 from Lupo <lupo.bugzi...@gmail.com> 2010-01-27 10:29:02 UTC ---
Created an attachment (id=7032)
Test harness for addFractions/toRational
Cool. I like the localizability of the final output.
However, for some pathological (but legal) input the result may still overflow
the 32bit range.
toRational has the same problem on 64bit systems where PHP_INT_MAX is larger
than 2**31. This can be solved easily by not using PHP_INT_MAX but 2147483647
Since EXIF is limited to 32bits for these values, I think it's important that
we don't overflow this range. Otherwise we may get incompatibilities between
MediaWiki installations running on 32bit or 64bit systems...
Attached is a test program that tests both approaches for correctness, 32bit
overflows, and speed. Interestingly, it looks as if toRational (with the above
fix for 64bit systems) is faster. All these gcd calls in addFractions appear to
take quite some time.
Please take a look at the attached test program.
--- Comment #23 from Lupo <lupo.bugzi...@gmail.com> 2010-01-27 10:35:12 UTC ---
Created an attachment (id=7033)
Sample output of test program
Tests were run on an iMac (64bit, i5). A full test would take about an hour;
but I don't expect any surprises in the omitted parts. Will let it run tonight,
when the machine is idle otherwise. Right now the timing might be skewed due to
other activity on this machine.
--- Comment #24 from Lupo <lupo.bugzi...@gmail.com> 2010-01-28 07:33:10 UTC ---
As expected, the full test results showed no surprises. Both variants
(addFractions/toRational) handle "normal" GPS input of the form deg/1 min/1
sec/100 fine. In my test run, addFraction consistently was one third slower
than toRational (addFraction taking 100sec per 3600000 iterations, toRational
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.
Wikibugs-l mailing list