Viewing profile — quicktwo
quicktwo
HN member- Joined
- Sun, Feb 20, 2022, 6:34 AM UTC
- HN karma
- 10
- Public activity
- 17 items
- HN profile
- View on Hacker News ↗
About quicktwo
No profile information was provided.
Recent public activity
-
comment
Comment #30423974
Not sure how big the word dict is in your latest version, but you can do much better simply by reordering how you create your index. With alphabet in order, assembling letters ABCD…
-
comment
Comment #30423924
May have been a DAWG like this: https://www.cs.cmu.edu/afs/cs/academic/class/15451-s06/www/l... These days GADDAG are used which are faster, but usually much less space efficient: …
-
comment
Comment #30423898
Not sure what technique you're using for the answers list, but the compress5.py suggests it's doing a basic bitmap. Base bitmap is 12972 bits, or 1622 bytes (your file lists 1619, …
-
comment
Comment #30423743
Is this just a trie, but you reverse all the words first?
-
comment
Comment #30423578
You can beat 15,412 bytes with a much simpler decompression algorithm than xz. Using variable length encoding on a tail-sorted delta-offset array gets down to 13,180 bytes. Neither…
-
comment
Comment #30423557
A good idea, saves a couple bits depending on alignment.
-
comment
Comment #30422392
I tried this out and got 12,231 bytes Brotli encoded, and 12,493 bytes gzipped, with 16,311 bytes raw -- so the estimate is very close. It compresses better with new lines than if …
-
comment
Comment #30421519
I like your trick of subtracting the prior node size if it's too small, it gets a number of offsets into the lower bucket to save some bits. I took this technique and made a few ch…
-
comment
Comment #30409898
Ah, I replied to myself with more information while you were also replying. I also surmise that the short length of the words makes a DAWG just very heavy. It's not clear to me tha…
-
comment
Comment #30409803
I ended up doing some math on a theoretical DAWG, based on: https://www.cs.put.poznan.pl/dweiss/site/publications/downlo... With 12,822 nodes, you need 57,387 bits for the labels a…
-
comment
Comment #30408969
I think you might have miscalculated bits per bytes here? 8 * 17,763/64,860 = 2.19 Also, I attempted to implement this as described in this paper (variable length encoding the lett…
-
comment
Comment #30408883
A trie representation physically removes letters from the dataset. Leaving it in ASCII means that it still leaves enough information behind that can be compressed well (a trie only…
-
comment
Comment #30408408
A trie will already run-length encode all the first letters into 26*5=130 bits pre-Huffman coding. I doubt RLE will beat that. A trie will in essence RLE every level but without ne…
-
comment
Comment #30408278
Thanks, I'll look into it. This case is interesting though, because the Gameboy doesn't even have native mul/div operators, so I suspect that Huffman coding is as fancy as you're g…
-
comment
Comment #30408258
I tried this method today, but a huge shortcoming here is that a DAWG needs these large pointers between nodes. I based my approach on http://www.wutka.com/dawg.html and http://ste…
-
comment
Comment #30403791
I was thinking that it's probably not quite sparse enough to benefit from RLE as-is, since the number of bits you'd need for your lengths would outstrip the length of your run. If …
-
comment
Comment #30403708
You can get down to 15,559 bytes by combining a trie with Huffman coding: https://github.com/adamcw/wordle-trie-packing However, this doesn't beat general Brotli encoding of a ASCI…