Adding noise statements to squin

[johnzl-777]

Some initial friction points/anticipated changes I can immediately see in translating this to stim

• The original PauliChannel definition from @kaihsin can take a variable number of float arguments, but in the stim dialect there are explicit fields for each probability of a 1Q/2Q pauli operator being applied. My feeling is that this should be reflected on the squin side as just something like 1QPauliChannel and 2QPauliChannel with explicit fields. I don't think we'd lose any generality here along with the added benefit that it would be much harder for a user to misinput information (the default definition assumes you plug in either 3 or 15 values via varargs but it seems to easy to make a mistake here)
  • If we DO want varargs I'm not quite sure how to nicely feed this to the kirin @wraps decorator
• From New Squin statements.  #200 , I see it could be possible to not have to provide an operator for basis and instead use a CliffordString (although I'd have to restrict CliffordString even further, to just the Pauli Operators. Would it be worth having something like a PauliString? Or is that silly?)

cc: @weinbe58 @Roger-luo @kaihsin

[github-actions]

☂️ Python Coverage

current status: ✅

Overall Coverage

Lines	Covered	Coverage	Threshold	Status
6335	5451	86%	0%	🟢

New Files

File	Coverage	Status
src/bloqade/squin/noise/_init_.py	100%	🟢
src/bloqade/squin/noise/_dialect.py	100%	🟢
src/bloqade/squin/noise/stmts.py	100%	🟢
TOTAL	100%	🟢

Modified Files

File	Coverage	Status
src/bloqade/squin/_init_.py	100%	🟢
TOTAL	100%	🟢

updated for commit: f1cde89 by action🐍

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

📢 Thoughts on this report? Let us know!

[johnzl-777]

This is the simplest port of the noise statements that @kaihsin originally produced.

I just have some observations/ideas that I'd appreciate getting feedback on (if it's worth it, I can make an RFC)

• PauliChannel in this PR can take any number of floats but in Stim it boils down to either 3 values for a 1Q channel or 15 values for a 2Q channel. In the Stim dialect those numbers are fixed per statement. While I can certainly enforce the correct number of values during code generation I don't think it would hurt to just mirror that structure in squin.
• Should PPError in squin map to the CORRELATED_ERROR...ELSE_CORRELATED_ERROR functionality in Stim? In which case, that should be added into the Stim dialect itself?

[Roger-luo]

LGTM can we have some basic tests on the constructors? Or maybe you could help @david-pl add the corresponding runtime in a new PR (which should test this too). I think would be nice to have it before next week's hackthon.

[david-pl]

@Roger-luo I'm happy to add the runtime. I'd just like to have #207 merged first.

Are there any plans for adding a rewrite pass that injects the noise as well?

[weinbe58]

@Roger-luo + @david-pl I think we could simplify the runtime if we added a target which would be able to handle a wider variety of channels and would be easy to implement with PyQrack using the current runtime in #185

@statement(dialect=dialect)
class StochasticUnitaryChannel:
    operators: ir.SSAValue = argument(ilist.IListType[OpType, NumOperators]
    probabilities: ir.SSAValue = argument(ilist.IListType[float, NumOperators]

you could basically just rewrite all these other specialized noise channels to this statement and then the runtime would be just randomly select which operator to apply.

[johnzl-777]

From discussing with @Roger-luo and @weinbe58 I agree this PR is good to go (apologies again for sitting on this!) and just wanted to put down two notes:

• @Roger-luo asked for some simple unit tests on the constructors, I'll make a separate PR for that
• @weinbe58 's proposed additional statement will also go into a separate PR 👍