homepage

Replace all the _sqrt(x) calls with x ** 0.5, improving the visual appearance and providing a modest speed improvement.
$ python3 -m timeit -s 'from math import sqrt' 'sqrt(3.14)'
10000000 loops, best of 3: 0.032 usec per loop
$ python3 -m timeit -s 'from math import sqrt' '3.14 ** 0.5'
100000000 loops, best of 3: 0.0101 usec per loop

sqrt(x) and x ** 0.5 can be different.
>>> 0.0171889575379941**0.5
0.13110666473522276
>>> sqrt(0.0171889575379941)
0.13110666473522273

Hmm, I don't get that same result (Mac OS/X 10.10, Python 3.4.2):
>>> from math import *
>>> 0.0171889575379941**0.5
0.13110666473522273
>>> sqrt(0.0171889575379941)
0.13110666473522273
It's odd because your two result as same number, just displayed differently. I thought that wasn't supposed to happen anymore.
>>> (0.13110666473522276).hex()
'0x1.0c81a6aa9a74ep-3'
>>> (0.13110666473522273).hex()
'0x1.0c81a6aa9a74dp-3'

>>> (0.0171889575379941**0.5).hex()
'0x1.0c81a6aa9a74ep-3'
>>> from math import *
>>> sqrt(0.0171889575379941).hex()
'0x1.0c81a6aa9a74dp-3'
>>> 0.0171889575379941**0.5 == sqrt(0.0171889575379941)
False

FYI, my results match Serhiy's, on Windows, under Pythons 3.4.2 and 2.7.8.
It's not surprising to me. Since IEEE 754 standardized sqrt, most vendors complied, delivering a square root "as if infinitely precise" with one anally correct rounding. But unless the platform pow() special-cases 0.5, that's going to involve a logarithm, multiplication, and exponentiation under the covers. pow() implementations usually fake some "extra precision" (else the worst-case errors can be horrendous), but it's still not always the same as single-rounding.
Raymond, I didn't understand this part: "It's odd because your two result as same number, just displayed differently." The output immediately following that showed they _are_ different numbers on your box too (the .hex() outputs differ by one in the last place).

> The output immediately following that showed they _are_ different numbers > on your box too 
So it is. Seems like I need to increase my font size :-)

The next question is whether we care about that 1 ULP in the context of the random number calculations which already involve multi-step chains that aren't favorable to retaining precision: 
 s + (1.0 + s * s) ** 0.5
 ainv = (2.0 * alpha - 1.0) ** 0.5
 bbb = alpha - LOG4
 ccc = alpha + ainv
 g2rad = (-2.0 * _log(1.0 - random())) ** 0.5
 z = _cos(x2pi) * g2rad
 self.gauss_next = _sin(x2pi) * g2rad
 stddev = (sqsum/n - avg*avg) ** 0.5

I don't care about the ULP. I don't care about exactly reproducing floating-point results across releases either, but I'd bet someone else does ;-)

Okay, I give up.

Gah! Peephole optimizer! When you do a timeit for '3.14 ** 0.5', you're just evaluating the time to retrieve a constant!
In general, `**` is going to be both slower *and* less accurate than math.sqrt. Please don't make this change!

Timing results on my machine:
(Canopy 64bit) taniyama:~ mdickinson$ python3 -m timeit -s "from math import sqrt; x = 3.14" "sqrt(x)"
10000000 loops, best of 3: 0.0426 usec per loop
(Canopy 64bit) taniyama:~ mdickinson$ python3 -m timeit -s "from math import sqrt; x = 3.14" "x**0.5"
10000000 loops, best of 3: 0.0673 usec per loop
And the disassembly showing the peephole optimizer at work:
>>> def f(): return 3.14**0.5
... 
>>> import dis
>>> dis.dis(f)
 1 0 LOAD_CONST 3 (1.772004514666935)
 3 RETURN_VALUE

Ah, I missed that the issue was already closed. Apologies for the excitement and the gratuitous exclamation marks in my previous messages.

Good catch, Mark!