Re: [Numpy-discussion] rcond in polyfit

[A. M. A. <per...@gm...>]

On 13/10/06, Tim Hochberg <tim...@ie...> wrote:
> Charles R Harris wrote:

> > 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':
>     'ignore'}
>      >>> 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 submitted a patchto use warnings for several functions in scipy a
while ago, and the approach I took was to create a ScipyWarning, from
which more specific warnings were derived (IntegrationWarning, for
example). That was perhaps a bit short-sighted.

I'd suggest a FloatingPointWarning as a base class, with
IllConditionedMatrix as a subclass (it should include the condition
number, but probably not the matrix itself unless it's small, as
debugging information).

The warnings module is frustratingly non-reentrant, unfortunately,
which makes writing tests very awkward.

> > 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.

This is a very good idea. scipy.integrate.quad returns a pair (result,
error_estimate) and every time I use it I trip over that. (Perhaps if
I were a fine upstanding numerical analyst I would be checking the
error estimate every time, but it is a pain.) Another option would be
a "full_output" optional argument.

A. M. Archibald