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
Expose reformatted parameters #465
Comments
2 makes sense to me given that the transformation is specific to QPU. Where would it live in 1? Also I think with 1 it would need renaming, but that may be true for 2 also |
Keeping this particular function in the cloud client makes sense to me. Why? Because it translates a nice state map into a list with 3's - very SAPI-specific, low-level and ugly. This is related to #166 and #199. I'd say, ideally, we don't use SAPI-specific data encoding anywhere on the client's API surface, and the translation happens internally. |
The
StructuredSolver._format_params
method currently transforms theinitial_state
parameter from a dict to the format expected by the endpoint.This translation, while useful for the user, makes it hard for other libraries (e.g. aws-braket-ocean-plugin) that are trying to mock the behavior of the
DWaveSampler
from dwave-system to do so.It would be helpful to expose this logic in a way that can be used by other libraries. Some possible approaches:
_format_params
method to a public class method, or even a static method. This would allow users/libaries to use the method without needing to authenticate with D-Wave._format_parmas
to theDWaveSampler
level, and expose it as a public method. We would likely want to deprecate the method in the cloud-client.I am inclined towards (2).
The text was updated successfully, but these errors were encountered: