Steven D'Aprano added the comment:
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.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28956>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
