@anntzer I think this is important, so I wanted to reply to this in the main thread.

Could the dtype be e.g. [("mask", bool, len(x.dtype.descr))] (with a slightly different API)?

The context here is that mulrivariate data is stored internally as an array with a data type with multiple fields.
This has been chosen, because it ensures thatdata.shape returns the same shape for both scalar and multivariate data.
If a numpy array with multiple fields is masked, itmust have a separate mask for each channel. I read@anntzer s suggestion as letting the mask be another field, i.e. ['bool', 'float64', 'float64'] interpreted as [mask, variate0, variate1] when a dataset with two variates is masked.

It should be noted that when a regular np.array is masked, and the mask isfalse for all values, only a single instance of is stored (instead of a full array of bools). This is not the case for structured arrays. For structured arrays, full mask [with a separate bool for each field] is encoded in all cases.

I didn't actually get as far as to prototype this, but I did have a look around.

I have found that it will largely involve changes tocolors.multi_norm._iterable_variates_in_data() andcbook.safe_masked_invalid()

I have tried to list the advantages/disadvantages of the two approaches below:

A: Use a masked array with a struct array.

• Implication: each variate has a separate mask

Advantages:

1. It is easy to iterate over the channels (this is in any case handled bycolors.multi_norm._iterable_variates_in_data())
2. Easy to parse masked input
3. np.ma.is_masked() will work for both multivariate and scalar data
   3.1 I don't think this is actually used internally in the context of the data for a relevant plotting method, so this appears to be a minor issue.
4. Each variatemay have a different mask, and we may implement different belending mode in color for each.
   4.1 i.e. instead of having the masked values be transparent, it is possible to map them to unique colors, [typically colors that otherwise do not occur naturally in the colormap, typically cyan, magenta, bright green ] so that the user knows which channel has masked [invalid] data.
   4.2 We will probably not support this initially, but choosing this route allows us the flexibility in the future

Disadvantages:

1. Need to store a separate mask for each channel.

B: store the mask as an additional dtype in the struct array i.e.[("mask", bool, len(x.dtype.descr))]

• Implication: a shared mask for all channels

Advantages:

1. Only one mask
   1.1 Less memory use
   1.2 No ambiguity as to what data is masked

Disadvantages:

1. In order to iterate over the channels, a masked array must be created for each channel. (i.e. slicing the array will not produce masked arrays – this can be handled incolors.multi_norm._iterable_variates_in_data().)
   1.1. The data may be iterated over multiple times in order to produce a single plot [autoset limits(?) etc.]. One way to interpret option A is that it caches each variate in its masked form, whereas with option B the masked version of each variate is created only upon access.
2. A no-masked and masked version of the same array has different number of fields, which can lead to confusion.
3. Masked input must be parsed
   3.1 With this implementation, practically all data will need to be formatted upon input, whereas with implementation A, data that is already structs [or is complex!] is interoperable with the internal workings of matplotlib.
4. I suspect it will be more difficult to onboard new developers with this approach.

Having looked at this, my personal opinion is that option A is more suitable for matplotlib because I think it will be easier to maintain.

@anntzer let me know if I have interpreted your suggestion correctly, and if you agree with my assessment of approach A or B, or if you think I should make a full prototype to explore this further.