This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author scoder gladman, mark.dickinson, pitrou, scoder, serhiy.storchaka, wolma 2014-09-27.13:06:00 -1.0 Yes <1411823161.49.0.80996013704.issue22486@psf.upfronthosting.co.za>
Content
```Patch 7 works for me. Why are the two Py_ABS() calls at the end needed when we start off the algorithm with long_abs()?

The Lehmer code is complex (I guess that's why you added the pure Euclidean implementation), but it's the right algorithm to use here, so I'd say we should. It's 4% faster than the Euclidean code for the fractions benchmark when using 30 bit digits, but (surprisingly enough) about the same speed with 15 bit digits. There is no major difference to expect here as the numbers are perpetually normalised in Fractions and thus kept small (usually small enough to fit into a 64bit integer), i.e. Euclid should do quite well on them.

The difference for big numbers is substantial though:

Euclid:

\$ ./python -m timeit -s 'from math import gcd; a = 2**123 + 3**653 + 5**23 + 7**49; b = 2**653 + 2**123 + 5**23 + 11**34' 'gcd(a,b)'
10000 loops, best of 3: 71 usec per loop

Lehmer:

\$ ./python -m timeit -s 'from math import gcd; a = 2**123 + 3**653 + 5**23 + 7**49; b = 2**653 + 2**123 + 5**23 + 11**34' 'gcd(a,b)'
100000 loops, best of 3: 11.6 usec per loop```
History
Date User Action Args
2014-09-27 13:06:01scodersetrecipients: + scoder, mark.dickinson, pitrou, serhiy.storchaka, wolma, gladman
2014-09-27 13:06:01scodersetmessageid: <1411823161.49.0.80996013704.issue22486@psf.upfronthosting.co.za>