Use NaN instead of NoneType if uncertainty evaluation fails

[jhossbach]

Hello there,
I am using LMFIT for a large amount of data and a number of models to fit. Because I am running further evaluation of the results, I rely on the structure (the covariance matrix, etc.). Now if some of those fits are failing, the resulting stderr and covariances will be NoneType which make them hard to work with. Instead, how about keeping the structure of the matrix but using np.nan instead? This allows to work with them, e.g. when using np.nanmean etc.

[newville]

@jhossbach I guess I would have thought that None and NaN were equal indicators of "no valid value available" and be about equally easy to work with. But if you are putting those into ndarrays, maybe that would be a more obvious difference. Perhaps you could test for errorbars being True?

Is the suggestion that covar should be set to NaN or a 2d array of NaN?

I don't really have a strong opinion on this, but willing to hear other ideas, opinions.

[jhossbach]

The only difference between None and NaN i know is that NaN is treated as a float which allows for arithmetic operations. pandas treats None as np.nan because of that (see https://pandas.pydata.org/pandas-docs/stable/user_guide/missing_data.html)

Is the suggestion that covar should be set to NaN or a 2d array of NaN?

I am thinking of a 2D array with NaNs. The option to check if errorbars is True does work but I feel having a if statement less in my code is more clean.

[newville]

@jhossbach Well, yes, NaN is a float, but one that is guaranteed that all functions and operations with it will return NaN.

I don't really view "what Pandas does" as a useful guide for handling numerical data. In fact, I would say that "Exhibit A" for the case to not follow Pandas is that they chose to (mis)use IEEE NaN for "missing data". That is what None is for.

Do we need to make covar an array of NaNs when result.errorbars is False? Are you using covar in some downstream analysis? Whatever you are doing, wouldn't the simplest way to handle cases where uncertainties could not be estimated be

   if result.errorbars:
        <code using stderr, covar, etc>
  else:
        <code to warn that uncertainties were not estimated>

[jhossbach]

Well, yes, NaN is a float, but one that is guaranteed that all functions and operations with it will return NaN.

In addition to that, numpy comes with a few methods that can avoid NaNs in the input, such as nanmean, nansum etc.

My reason for this change is the convenience when using mathematical expressions to not having to add additional logic to handle None while this could be avoided using nan.
Personally I would treat any value that usually is numeric but can be undefined as nan in order to avoid having to deal with a non-numeric object type.
Whether this is compliant with the IEEE I am not sure but I don't see why it shouldn't be.

That being said, I am of course happy to let this go if no one shares this opinion.

[newville]

@jhossbach Well, numpy comes with a few methods, and then you have to use np.nanmean instead of np.mean, which already signals to the reader "there might be NaNs". And that np.nanmean is really only a oneliner:

x_nanmean = x[np.where(np.isfinite(x))].mean()

so, maybe doing x_finite = x[np.where(np.isfinite(x))] is more robust -- you can use any calculation with that.

And you do probably really want to know which fits did not have uncertainties calculated, right?

I guess I'm not sure there is a compelling argument to change the library as opposed to expecting downstream code to use result.errorbars as the signal of whether uncertainties were calculated. If you're doing a bunch of fits, you'll have to loop over those and build an array anyway, right?

[reneeotten]

I am not in favor of making that change as it will -I think at least- break all existing code that checks for the presence of errorbars or covar using:

if covar:
    <do something>

if that's indeed the case then I don't support making a change given the discussion above.

[Tillsten]

I also have a lot of code which does if param.stderr is None:. -1 from me.

[newville]

@jhossbach @Tillsten @reneeotten OK, looks like we're not going to change this.