All SampleMeasurement processes include a dtype optional parameter

[PietropaoloFrisoni]

Context: In this PR, we extend the usage of the dtype optional parameter to all measurement processes inheriting from SampleMeasurement (except for qml.counts as this always returns a dict with integer keys and values):

• qml.expval
• qml.var
• qml.probs
• qml.sample (already implemented in this PR)

Description of the Change: As above.

Benefits: More flexibility and symbolic (imaginary) speed up improvement.

Possible Drawbacks: None that I can think of.

Related GitHub Issues: None.

[sc-98735]

[github-actions]

Hello. You may have forgotten to update the changelog!
Please edit doc/releases/changelog-dev.md with:

• A one-to-two sentence description of the change. You may include a small working example for new features.
• A link back to this PR.
• Your name (or GitHub username) in the contributors section.

[albi3ro]

Can we add this to MeasurementProcess as a whole instead?

[PietropaoloFrisoni]

Can we add this to MeasurementProcess as a whole instead?

@albi3ro Yes, that was already in the commit that I was going to push : )

GitHub accidentally tagged our team automatically, but this PR is still not ready for review. Sorry for the notification!

[JerryChen97]

Is this already ready for review?

[PietropaoloFrisoni]

Is this already ready for review?

No, please look at this PR instead (which only adds this new optional parameter to SampleMP)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.40%. Comparing base (17e337f) to head (bdf5de1).
⚠️ Report is 22 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff            @@
##           master    #8214    +/-   ##
========================================
  Coverage   99.39%   99.40%            
========================================
  Files         551      552     +1     
  Lines       57223    57375   +152     
========================================
+ Hits        56879    57031   +152     
  Misses        344      344            

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[JerryChen97]

pylint seems to be catching some mismatches 🤔

[PietropaoloFrisoni]

@JerryChen97 Please ignore this PR as it is not review-ready : )

[albi3ro]

@qml.qnode(qml.device('default.qubit'))
def c():
    return qml.expval(qml.X(0), dtype=np.float16)

c().dtype

dtype('float64')

Also need to convert in analytic mode.

But for analytic processing, we may actually need to go into the relevant device code and add some conversions there too.

[PietropaoloFrisoni]

@albi3ro Exactly, that's why I mentioned in the doc that the dtype argument is ignored if sampling is not used. Otherwise, this might exceed the original time estimate since we probably need to go to the device level and perform conversions in there too. Please let me know what you think.

Also, it seems to me that the main motivation for this was a (future) speed-up improvement, which is particularly relevant when samples are used. Do we expect any major performance benefit in providing a dtype argument for analytic processing?

[PietropaoloFrisoni]

For observables multiplied by complex coefficients, indices might be created as a complex array, but it should always be integer

[albi3ro]

@albi3ro Exactly, that's why I mentioned in the doc that the dtype argument is ignored if sampling is not used. Otherwise, this might exceed the original time estimate since we probably need to go to the device level and perform conversions in there too. Please let me know what you think.

If it's too much work to get the feature done right now, then we can just backlog it and come back to this later. Getting the feature in for qml.sample was the most important part.

[PietropaoloFrisoni]

@albi3ro Sounds good. I will 'freeze' this PR and backlog the story then.

I will still add a 1-line change in a separate PR as I realized that in case of a complex coefficient times an observable, the indices created with indices = math.array(indices) in process_raw_samples might be complex (although we all imaginary parts equal to zero). This causes issues when we use them as indices. I'll push a fix later