Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why Huffman code in reverse order? #110

Open
huhu0823 opened this issue Nov 1, 2022 · 2 comments
Open

Why Huffman code in reverse order? #110

huhu0823 opened this issue Nov 1, 2022 · 2 comments
Labels

Comments

@huhu0823
Copy link

huhu0823 commented Nov 1, 2022

I'm very interested in compression.Huffman coding can be performed sequentially,I can't understand why huffman code is executed in reverse order in the code.

@Cyan4973
Copy link
Owner

Cyan4973 commented Nov 2, 2022

FSE needs to encode and decode in reverse directions.
There are multiple conventions possible, this implementation selects to write the compressed bitstream forward, and read backward.
This results in a bitstream format, which is built around the assumption of forward writing, and backward reading.

For simplicity, the Huffman implementation in this repository employs the same bitstream.
Since the compressed bitstream will be read backward, but we still want the decoded symbols to be written forward, it follows that they must be written in the compressed bitstream in reverse order.

Obviously, other conventions could have been used. And it's also possible to read + write huffman forward, which is probably easier to follow. This would "just" require another bitstream implementation.

@huhu0823
Copy link
Author

huhu0823 commented Nov 7, 2022

FSE needs to encode and decode in reverse directions. There are multiple conventions possible, this implementation selects to write the compressed bitstream forward, and read backward. This results in a bitstream format, which is built around the assumption of forward writing, and backward reading.

For simplicity, the Huffman implementation in this repository employs the same bitstream. Since the compressed bitstream will be read backward, but we still want the decoded symbols to be written forward, it follows that they must be written in the compressed bitstream in reverse order.

Obviously, other conventions could have been used. And it's also possible to read + write huffman forward, which is probably easier to follow. This would "just" require another bitstream implementation.

Thank you for your reply!Your answer made me suddenly understand.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants