Would be nice if there were a test proving this is necessary.

I don't think core_num_dims is a suitable variable name any more, if it's not a universal replacement for ufunc->core_num_dims

@mattip - I cannot test this, as it doesn't cause any problems - just a bit of extra memory allocated that may get an irrelevant value in it. But it was good to find it, as it showed that your n_dims_used variable, which was a copy of the core_num_dims that I had introduced for keepdims, was not necessary.

@eric-wieser - the name is a bit beyond the scope of this PR, but how I see it is that the names not attached to the ufunc are explicitly meant for changes that are useful within the routine. In the frozen-dimension addition, ufunc->core_dim_sizes is used similarly as initial values, and core_dim_sizes for the actual ones. In fact, I've been thinking that it might be useful for the implementation if upon entry a light copy of the ufunc gets made in which such changes can be kept together. This could then be used also to address the linalg problems: one could have a signature that means an external routine gets called that can adjust the indices, etc., in-place.

Anyway, probably the wrong place to put this idea, since not relevant to this PR - which really is just a correction for a mistake I made in #11098.

Still a bit stymied on this one, I admit. Even though I dived deeply into the code I only have an intuitive feel for when we use ufunc->core_num_dims and when just core_num_dims. Perhaps a name change would make it clear, or an explanatory comment next to the changes in this PR.

The underlying logic is that if one wants to access information in the ufunc (basically, core_dim_ixs), the it always should be ufunc->core_num_dims.

Agreed that a name change may be useful, but perhaps as part of #11175 - this PR is really just meant as a correction for #11098 (and I'd like to have it in to avoid yet more rebases...).

Thanks Marten