-
Notifications
You must be signed in to change notification settings - Fork 125
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
BaseMetadata #24
Comments
Perhaps the last one can be just a line scan. So there are roughly two types. Another case would be 2D scan, but I don't have any mandatory experiment for now. Thus it can be future extension. |
A dataclass seems like a nice way to document metadata for an experiment. Though if we use them we should try and use the dataclass package functionality rather than add our own dict like API wrapper on top of it. Most of the extra methods here seem unnecessary:
|
Thanks Chris for the feedback
def get_x_value(self) -> Tuple[float, float]:
return (self.frequency, self.amp) |
Anything the end user cares about should be in the analysis result, and the average user never needs to see raw metadata. It's only there so you can run the analysis. This is why I think it should just be a simple container (whether dict, simple namespace, dataclass etc), not something you add a lot of methods to. Extra methods for getting values or processing should be part of the analysis classes + data processor classes where the metadata is used. It seems like most of what this is aiming to accomplish with the x-y values would also be accomplished by having general purpose analysis classes for the various types of curve fitting. These should then be used as parent classes for other experiments. |
I understand. It sounds like dataclass is not necessary and analysis should know the field of metadata, i.e. generator and analysis are attached to the same experiment. The purpose of this issue is to decouple metadata from analysis to make general purpose analysis as you mentioned. This means extract function API proposed in #23 is sufficient and I can close the issue. |
What is the expected behavior?
As I wrote here, having a formatted metadata will be useful to extract x and y values, see #23. Currently, xvalue appears as different name in PRs ("delay" in #5 , "meas_basis" in #7, "xdata" in #18 ), so the naming rule is up to person who implements the module. Though this improves readability of metadata, this will be a real headache to write the analysis superclass.
Here I propose to define dataclass with some helper method:
We assume we can identify an experiment entry with x_value and series, i.e. x_value is horizontal axis of the graph, while series indicates a label of line. Some experiment may have only series, values can be provided by a method so that we don't need to fill metadata with empty value (still we can guarantee the extraction method proposed in #23 can access to values).
The extraction method may become
since x_value is provided by metadata itself. Series becomes kwargs because it may be defined by a dictionary.
The
.check_entry
method will returnTrue
if input kwargs mathces with the metadata.I assume we can cover almost all typical experiments with below 3 sub types:
No scan:
Discriminator experiment
Process tomography
Line scan:
Interleaved randomized benchmarking
T1 measurement
Line scan with multiple series
Hamiltonian tomography
The text was updated successfully, but these errors were encountered: