Successive cancellation decoding is a lot like eating a box of chocolates: If you accidentally choose a very flavorful one somewhere in the middle of the consumption, the rest of the chocolates will taste dull.
For PAC codes to work well, we need to abandon the CRC (in favor of a better code-rate) but still can use list decoding. With a list size of just L=64, we come dangerously close to OSD decoding of BCH codes! We also need to replace the Polar code construction (the selection of frozen bits) with something that gives us better distance properties over better polarization properties. Here the Reed Muller based construction comes in handy and is super simple to compute, as you can see in the screenshot.
So just convolving the message bits is not enough. Even though we already use the frozen bits to penalize, it seems like they also need to be scrambled. That means we need to sacrifice the speedup we got from simply collapsing rate-0 nodes, in order to decode them. Stay tuned.
Oh no. I opened another can of worms: Polarization-Adjusted Convolutional (PAC) codes. At this rate, I am never going to finish the next project. Might even break my pinky promise of not changing the next modem scheme anymore. But it's for the greater good! Oops, already did that by adding slashes to the call sign. Ahh well.
Ahmet Inan
How to make a simple audio cable yourself for Robot36 and Rattlegram
3 days ago | [YT] | 0
View 0 replies
Ahmet Inan
Another cable for Robot36 and Rattlegram. Excellent!
6 days ago | [YT] | 0
View 0 replies
Ahmet Inan
Successive cancellation decoding is a lot like eating a box of chocolates: If you accidentally choose a very flavorful one somewhere in the middle of the consumption, the rest of the chocolates will taste dull.
3 weeks ago | [YT] | 1
View 0 replies
Ahmet Inan
Is it just me or are the fscking fireworks getting louder each year?
1 month ago | [YT] | 1
View 0 replies
Ahmet Inan
For PAC codes to work well, we need to abandon the CRC (in favor of a better code-rate) but still can use list decoding. With a list size of just L=64, we come dangerously close to OSD decoding of BCH codes! We also need to replace the Polar code construction (the selection of frozen bits) with something that gives us better distance properties over better polarization properties. Here the Reed Muller based construction comes in handy and is super simple to compute, as you can see in the screenshot.
1 month ago | [YT] | 3
View 3 replies
Ahmet Inan
HoHoHo, merry xmas!
1 month ago | [YT] | 3
View 0 replies
Ahmet Inan
If someone wants to play with my implementation of a PAC list decoder, enjoy:
github.com/aicodix/code/blob/master/pac_list_decod…
1 month ago | [YT] | 0
View 0 replies
Ahmet Inan
It's working! We got closer to what is possible without too much sacrifice. Only 10% slower with a 0.7-rate code! Cheers! 🥂
1 month ago | [YT] | 3
View 0 replies
Ahmet Inan
So just convolving the message bits is not enough. Even though we already use the frozen bits to penalize, it seems like they also need to be scrambled. That means we need to sacrifice the speedup we got from simply collapsing rate-0 nodes, in order to decode them. Stay tuned.
1 month ago | [YT] | 5
View 0 replies
Ahmet Inan
Oh no. I opened another can of worms: Polarization-Adjusted Convolutional (PAC) codes. At this rate, I am never going to finish the next project. Might even break my pinky promise of not changing the next modem scheme anymore. But it's for the greater good! Oops, already did that by adding slashes to the call sign. Ahh well.
1 month ago | [YT] | 4
View 2 replies
Load more