rcond in polyfit

Tim Hochberg tim.hochberg at ieee.org
Fri Oct 13 16:11:57 CDT 2006

Charles R Harris wrote:
> On 10/13/06, *A. M. Archibald* <peridot.faceted at gmail.com 
> <mailto:peridot.faceted at gmail.com>> wrote:
>     On 12/10/06, Charles R Harris <charlesr.harris at gmail.com
>     <mailto:charlesr.harris at gmail.com>> wrote:
>     > Hi all,
>     >
>     > I note that polyfit looks like it should work for single and
>     double, real
>     > and complex, polynomials. On the otherhand, the default rcond
>     needs to
>     > depend on the underlying precision. On the other, other hand,
>     all the svd
>     > computations are done with dgelsd or zgelsd, i.e., double
>     precision. Even so
>     > problems can arise from inherent errors of the input data if it
>     is single
>     > precision to start with. I also think the final degree of the
>     fit should be
>     > available somewhere if wanted, as it is an indication of what is
>     going on.
>     > Sooo, any suggestions as to what to do? My initial impulse would
>     be to set
>     > rcond=1e-6 for single, 1e-14 for double, make rcond a keyword,
>     and kick the
>     > can down the road on returning the actual degree of the fit.
>     I'd also be inclined to output a warning (which the user can ignore,
>     read or trap as necessary) if the condition number is too bad or they
>     supplied an rcond that is too small for the precision of their data. 
> That sounds good, but how to do it? Should I raise an exception?
Use the warnings framework:

     >>> import warnings
     >>> warnings.warn("condition number is BAD")
    __main__:1: UserWarning: condition number is BAD

The user can turn warnings on or off or turned in exceptions based on a 
variety of criteria. Look for the warnings filter in the docs.

Which brings up a question: do we want to have a FloatingPointWarning or 
some such? Currently, if you use set the error handling to warn using 
seterr a runtime warning is issued:

     >>> np.seterr(all='warn')
    {'over': 'ignore', 'divide': 'ignore', 'invalid': 'ignore', 'under':
     >>> np.arange(1) / 0
    __main__:1: RuntimeWarning: divide by zero encountered in divide

On the other hand if error handling is set to 'raise', then a 
FloatingPointError is issued. Is a FloatingPointWarning in order to 
mirror the FloatingPointError? And if so, would it be appropriate to use 
for condition number?

> I would also have to modify lstsq so it returns the degree of the fit 
> which would mess up the current  interface.
One approach would be to write lstsqcond (or a better name) that returns 
both the fit and the condition number. listsq could then be just a 
wrapper over that which dumped the condition number.  IIRC, the 
condition number is available, but we're not returning it.


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo

More information about the Numpy-discussion mailing list