Paul Dubois <paul@pfdubois.com> wrote:

Tim Churches wrote:

...

However, the fundamental problem is that support for NA (missing), Inf and NaN seems to be afterthoughts in both NumPy and numarray, whereas such support should have been integrated into the design right from the outset.

Is it too late to incorporate them into the fabric of numarray?

I can't speak for numarray. For Numpy, however, the fact that there is no support was DELIBERATE. Perhaps it is now possible to provide such

support at no cost in performance and in a portable way. I remain to be convinced.

Yes, fair enough. I think it comes down to different use cases for NumPy/numarray. Some of us would be happy to sacrifice 20-30% of overall performance for NA(missing)/Nan/Inf support which was not slower than the rest of NumPy/numarray (as opposed to MA arrays, which are half the speed of NumPy). However, I appreciate that for many other users, a 20-30% drop in overall performance is a disaster.

In any case, even if it is possible to do it now, and useful, it wasn't back then. We didn't overlook this question, we decided it one way.

Yup, OK, and I understand why you decided it that way.

One estimate, by the way, is that the implementation of the hardware to support this stuff slows down the cycle time of every supercomputer between 20 and 30 percent. Yet it is unnecessary, IMHO.

Unnecessary for specific applications, or unnecessary in general? Tim C