proposal: math/bits: rename OnesCount to Weight (Go 1.9)

[ctruta]

Hi, this is my first proposed change to Go. I hope I'm not missing anything, and, more importantly, that I'm not coming too late in the Go 1.9 release cycle.

May I please suggest renaming bits.OnesCount to bits.Weight?

Besides the name bits.Weight being shorter and along the lines of bits.Length, it's also the proper information-theoretic jargon -- the Hamming weight, or the bit weight.

Moreover, it is possible to extend this terminology to other measures as well. It needs not be done in the standard library if user code is better suited for this; but it will be semantically easy (and once again consistent with the information theory textbook) to add, for example, the distance (i.e. the Hamming distance) as follows:

func Distance(x, y uint) int { return Weight(x ^ y) }

[bradfitz]

Sorry, it's almost certainly too late. Go 1.9 isn't out yet, so it's theoretically possible to change yet, but Go 1.9 is basically done at this point.

You missed the big naming thread in #18616 where nobody mentioned "weight".

[bradfitz]

Further, most of the @golang/proposal-review group is about to go on summer vacations, so there might not be a proposal review meeting before Go 1.9 ships.

/cc @griesemer @brtzsnr @cespare @cherrymui @josharian @dr2chase @randall77

[ctruta]

Thank you @bradfitz for your response. I'm following the Go development by looking at what's new in the betas every now and then. I missed that big naming thread indeed.

[jimmyfrasche]

The OnesCountX functions parenthetically mention that the operations is also known as population count, as there are many sources that refer to the operation as such.

I could see the value in adding this to the docs as another also-known-as.

I don't recall coming across this name for the concept, personally, so I can't say how common it is. (Fair disclosure: I don't mess with bits that often and it's been a while since I did any readings in the information theory literature so I could just be forgetting that I've seen this).

[ctruta]

Ok @jimmyfrasche, if you consider mentioning the A.K.A. in the docs, you may find this Wikipedia article useful:

https://en.wikipedia.org/wiki/Hamming_weight

Considering other names (most notably Popcount), there was a need to play nice in the global namespace for CPU opcodes, or C (or ASM) functions. In the choice between Popcount and Bitcount, I can understand why Popcount was preferred as the more precise name. I, for one, consider that the zero bits are also bits that "count".

But when you have a bits or bitset namespace, "population" becomes redundant as a qualifier. Why was Count used instead of Weight in other places, like C++ or Java? I don't know. Perhaps because Weight was not that well-known, which is understandable, considering that not that many developers happen to be into coding theory, or compression, or error-correcting codes, or any other area in which terms like "weight" and "distance" (in reference to collections of bits) are commonly used in formulas and calculations.

In closing, I'm actually glad that you finally chose OnesCount instead of plain Count. Even if it's a little stylistically-inconsistent with LeadingZeros and TrailingZeros, it's more precise than Count, it sounds better than CountingOnes, etc. It's really a good name.

[ctruta]

(Responding to my own musing about the suitability of count, at least in C++ STL)

... because where there's a bitset i.e. a set represented as bits (and not just a plain bits namespace), count makes sense. In a bitset, the 1 bits represent elements, and the number of 1 bits represent the element count...

[rsc]

Too late. There was a long discussion about naming in #18616 and it's done. Even if you came up with a spectacularly better name, it's done.

And bits.Weight is not spectacularly better than bits.OnesCount anyway. OnesCount is much clearer to people without information-theory backgrounds, and that's the vast majority of our developer base.