search

Infleqtion / qLDPC

Tools for constructing and analyzing quantum low density parity check (qLDPC) codes.
Apache License 2.0
73 stars 8 forks source link

Puncture and shorten `ClassicalCode`s #41

Closed perlinm closed 5 months ago

perlinm commented 5 months ago

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 commented 5 months ago

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

mittaltushant commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 https://github.com/Infleqtion/qLDPC/pull/41#issuecomment-2020470622, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE6JBDIUOULEIA4PQ5T2GWDY2F3URAVCNFSM6AAAAABFF3OOLCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRQGQ3TANRSGI. You are receiving this because you were mentioned.