Re: [Numpydiscussion] numpy.mean still broken for large float32arrays
Inaccurate and utterly wrong are subjective. If You want To Be sufficiently strict, floating point calculations are almost always 'utterly wrong'. Granted, It would Be Nice if the docs specified the algorithm used. But numpy does not produce anything different than what a standard c loop or c++ std lib func would. This isn't a bug report, but rather a feature request. That said, support for fancy reduction algorithms would certainly be nice, if implementing it in numpy in a coherent manner is feasible. Original Message From: "Joseph MartinotLagarde" <joseph.martinotlagarde@m4x.org> Sent: 2472014 20:04 To: "numpydiscussion@scipy.org" <numpydiscussion@scipy.org> Subject: Re: [Numpydiscussion] numpy.mean still broken for large float32arrays Le 24/07/2014 12:55, Thomas Unterthiner a écrit :
I don't agree. The problem is that I expect `mean` to do something reasonable. The documentation mentions that the results can be "inaccurate", which is a huge understatement: the results can be utterly wrong. That is not reasonable. At the very least, a warning should be issued in cases where the dtype might not be appropriate.
Maybe the problem is the documentation, then. If this is a common error, it could be explicitly documented in the function documentation. _______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On 7/24/2014 4:42 PM, Eelco Hoogendoorn wrote:
This isn't a bug report, but rather a feature request.
I'm not sure statement this is correct. The mean of a float32 array can certainly be computed as a float32. Currently this is not necessarily what happens, not even approximately. That feels a lot like a bug, even if we can readily understand how the algorithm currently used produces it. To say whether it is a bug or not, don't we have to ask about the intent of `mean`? If the intent is to sum and divide, then it is not a bug. If the intent is to produce the mean, then it is a bug. Alan Isaac
participants (2)

Alan G Isaac

Eelco Hoogendoorn