On Tue, Dec 13, 2016 at 10:08:10AM +0000, Srikanth Anantharam wrote:
> Please see the updated pull request PR 50, with the changes.

I'm rejecting that pull request. As I said, mode() intentionally 
returns only the single, unique mode. I may add a more advanced API or a 
second function for dealing with multi-modal samples, but even if I do, 
your suggestion wouldn't be sufficient. Your pull request merely returns 
the entire list of unique values:

    return tuple(value for value, frequency in table)

with no way for the caller to tell which values might be a mode and 
which are not.

(By the way, even if this function behaviour was acceptible, which I 
stress it is not, this would not be sufficient for me to accept as a 
patch. You should preferably update the documentation and the tests as 
well. At the very least, you should update the function's docstring to 
explain the changed return value.)

I'm sorry that I have to reject this, I am interested in having better 
support for multiple modes. I'm not closing this issue just yet, if you 
are interested in continuing the discussion, what would be *VERY* 
valuable for me would be for you or some other volunteer to do some 
research into numerical techniques for objectively determining the 
number and value of modes, rather than just plotting a graph and 
subjectively deciding whether a value is a peak or not.

Thanks for your interest.