Obtaining basic metadata from dimod models

[pau557]

Application Dimod-supported characterization the object properties

Proposed Solution For each of the canonical models, eg. BQM, DQM, there could be a method that puts together some of the model properties, ie. num_variables, num_biases, num_interactions, etc. and returns them as a dict.

Alternatives Considered The alternative would be to look for all the attributes and methods available and build your own version. This has the danger of breaking compatibility as these models get updated.

Additional Context This is important for analyzing performance of solvers based on problem sizes and other basic properties.

[arcondello]

Got it, we have something like this embedded in the to_file() methods (example), but we could probably expose them as a method. Maybe something like bqm.metadata() or bqm.get_metadata().

You can actually get them from CQMs/QMs/BQMs that have been serialized with read_header.

[arcondello]

So looking at what info is actually in the headers at the moment, it's

        data = dict(shape=self.shape,
                    dtype=self.dtype.name,
                    itype=self.data.index_dtype.name,
                    type=type(self).__name__,
                    variables=not self.variables._is_range(),
                    )

for quadratic model

        data = dict(shape=self.shape,
                    dtype=self.dtype.name,
                    itype=self.data.index_dtype.name,
                    ntype=self.data.index_dtype.name,
                    vartype=self.vartype.name,
                    type=type(self).__name__,
                    variables=not self.variables._is_range(),
                    )

for binary quadratic model (in serialization version 2.0+)

        data = dict(num_variables=len(self.variables),
                    num_constraints=len(self.constraints),
                    num_biases=self.num_biases(),
                    num_quadratic_variables=self.num_quadratic_variables(),
                    )

for constrained quadratic model

There is less overlap than you'd think. I am guessing that it's really only the shape that's relevant to you for QM/BQM. Are the data types, type of the object, and whether or not the variables are index labelled stuff that you would want to keep in metadata?

For CQM, shape is not really well-defined which is why we call the attributes out separately.

[randomir]

Looking at these fields, perhaps we should call them "structure", not metadata? I'm imagining "bqm.info" would be metadata. :shrug:

Seems explicitly calling out num_variables and num_interactions would be clearer and would create more overlap. And we could include types in CQM as well.