Closed perlinm closed 5 months ago
@mittaltushant I'm going to merge but nbd if we need to revise after.
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.
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?
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.
These methods will be used in code-search experiments.
Also: added equality testing between
ClassicalCode
s, and added theClassicalCode.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?