Hacker Newsnew | past | comments | ask | show | jobs | submit | ggghhhfff's commentslogin

As someone with a light background in social psychology, I have to say that nothing presented here falls into line with anything I have ever studied or learned. I would love for the author to provide references or links to any studies or any proper research that corroborates the claims.


I mean, he is basically saying that people either love you unconditionally, they love you but not unconditionally, they pretend to love you but are actually using you, or they actively hate you.

He kind of misses the category of people who dont care,but other than that, doesn't it cover 100% of the possibility space? What other possibilities are there? Like a priori i would expect the model to be true by virtue of the law of excluded middle


This. Only a gmail (not an institutional email) from a "consultant in diabetes and endocrinology" who seems to be moonlighting as ... a life coach?


Note that holding one of several financial licenses, such as a series 7 license, makes one eligible to be considered an accredited investor. Net worth / income is not the only path to attaining this status.


Great point, I wasn’t aware of this.


I am curious as to how this works for filetypes other than text files- what are the contents of each node in the tree for, say, a PNG file?


It works the *exact* same way. You process the input one byte at a time, build a histogram, construct the Huffman Tree and encode the input.

Why should it work different? Text files are just regular files where the bytes only use a specific subset of the possible values they could have.

If you do have some knowledge about the data you are encoding, you can be a little bit smarter about it: e.g. for the text section of an executable, you might work on individual instructions instead of bytes, maybe use common, prepared Huffman Trees, so you don't have to encode the tree itself.

On a side note: IIRC the Intel Management Engine does that using a proprietary Huffman Tree, backed into the hardware itself, as an obfuscation technique[1].

To circle back to your question: PNG simply feeds the pixel data into the zlib deflate() function as-is.

[1] https://en.wikipedia.org/wiki/Intel_Management_Engine#Design


You ask why it should work differently but then give a good reason why it should work differently: sometimes splitting by bytes is not the best unit.

And it actually does often work differently for PNG! PNG has a handful of preprocessing options for the pixels. So in filter mode 2, for example, deflate is encoding the difference between each pixel and the pixel above it. More or less.


But you still apply Huffman coding to the bytes after filtering.

I think this is true even when using 16 bits per sample, but i'm not sure.

From what i remember, in gzip, Huffman coding is applied to the offsets of repeated blocks, which are not single bytes.


JPEG uses Huffman as the compression stage. Here's[1] a brief but nice overview, here's[2] a more in-depth one.

Some encoders just use a precomputed Huffman table, but you can make an optimized one as discussed here[3].

Huffman is not the most optimal compression that can be used, for example Dropbox's Lepton[4] saves an additional 20% by replacing the Huffman stage with something better.

However, since it's a lossless stage this can be done transparently, which is nice.

[1]: http://www.robertstocker.co.uk/jpeg/jpeg_new_11.htm

[2]: https://www.impulseadventure.com/photo/jpeg-huffman-coding.h...

[3]: https://www.impulseadventure.com/photo/optimized-jpeg.html

[4]: https://dropbox.tech/infrastructure/lepton-image-compression...


The main key is that you can look at any file as a string of bits! And apply Huffman coding at whatever granularity you like. For text files, you're essentially applying it at the byte level (since each character is a byte (in ASCII, anyways)). For images, you might have one byte per colour channel, RGB. Then you can apply Huffman coding at the byte level, or even at the 3 byte level to operate on entire colours as opposed to channels.


Huffman coding generally works on symbols, where a symbol can be represented by any (possibly variable-length!) string of bits. I recall reading about a compression scheme (lzw?) where the symbol table had an entry for each raw byte value, plus the encoding instructions (e.g. lookback x bytes for y bytes).


That's pretty much all of them except LZW (which is an LZ78-alike, rather than LZ77). gzip has a number of Huffman tables for literals, distance, and for building Huffman tables at runtime... Yes, the instructions for building the Huffman tables used for decompression are themselves compressed using... more Huffman tables (HCLEN)!

Anything to save a few bits...


Oh yeah, might have been remembering gzip. All I remember is that it was one of the old/common ones. Don't know why my mind jumped to lzw instead of the obvious gzip haha.


It's generally used on bytes, but as others have said, it can be any symbol. Even on complete words!

https://www.nayuki.io/page/huffman-coding-english-words


It's the opposite: It's almost never used on bytes, because that just doesn't give you a lot of compression.

It is generally used as the final stage of some other compression algorithm, and operates on symbols generated by that algorithm. Often, this is some variation on LZ77, and the symbols are something like "bytes 0-255" in addition to various symbols that denote a match in previous data of some length and at some offset.


Indeed, this is an example where each English word in a book gets a unique symbol for the purposes of Huffman coding. Note that the Huffman output is in base 52 (abc...xyzABC...XYZ) alphabet instead of the usual binary.


One way could be to split the image file into RGB or CMYK channels, and then compress the relative brightness of pixels per channel.


Huffman coding is not used directly by PNG. PNG instead uses the regular DEFLATE algorithm from Zip (and Gzip), which uses Huffman coding as its last stage, to output the symbols created by its LZ77-based compression algorithm.


I’ve heard about the bowl-less design pattern a few weeks ago, excited to hear that it pans out in real world scenarios!


Parent is joking with the meme of “but I could build this produc myself with open source libraries!”


Parent is joking with the meme of “ If you don't understand the joke, then the joke's on you.”

;)


Interesting. Thanks for linking this.


Spot on. In theory, it is a fantastic idea to send mental health professionals, without any guns or self defense tools, or any bodyguards (police) to an ambiguous high-intensity crisis situation that seems like it involves psychological distress. In reality, when those professionals come face-to-face with, for example, someone high off of bath salts or PCP, they might have to abandon the scene due to the imminent threat to their lives, which then results in both the drug user and random passerby being placed into harms way due to the government not sending a full complement of healthcare + police professionals to the scene.


It's too dangerous for anyone to go there. They should just launch missiles on any address 911 is called for.

There is always risk.


Indeed


I disagree. All problems you mentioned are fundamentally hard. It is unfair to say that a logistical challenge is easier simply because it involves refrigeration at scale as opposed to research, weapons development, or computing at scale.


I agree. I think sometimes it is hard to fully understand how complicated logistics can be. I mean that’s why people study logistics in school and companies pay money for professionals well versed in logistics.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: