Mark Dickinson added the comment: It would be easy and safe to just use a/b = float(a)/float(b) if both a and b are less than 2**53 (assuming IEEE doubles). Then there wouldn't be any loss of speed for small integers.
For large integers the algorithm I posted should run in time linear in the number of digits of max(a, b), at least in the worst case (though with appropriate optimizations it could be made much faster for 'random' inputs). The current algorithm has essentially O(1) runtime. To get proper timings I'd have to code this up properly. I'll do this, unless there's a consensus that it would be a waste of time :) __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1811> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
