[issue25478] Consider adding a normalize() method to collections.Counter()

Raymond Hettinger added the comment: Withdrawing the suggestions for scaled_to() and scaled_by(). Am thinking that people are mostly better off with a dict comprehension where they can control the details of rounding and type conversions. -- resolution: -> rejected stage: patch rev

[issue25478] Consider adding a normalize() method to collections.Counter()

Raymond Hettinger added the comment: New changeset 8c598dbb9483bcfcb88fc579ebf27821d8861465 by Raymond Hettinger in branch 'master': bpo-25478: Add total() method to collections.Counter (GH-25829) https://github.com/python/cpython/commit/8c598dbb9483bcfcb88fc579ebf27821d8861465 --

[issue25478] Consider adding a normalize() method to collections.Counter()

Change by Raymond Hettinger : -- pull_requests: +24516 pull_request: https://github.com/python/cpython/pull/25829 ___ Python tracker ___ ___

[issue25478] Consider adding a normalize() method to collections.Counter()

Allen Downey added the comment: This API would work well for my use cases. And looking back at previous comments in this thread, I think this proposal avoids the most objectionable pitfalls. -- nosy: +AllenDowney ___ Python tracker

[issue25478] Consider adding a normalize() method to collections.Counter()

Raymond Hettinger added the comment: Here's what I propose to add: def total(self): return sum(self.values()) def scaled_by(self, factor): return Counter({elem : count * factor for elem, count in self.items()}) def scaled_to(self, target_total=1.0): ratio

[issue25478] Consider adding a normalize() method to collections.Counter()

Raymond Hettinger added the comment: Vedran, Counters do explicitly support floats, decimals, ints, fractions, etc. Also, total() needs to be a method rather than a property to be consistent with the existing API and for clarity that a computation is being performed (as opposed to looking u

[issue25478] Consider adding a normalize() method to collections.Counter()

Vedran Čačić added the comment: My reading of the documentation says floats are only tentatively supported. The main text of the documentation says the values are supposed to be integers. Even the note mostly talks about negative values, the floats are mentioned in only one item. (And in that

[issue25478] Consider adding a normalize() method to collections.Counter()

Mark Dickinson added the comment: The point is that if you cache the total and update on each operation, you end up with a total that depends not just on the current contents of the Counter, but also on the history of operations. That seems like a bad idea: you could have two Counters with ex

[issue25478] Consider adding a normalize() method to collections.Counter()

Vedran Čačić added the comment: Well, yes, floats are innacurate. Do you really expect to normalize Counters containing values like a googol, or was it just a strawman? For me, it is much more imaginable* that total be zero because you have a negative value (e.g. {'spam': -1, 'eggs': 1}) than

[issue25478] Consider adding a normalize() method to collections.Counter()

Mark Dickinson added the comment: > total should be a cached property, that's updated on every Counter update That would run into difficulties for Counters with float values: e.g., after >>> c = Counter() >>> c['spam'] = 1e100 >>> c['eggs'] = 1 >>> c['spam'] = 0 the cached total would likely

[issue25478] Consider adding a normalize() method to collections.Counter()

Vedran Čačić added the comment: As I said above, if we're going to go down that route, it seems much more reasonable to me that total should be a cached property, that's updated on every Counter update (in __setitem__, increased by a difference of a new value and an old one for that key). An

[issue25478] Consider adding a normalize() method to collections.Counter()

Allen Downey added the comment: I'd like to second Raymond's suggestion. With just a few additional methods, you could support a useful set of operations. One possible API: def scaled(self, factor) """Returns a new Counter with all values multiplied by factor.""" def normalized(self, total=

[issue25478] Consider adding a normalize() method to collections.Counter()

Serhiy Storchaka added the comment: Was __rtruediv__ discussed before? What is the use case for it? Besides __rtruediv__ all LGTM. -- nosy: +serhiy.storchaka ___ Python tracker __

[issue25478] Consider adding a normalize() method to collections.Counter()

Change by Raymond Hettinger : -- keywords: +patch pull_requests: +6275 stage: -> patch review ___ Python tracker ___ ___ Python-bugs

[issue25478] Consider adding a normalize() method to collections.Counter()

Change by Raymond Hettinger : -- versions: +Python 3.8 -Python 3.7 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue25478] Consider adding a normalize() method to collections.Counter()

Steven D'Aprano added the comment: It seems to me that the basic Counter class should be left as-is, and if there are specialized methods used for statistics (such as normalize) it should go into a subclass in the statistics module. The statistics module already uses Counter internally to calc

[issue25478] Consider adding a normalize() method to collections.Counter()

David Mertz added the comment: Raymond wrote: > The idea is that the method would return a new counter instance > and leave the existing instance untouched. Your own first example suggested: c /= sum(c.values()) That would suggest an inplace modification. But even if it's not that, but c

[issue25478] Consider adding a normalize() method to collections.Counter()

Raymond Hettinger added the comment: The idea is that the method would return a new counter instance and leave the existing instance untouched. -- ___ Python tracker ___ ___

[issue25478] Consider adding a normalize() method to collections.Counter()

David Mertz added the comment: I definitely wouldn't want a mutator that "normalized" counts for the reason Antoine mentions. It would be a common error to normalize then continue meaningless counting. One could write a `Frequency` subclass easily enough. The essential feature in my mind wo

[issue25478] Consider adding a normalize() method to collections.Counter()

Vedran Čačić added the comment: That seems horribly arbitrary to me, not to mention inviting another intdiv fiasco (from sanity import division:). If only Counter was committed to only working with integer values from start, it might be acceptable, but since Counter implementation was always c

[issue25478] Consider adding a normalize() method to collections.Counter()

Wolfgang Maier added the comment: > >>> Counter(red=11, green=5, blue=4).normalize(100) # percentage > Counter(red=55, green=25, blue=20) I like this example, where the normalize method of a Counter returns a new Counter, but I think the new Counter should always only have integer counts. M

[issue25478] Consider adding a normalize() method to collections.Counter()

Vedran Čačić added the comment: Operator seems OK. After all, we can currently do c+c, which is kinda like c*2 (sequences behave this way generally, and it is a usual convention in mathematics too). And division by a number is just a multiplication by its reciprocal. But a dedicated normalize

[issue25478] Consider adding a normalize() method to collections.Counter()

Antoine Pitrou added the comment: The pitfall I imagine here is that if you continue adding elements after normalize() is called, the results will be nonsensical. -- nosy: +pitrou ___ Python tracker __

[issue25478] Consider adding a normalize() method to collections.Counter()

Changes by SilentGhost : -- nosy: -SilentGhost ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue25478] Consider adding a normalize() method to collections.Counter()

Changes by SilentGhost : -- Removed message: http://bugs.python.org/msg275998 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue25478] Consider adding a normalize() method to collections.Counter()

SilentGhost added the comment: Floats are also not fully supported by the Counter class, for example, sorted(Counter(a=1.0).elements()) results in TypeError. -- nosy: +SilentGhost ___ Python tracker ___

[issue25478] Consider adding a normalize() method to collections.Counter()

Changes by Raymond Hettinger : -- versions: +Python 3.7 -Python 3.6 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue25478] Consider adding a normalize() method to collections.Counter()

Josh Rosenberg added the comment: Counter is documented as being primarily intended for integer counts. While you can use them with floats, I'm not sure they're the right data type for this use case. Having some methods that only make sense with floats, and others (like elements) that only mak

[issue25478] Consider adding a normalize() method to collections.Counter()

New submission from Raymond Hettinger: Allen Downey suggested this at PyCon in Montreal and said it would be useful in his bayesian statistics courses. Separately, Peter Norvig created a normalize() function in his probablity tutorial at In[45] in http://nbviewer.ipython.org/url/norvig.com/ip

[issue25478] Consider adding a normalize() method to collections.Counter()

Changes by Raymond Hettinger : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:/