-
Notifications
You must be signed in to change notification settings - Fork 582
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
_operator_map and _observable_map are now class attributes. #48
Conversation
…map are now required and are class attributes.
Returns: | ||
tuple(float, float): Mean photon number and variance. | ||
""" | ||
return state.mean_photon(wires), 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to return 0
for the variance here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I'm planning to submit a quick fix to SF today so that mean_photon also returns the variance
# estimate the expectation value | ||
# use central limit theorem, sample normal distribution once, only ok | ||
# if shots is large (see https://en.wikipedia.org/wiki/Berry%E2%80%93Esseen_theorem) | ||
ex = np.random.normal(ex, np.sqrt(var / self.shots)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we modify this so that it actually runs the simulation self.shots
times?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm on the fence, what do you think? It would add significant overhead for large number of shots
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be worth making an issue about this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking more that we need to be careful with a low number of shots; in that case, it is not a very good estimator. On the flip side, in that case, the overhead of repeatedly running the simulation wouldn't be too bad
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we use an heuristic to decide? I.e. for shots < 10
(arbitrarily chosen) we rerun the simulation, and for shots > 10
, we use the central limit theorem
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, probably the best solution for now. Maybe a number higher than 10 though?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the whole, looks good for merging. Most of my comments are small points/questions
Yes.
--
Christian Gogolin
http://www.cgogolin.de
|
Main changes:
_operator_map
and_observable_map
are now required class attributes for all devices. This simplifies plugin development, as the developer no longer needs to importDeviceError
and raise issues if incorrect operators/observables are passed. Instead, this is handled in the background byDevice
.Device.supported()
now directly queries the operator and observable maps, and no longer needs to be overwritten by the developer either.Note that
_operator_map
and_observable_map
do not need to map to anything useful (i.e. they could all map toNone
, if the plugin developer wishes - it is entirely up to the developer). All that is required is that the supported keys are provided.Other changes:
default.qubit
plugin to use the new suggested API