<div dir="ltr">On Wed, Feb 17, 2016 at 2:57 PM, Eran Hof <<a href="mailto:eran.hof@gmail.com">eran.hof@gmail.com</a>> wrote:<br>><br>> Enough people devoted plenty of their time to write papers about it: <a href="http://ieeexplore.ieee.org/search/searchresult.jsp?queryText=.QT.Q%20function.QT.&newsearch=true">http://ieeexplore.ieee.org/search/searchresult.jsp?queryText=.QT.Q%20function.QT.&newsearch=true</a><br>><br>> so I guess, a little comment in the documentation is in place. Adding to that, as said for Matlab immigrants, it be nice that when searching this function in scipy they'll get something. <br><br>Absolutely, please do add this to the documentation. Documenting common aliases is greatly appreciated.<div><br></div><div>To answer your question about why erf() but not Q, erf() is essentially the most normalized form of this function, so it can be implemented efficiently and numerically accurately more easily than Q directly. But once implemented, it is a good building block to implement the other variants like the Q function.</div><div><br></div><div>You may then ask, quite astutely, why we also have erfc() which is just 1-erf(). The answer is that for different values, you want to use one or another approximation. In some regions, erfc() is implemented to call 1-erf(). In other regions, erf() is implemented to call 1-erfc()! They have disjoint regions in which their approximation is numerically accurate. Our underlying special function library implements both for this reason. It was easier just to expose both in scipy.special. Otherwise, I would also not feel particularly compelled to expose an erfc() even though it is also commonly encountered in the literature.<br><br>--<br>Robert Kern</div></div>