Is the endgoal of this PR (and further work) to be as close as possible tothe ones in numpy? I ask because I'm a long time user of numpy, as is everyone in the company I work for, and nobody used thisnumy.ma, ever. I mean, we do use masked arrays all the times in medical imaging, mostly for ignoring invalid voxel (outside of brain, etc.), but the tools innumy.ma never had any appeal I guess.

In brief, I see 3 problems with this (not your PR spedifically, but the concept)

1. AFAIK, it's mostly useless. This is my opinion and the result of a survey in my small company. I don't really believe it, but keep in mind that it's possible that we're simply ignorant of the right usage, or have simply never needed it.
2. It forces the library to duplicate code. Like,mean forArray andMaskedArray,std-dev, etc. Maybe this is less of a hassle than I think.
3. Most all(?) usages can be replaced with aselect() or aZip::from(arr).and(mask). That's what we're currently doing. in fact, I think that's the problem withnumy.ma: it's super easy to avoid. You simply usearr[mask > 0] and some other indexing tools, et voila.

What I would gladly use is aZip::masked function, like

Zip::from(&brain).and(&wathever).and(&mut out).masked(mask).par_apply(|&b, &w, o| {    // No mask == false here, yay! But it's simply avoiding a if...})

but this is somewhat irrelevant to the current discussion :)

I appreciate reading your sketch andrei, you're more productive than me, just having a go at a draft instead of trying to make something perfect.

I think it's been mentioned before yeah, the question whether to have masked arrays or masked operations on arrays. I dread the complexity of either. Thanks nilgoyette for the candid thoughts too.

I think we should start with masked operations. I think that's what a masked array type (if it were to exist) would need as basis anyway. And it allows having a separate mask too - which should hopefully be more efficent (packed or sparse bitmap?)