Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I could see that in some extraordinarily niche scenarios but if someone has the bandwidth to be transmitting full news articles then they have the bandwidth to use a whole 7 bits per character. And they should be compressing it too, at which point you don't need to restrict less common characters.


The set of people at the wire transmitting full articles might be different from the set publishing brief facts from low-bandwidth locations. (But it is convenient if they use the same infrastructure for it!)

I'm not convinced they would be compressing it. When you have the bandwidth for a full article, size is probably not going to be the problem, and when you don't have the bandwidth, compression is probably counterproductive.


Compression of text is basically never counterproductive as long as you use a suitable design.

Even a static huffman tree would help, and has no overhead. An entropy encoder would do very well and only cost a few bits to flush.


Compression removes redundancy. It's literally the definition of compression! And reduced redundancy is always bad when reliable transmission is a priority over small size.


If your news wire starts mangling data, you need to resend it, not guess.

And I bet you can get more reliability out of compressing and then adding error correction bits.


Bit of a late reply, but resending it is a form of redundancy, and so is adding error correction bits. It is cheaper to do these things (they require less bandwidth) when you start with a limited character set.




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

Search: