I'm inclined to agree with Mark - the wholly naive algorithm is already "perfect" away from extreme (whether large or small) magnitudes, and can't be beat for speed either.  This kind of thing gets much more attractive in IEEE single precision, where getting near the extremes can be common in some apps.

That said, at a higher level there's no end to FP functions that _could_ be implemented to be more accurate in some (even many) cases.  That it's possible isn't enough, on its own, to justify all the eternal costs of supplying it.  Significant real life use cases make for far more compelling justification.

For new FP stuff, the first thing I ask is "does numpy/scipy/mpmath supply it?".  I don't know in this case, but if the answer is "no", then it's a pretty safe bet that number-crunching Python users have insignificant real use for it.  If the answer is "yes", then the question changes to whether Pythoneers other than those _already_ using the major number-crunching Python packages have significant real uses for it.

On that basis, e.g., accepting the whole `statistics` module was an easy call (many real uses outside of just specialists), but adding a function to do LU decomposition of a matrix is an easy reject (exceedingly useful, in fact, but those who need it almost certainly already use the Python packages that already supply it).