pictures and /dev/random should give 0.5, not 0.57, if not they are not properly compressed and it's not a proper random generation, which I don't really believe. Maybe similar error as what happened with the 0.29?
The mean byte value in decimal should be 127.5.
I guess it may be something about the hexadecimal -> decimal -> binary conversion -> count instances of '0' and '1' in string in the python code that is doing something wrong (it's also inefficient to roundtrip through decimal when the original bytes are already binary in the computer and to involve strings in this at all). Does it remove leading zeros perhaps?
I don't want to turn this into a personal attack or an overly snarky comment but it's really something to try and implement a bit counting algo by hand and then fail to observe the way bin() behaves
> I don't want to turn this into a personal attack or an overly snarky comment
That's a fine intention, but then you shouldn't lead with "Jesus this is some dumb shit" or end with "it's really something to try and [...] fail." Doing it that way breaks the site guidelines. Would you mind reviewing them? https://news.ycombinator.com/newsguidelines.html
Note that the leading guideline in the "comments" section is Be kind.
There's a Linux application called "ent" that calculates the entropy of a file. I use it to see if it's worth it to compress a file before I ship it somewhere else.
It is of course vitally important that the 1's and the 0's even out, otherwise you might overflow the bit bucket and jam the tubes.
(This is actually a thing, encoding schemes like MFM and RLL in magnetic media ensure there aren't too many sequential 1 bits etc. See also "Grey codes")
I would assume < 0.5 on average since English strings are pretty common and the top bit is usually 0. Zero padding is fairly common in files too, while 1 padding is relatively rare.
This page is devoid of content except for a single "_" character. (I viewed the page in Chrome, Safari, Edge, and Firefox with identical results.) What am I missing?
32 comments
[ 5.6 ms ] story [ 54.2 ms ] thread0.25 according to my calculations
pictures and /dev/random should give 0.5, not 0.57, if not they are not properly compressed and it's not a proper random generation, which I don't really believe. Maybe similar error as what happened with the 0.29?
The mean byte value in decimal should be 127.5.
I guess it may be something about the hexadecimal -> decimal -> binary conversion -> count instances of '0' and '1' in string in the python code that is doing something wrong (it's also inefficient to roundtrip through decimal when the original bytes are already binary in the computer and to involve strings in this at all). Does it remove leading zeros perhaps?
Personally I would probably have used shift for a simple script like this.
In python, the string returned by
drops the leading zeros I don't want to turn this into a personal attack or an overly snarky comment but it's really something to try and implement a bit counting algo by hand and then fail to observe the way bin() behavesThat's a fine intention, but then you shouldn't lead with "Jesus this is some dumb shit" or end with "it's really something to try and [...] fail." Doing it that way breaks the site guidelines. Would you mind reviewing them? https://news.ycombinator.com/newsguidelines.html
Note that the leading guideline in the "comments" section is Be kind.
A smaller nit, these lines:
can be just$ ent -bc <filename>
(This is actually a thing, encoding schemes like MFM and RLL in magnetic media ensure there aren't too many sequential 1 bits etc. See also "Grey codes")
https://en.wikipedia.org/wiki/8b/10b_encoding
https://en.wikipedia.org/wiki/64b/66b_encoding
I thought A was 65, not 129?
One is the hex conversion. Compare:
versus just: Secondly, the code should just count the 1 bits; there is no need for a count of zeros.