Re: NaN-toolbox much faster now

[Jason Riedy]

And Alois Schlögl writes:
> The only difference is that one implementation gives more often NaN
> (indicating no result) than the other implementation. Maybe its not
> wrong to return NaN, but its not what you want. You want the best
> possible estimate.

Well, sometimes it is what *I* want.  There are so many options of
what to do with NaNs that predicting what users want is tricky.

The "best possible estimate" with missing data can be computed in
different ways!  One involves an iterative process of replacing the
NaNs with an estimate based on the rest of the data.  You'll find
that method in some experimental design literature, and you can
even find reference to software using signaling NaNs for that
purpose long, long ago.  Without such tricks, returning NaN as the
mean is a great way to identify when you should apply the iterative
method to your data set.

But, on the flip side, if you're using the mean to re-center the
data, then you absolutely do *not* want a NaN result.  Subtracting
NaN from every entry will wipe out the entire data set and leave
you no trace of the original NaN.

Baring more sophisticated handling of exceptional events and data,
the most reliable choices are to provide either a per-call optional
argument or two different routines.  R takes the former route[1],
and we took the latter for max(a, b) and min(a, b) in the IEEE-754
standard.

A global flag that is not locally scoped and can be forgotten is
downright dangerous in this context.  Such a flag will wander into
code where it was not intended and wreck havoc.  Please use another
method.

Jason

Footnotes: 
[1]  R oddly conflates NaN and NA and removes both when na.rm=TRUE.
Might be an R bug.