Batched methods + simplified settings

[ziofil]

Description of the Change:

• L2_norm, purity, probability can now work element-wise along the batch dimension or globally. This enables using the batch dimension more freely.

• simplified docstrings in Settings class

• adds setting CIRCUIT_DRAW_PARAMS to set whether the circuit drawer should just draw the name of components or their parameters as well

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 97.91667% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 87.63%. Comparing base (f4356d7) to head (8928d89).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #391      +/-   ##
===========================================
- Coverage    87.72%   87.63%   -0.10%     
===========================================
  Files           81       81              
  Lines         6182     6128      -54     
===========================================
- Hits          5423     5370      -53     
+ Misses         759      758       -1     

Files	Coverage Δ
mrmustard/lab/gates.py	97.24% <100.00%> (ø)
mrmustard/lab_dev/circuit_components.py	96.06% <100.00%> (+0.04%)	:arrow_up:
mrmustard/lab_dev/circuits.py	95.45% <100.00%> (ø)
mrmustard/lab_dev/transformations/base.py	100.00% <100.00%> (ø)
mrmustard/physics/ansatze.py	95.13% <ø> (ø)
mrmustard/physics/gaussian_integrals.py	100.00% <100.00%> (ø)
mrmustard/physics/representations.py	99.46% <100.00%> (+0.01%)	:arrow_up:
mrmustard/lab_dev/states/base.py	96.54% <96.29%> (-0.16%)	:arrow_down:
mrmustard/utils/settings.py	99.04% <97.72%> (+0.71%)	:arrow_up:

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update f4356d7...8928d89. Read the comment docs.

[SamFerracin]

I'm ok with most of the changes in PR. Just a concern about the setting.ELEMENT_WISE, this is a label to say if we want element wise matmul of the representation or not. But it is still a problem if we use batch to interpret everything in MM. For example, if we do state@measurement, if this settings would be a thing there?

I do agree with @sylviemonet that these batched methods are rushed and should be thought over in the larger context of things. The risk is ending up with too many functionalities that users use in ways that were not expected, and are incompatible with each other (see the example about detectors). My advice is to encapsulate the concept of batch in its own class, as opposed to leaving it floating around and up to the interpretation of the user/developer. Specifically, it should be made clear what axis represent different "superposition" batches, and what axis represent different "zip" batches. The setting (if needed) should come after that

[ziofil]

@sylviemonet if we do state@measurement with ELEMENT_WISE = True we mean that we zip the batch dimensions of state and measurement, which will have to match. If it is False (default), then it's the kron of the batch dimensions as usual. It's not always possible to do, and we trust users to know when to use it. We can put guardrails if needed, but I think this is the easiest way to implement both functionalities and it's a simple switch that you can turn on and off. @SamFerracin what example about detectors? if you have an example of how this idea could fail please let me know. For now we keep it as it's already working as it should.

[ziofil]

Actually, I changed my mind. You're both right, and this is probably the solution (which was thrown around in the past) we keep a batch dimension that we always zip over and that grows when we concatenate batches, and a linear combination dimension that we kron over when we multiply and append to when we sum.