Puncture and shorten ClassicalCodes

[perlinm]

These methods will be used in code-search experiments.

Also: added equality testing between ClassicalCodes, and added the ClassicalCode.from_generator constructor.

@mittaltushant no rush, but if you get the chance can you please take a quick look to make sure this looks correct?

[perlinm]

@mittaltushant I'm going to merge but nbd if we need to revise after.

[mittaltushant]

For the equality test function, it seems that the check would not work if one uses a different (but equivalent) parity check matrix/generator matrix. A more foolproof method would be to check if H_1G_2^T = 0 (basically, if the generators of C_2 satisfy all parity checks we have C_2 \subseteq C_1; the other direction can be a simple dimension check).

The rest looks good.

[perlinm]

Hmm that's a good point. I guess that raises a tension in what it means for two ClassicalCode instances to be "equal", or what the expectations of a user would be if I told them that code_a == code_b. Thinking about this more, I'm hesitant to say that code_a == code_b if the two code instances behave differently -- for example by giving rise to different hypergraph product codes. That could be pretty confusing.

I certainly agree though that my current equality test is misguided. I'm sort of leaning having __eq__ just test equality of the data that defines an instance (for a ClassicalCode, the parity check matrix), and adding a ClassicalCode.equiv method that checks (C_a ⊆ C_b) & (C_b ⊆ C_a). Does that sound reasonable?

[mittaltushant]

Yeah it sounds good! I added a comment to green flag the merge but "closed it” by mistake. Sorry for that, Tushant

…

On Mar 26, 2024, at 8:44 AM, Michael A. Perlin ***@***.***> wrote: Hmm that's a good point. I guess that raises a tension in what it means for two ClassicalCode instances to be "equal", or what the expectations of a user would be if I told them that code_a == code_b. Thinking about this more, I'm hesitant to say that code_a == code_b if the two code instances behave differently -- for example by giving rise to different hypergraph product codes. That could be pretty confusing. Certainly my current equality test is misguided. I'm sort of leaning having __eq__ just test equality of parity check matrices (<--> equality between "code instances"), and adding a ClassicalCode.equiv method that checks (C_a ⊆ C_b) & (C_b ⊆ C_a). Does that sound reasonable? — Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE6JBDIUOULEIA4PQ5T2GWDY2F3URAVCNFSM6AAAAABFF3OOLCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRQGQ3TANRSGI>. You are receiving this because you were mentioned.