DOC: Grouper.ngroups vs Grouper.group_info[2]

[jbrockmendel]

In the groupby code we sometimes get do ids, _, ngroups = self.group_info and other times do ngroups = self.ngroups. In all existing test cases (as of last time I checked which was probably over a year ago), these two ways of getting ngroups match. Can we prove that this will always be the case? If so, let's make one a property based on the other. If not, let's add a test with a counter-example and a comment.

[natmokval]

I would like to work on this.

[rhshadrach]

I feel "proof" is too strong, but from what I can tell, they are always the same.

Case I: there is a single grouping ping. Here, result_index is ping.result_index and Grouper.group_info[2] is the length of ping.group_index. But ping.result_index is the same as ping.group_index, possibly with a modification to the categories. Thus these are the same.

Case II: there are multiple groupings. Here we have

comp_ids, obs_group_ids = self._get_compressed_codes()

with group_info[2] being len(obs_group_ids). obs_group_ids are the unique values that arise from self.codes when considering all groupings, where as comp_ids are the enumeration of the groups themselves. In particular, the number of unique values of comp_ids is equal to the length of obs_group_ids. On the other hand, we get reconstructed_codes from calling decons_obs_group_ids on comp_ids. The function decons_obs_group_ids returns a list of NumPy arrays all of the same length as the number of unique values in comp_ids. Therefore, len(obs_group_ids) equals len(result_index).

#55738 uses len(result_index) for both of these values.