Sampler primitive and shots (number of samples) handling

[woodsp-ibm]

What should we add?

In using the Sampler in algorithms some observations have been made around access to the number of samples (shots) which some want to control and/or read/use as part of their function.

At present algorithms are accessing shots (or trying to since it may not be there) from the run_options when provided with a BaseSampler instance. If a user has not configured shots into this default run_options, and say internally it defaults to some value, whatever this value is cannot presently be known... at least until the result is computed... and if it's put in the result metadata.

Some algorithms also want to set the number of samples (shots). This does not seem to be an aspect that can be known whether it can be set or not whereby say a sampler that was configured by some quality metric that determined the number of shots may not give direct access to shots.

In the result shots are part of the metadata. It would seem that number of samples for a sampler perhaps should be a more intrinsic part of the result so it can be relied upon rather than being in metadata. Now the result contains a QuasiDistribution that has shots on the constructor (defaults to None) and is a public instance var that does not seem to be set. Perhaps this should be the place where shots is set and there is no need for a specific field in the result since it can be conveyed via the quasi dist.

I guess for a Sampler number of samples feels like it should be more a direct part of the capability rather than "hidden" in run_options and metadata. I understand that we might want more indirect ways to set this going forwards but for algorithms that want/need to be more explicit in number of samples and knowing the value used the present state of shots/num samples handling seems like there could be room for improvement.

[t-imamichi]

I close this because the Sampler V1 is deprecated #12575