Skip to content

Conversation

@thisac
Copy link
Contributor

@thisac thisac commented Dec 19, 2025

Draft of a samplers submodule. Still missing full test coverage, and a consensus on whether this is what we want or not.

Copy link
Collaborator

@kevinchern kevinchern left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Theo, this is looking good and motivates some topics for discussion. A purpose of the changes proposed in this PR is to decouple models and samplers. In essence, my comments are concerned with this goal. For example, objects like GRBMs should no longer have a to_ising method, as that method is specific to dimod models and dimod sampling. As a consequence (maybe tangentially), I propose we wrap and hide dimod and dimod-motivated objects (e.g., sample sets, and to_ising).

"""PyTorch plugin wrapper for a dimod sampler.

Args:
module (GraphRestrictedBoltzmannMachine): GraphRestrictedBoltzmannMachine module. Requires the
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any particular reason to name it module instead of grbm?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really. Remnant from wanting it to be a generic module but not having a reasonable base class to use.


Args:
module (GraphRestrictedBoltzmannMachine): GraphRestrictedBoltzmannMachine module. Requires the
methods ``to_ising`` and ``nodes``.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this new interface, to_ising method should be removed from GRBM and implemented elsewhere as a function (not in this sampler either).

self,
module: GraphRestrictedBoltzmannMachine,
sampler: dimod.Sampler,
prefactor: float,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we remove prefactor, linear_range, and quadratic_range from DimodSampler?
This restriction is primarily motivated by a QPU's limitations and not a typical constraint in classical samplers.
I need to give this more thought..

return sampleset_to_tensor(self._module.nodes, self._sample_set, self.device)

@property
def sample_set(self) -> dimod.SampleSet:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove property and keep the sample set a hidden attribute; the public interface should not be concerned with dimod objects.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was requested by @VolodyaCO for the GRBM class previously, so it seems useful, no?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@VolodyaCO what's the use case?

@thisac thisac force-pushed the feature/samplers branch 2 times, most recently from 3c93210 to 60c3cee Compare December 24, 2025 00:45
@kevinchern kevinchern mentioned this pull request Jan 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants