Closed pedrorrivero closed 2 months ago
Adding variances is a good idea 👍🏻
About renaming values
to expvals
: I think we're not really using abbreviations anywhere in the user-facing interfaces but typically tend write the full word, so expvals
is not really fitting this scheme. I personally think values
is clear enough since it's an attribute on the estimator. But if you think it's not clear enough maybe we can use expectation_values
(which gets a bit long though)?
Yes, I was first considering expectation_values
, and also thought it was kind of long @Cryoris .
My main issue with values
is that it is kind of vague. In statistics there are estimators for the variance (e.g. Bessel's), so just using the word "value" does not feel specific enough. What value? On top of that, but certainly less important, it can cause confusion with key-value pairs in a dictionary.
Maybe expvals
is not the right name, but I think it would be nice to think of a more descriptive alternative. I am open to suggestions!
UPDATE: expectation_values
seems to be receiving good feedback. Other alternatives are expectations
and means
.
I close this because the discussion is obsolete
What should we add?
In the context of
EstimatorResult
:values
field, forexpvals
. The former is not only too generic but also misleading (i.e. reminds of key-value pairs), whereas the latter is specific to statistics and directly relatable to quantum mechanics.variances
field, pulling it out of metadata. Since the result that we provide is statistical in nature, variances should have better exposure and be enforced. If calculating exact expectation values using a simulator, individual variances can always be set to zero.EstimatorResult
data structure is not related to numpy in any straightforward way, so returningndarray
seems unwarranted; since that is a mainly operational data type and what we really want here is data exchange, not performing fancy operations like vector addition. Users that need numpy can always cast.metadata
. Lists are mutable, and the dataclass hasfrozen=True
, which seems contradictory. This should also be taken into account in the previous request to remove numpy data types.