ValueError: a must be greater than 0 unless no samples are taken

[glory21]

when I train my dataset, there is an error:

File "/home/whb/anaconda3/envs/meta-frcnn1/lib/python3.7/site-packages/torch/utils/data/_utils/fetch.py", line 44, in data = [self.dataset[idx] for idx in possibly_batched_index] File "/home/whb/anaconda3/envs/meta-frcnn1/lib/python3.7/site-packages/detectron2/data/common.py", line 41, in getitem data = self._map_func(self._dataset[cur_idx]) File "/home/whb/kunyan/Meta-Faster-R-CNN-main/meta_faster_rcnn/data/dataset_mapper_pascal_voc.py", line 129, in call support_images, support_bboxes, support_cls = self.generate_support(dataset_dict) File "/home/whb/kunyan/Meta-Faster-R-CNN-main/meta_faster_rcnn/data/dataset_mapper_pascal_voc.py", line 267, in generate_support other_cls = self.support_df.loc[(~self.support_df['category_id'].isin(used_category_id)), 'category_id'].drop_duplicates().sample().tolist()[0] File "/home/whb/anaconda3/envs/meta-frcnn1/lib/python3.7/site-packages/pandas/core/generic.py", line 5365, in sample locs = rs.choice(axis_length, size=n, replace=replace, p=weights) File "mtrand.pyx", line 909, in numpy.random.mtrand.RandomState.choice ValueError: a must be greater than 0 unless no samples are taken

help please

[Chilipp]

hey @jgostick! Great, I am happy to hear that this package is useful :)

I apologize for being demanding

There is absolutely no need to apologize :wink: I am always happy to implement new features if I can. And in your case, I think it's actually not too difficult.

---

Let me start with the easy one: point 2. I think this is actually already answered in https://github.com/Chilipp/docrep/issues/4#issuecomment-366548209, but please let me know if not. Unfortunately, I cannot think of a fully automated solution at the moment as I have to treat Parameters-type sections, Returns-type sections and text sections differently. An automated support for unknown sections would not a priori know whether the unknown section should be treated like a Parameters section, or Returns section, or text section.

---

Point 1 is a bit more tricky, but should be feasible indeed. The workaround you mention in https://github.com/Chilipp/docrep/issues/16#ref-issue-466953964 has the problem that it does not maintain the order of parameters (which often is important for the documentation). I could imagine the following strategy:

1. Read the existing parameter list (for this, I have to remove all '%(...)s'-like parts in the section).
2. insert the new parameters (i.e. replace the '%(...)s'-like parts in the section as it is currently done with dedent)
3. load the parameters and check for duplicates. The parameters identified in step 1. should then be inserted at the positions of step 2.

As an example, let's look at this two methods:

@docstrings.get_sectionsf('method')
def some_awesome_method(self, param1, param2, param3):
    r"""
    Parameters
    ------------
    param1 : int
         This parameters controls blah and it's default is None
    param2 : int
         This second parameters controls blah and it's default is None
    param3 : int
         This third parameters controls blah and it's default is None
    """

@docstrings.dedent
def some_other_awesome_method(self, param1, param2, param3):
    r"""
    Parameters
    ------------
    %(method.parameters)s
    param2 : int
         This second parameters controls the size of the timestep and it's default is **10**
    """

Here, it is important that the doc of param2 needs to apear before param3 (therefore step 3.). In other words, the parameters section of some_other_awesome_method should look like

    Parameters
    ------------
    param1 : int
         This parameters controls blah and it's default is None
    param2 : int
         This second parameters controls the size of the timestep and it's default is **10**
    param3 : int
         This third parameters controls blah and it's default is None

and not like

    Parameters
    ------------
    param1 : int
         ...
    param3 : int
         ...
    param2 : int
         ...

Is this, what you are looking for?

[jgostick]

I would actually not mind if the parameters were in the wrong order, if it meant having the ability to override parent class docs. It's a trade-off I'd be willing to make. In other words, the order of parameters is secondary information (i.e. relays information about each parameters' relative importance) compared to the actual content of the docstring. But I must admit that I did imagine the added parameter overwriting the existing one, not appending onto the list.

[Chilipp]

Alright! Thanks for the feedback @jgostick :smiley: This requires a bit of work. At the moment I am not looking what parameters, etc. exist, at all. Instead, keep_params, for instance, just substitutes the parameters that you specify using a regular expression. However, for the stuff I am planning in #17, we need something to read and process the docstring, rather than just substituting the contents.