BaseMetadata about qiskit-experiments HOT 5 CLOSED

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.

from qiskit-experiments.

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:

• rather than wrap to_dict just use its built in asdict, though in general if we are using dataclass we should avoid using them as dicts except when serializing for execution or DB storage.
• check_entry should use hasattr(datacls, attr) not conversion to dict. You could probably do something with dataclasses.fields instead. Part of the point of using dataclasses is you dont need to do these checks, you can use type checking instead to know it has certain fields or not.
• I don't think building in methods for returning xvalues is necessary. If an experiment has a metadata parameter for x-values it should just save it as xval: float. This can just be accessed using data.xval or `getattr(data, xval). Of course this only matters for experiments where you plan on using common analysis classes (such as curve fitting).

from qiskit-experiments.

Thanks Chris for the feedback

• About to_dict; Yes we can use built-in function. However, this indicates we need to import dataclass in many modules. This is just to avoid importing dataclass.
• About check_entry; I totally agree. The code above is just an example to show concept (maybe I should write pseudo code...).
• About xval; I think this depends who uses metadata. If metadata is a public member (and intended to be exposed to end-users), I prefer more meaningful name rather than just xval. Another useful case of method is multi axes scan. Adding data.xval1 and data.xval2 will be the most straightforward approach to create metadata, but this is quite confusing and developer may induce a bug. If this is implemented as a method, we can override this with, for example

    def get_x_value(self) -> Tuple[float, float]:
        return (self.frequency, self.amp)

from qiskit-experiments.

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.

from qiskit-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.

from qiskit-experiments.