polyfit(): Is it possible to catch the error/warning and only then make corrective action? i.e. iferror(reduce the degree of the fit?)

This warning doesn't occur very often within my loop -- it depends upon the data (SNR). Seems an obvious need for a catch yet user manual doesn't mention it.

Warning: Polynomial is badly conditioned. Add points with distinct X values, reduce the degree of the polynomial, or
try centering and scaling as described in HELP POLYFIT. 
> In polyfit (line 79)
  In plot87_13c1_dig (line 444) 

[dpb]

Why not center always? (Other than coefficents are for standardized variables...)

What degree of polynomial are you using? (Maybe overfitting ...)

I'm not sure you can try...catch a warning but you can check the lastwarning status if matches.

How about attaching a sample dataset with typical casel that does/does not issue the warning and the base code line so folks can see?

[dpb]

Eric Answer moved to Comment -- dpb

Thanks for your response.

1. [p,S,mu] = polyfit( etc ) gives me a response very far removed from my visually satisfactory one p = polyfit()
2. degree 4 gives me a better eyeball fit than 3, particularly for high SNR cases, but error occurs for low SNR cases so I've been ignoring it.
3. I'll try. But wouldn't it be more consistent to issue a 1 or 0 as an output argument?

Try tomorrow. Maybe I can try a different approach. Thanks again. - ELeP

[dpb]

1. The fitted polynomial response will be identical for cases that are ok without centering; probably you're not using the centered variable for the predictor variable. See the example in the doc, you pass polyval() z=(x-u)/s instead of x.
2. 4th order polynomial is probably risky unless is never going to be used outside the defined range (never extrapolate, that is) and even there unless you're inspecting the output visually, there possibly could be an inflection point you wouldn't really want. IOW, caution against automating this too much.
3. I don't follow the question raised, sorry...

You might want to consider an interpolating spline instead of just a polynomial as less error-prone solution. Again, seeing some typical data and knowing more about the end objective could lead to improved suggestions.

Answer 1

[Eric LePage]

Yes tried the substitute variable... but put the numerator parenthesis in the wrong spot. Now fixed. No warnings.

Works superbly up to degree 5.

Thanks 1e+06. ELeP

[dpb]

I've resorted to workaround on occasion --

>> polyvalz=@(p,x,mu) polyval(p,(x-mu(1))/mu(2))
polyvalz =
  function_handle with value:
    @(p,x,mu)polyval(p,(x-mu(1))/mu(2))
>>

Then you don't have to compute z yourself, just pass original x and the statistics and let the function deal with it. How polyfit should have been implemented from the beginning imo...

This oneliner doesn't handle the extra inputs, though...that takes a more complicated function to handle the various possibilities.