Skip to content
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

Reparameterizing model doesn't propagate to model members dictionaries #367

Closed
coreyostrove opened this issue Nov 8, 2023 · 2 comments
Closed
Assignees
Labels
bug A bug or regression

Comments

@coreyostrove
Copy link
Contributor

A BOGO special on the bugs uncovered by unit test refactors (I stumbled onto this when working through some problems related to #366 ). When reparameterizing a model using set_all_parameterizations this change in parameterization doesn't propagate to the default_param attribute of the model's various contained OrderedMemberDict objects (i.e. the values of model.preps, model.operations etc.). This attribute controls the casting behavior that is invoked when directly setting the value of an entry in an OrderedMemberDict when setting this value to a numpy array. E.g. if the value of default_param for this OrderedMemberDict is 'full TP' then directly setting the value of model.operations with an array will cast this array to a FullTPOp.

Here is a minimal working demonstration.

from pygsti.modelpacks import smq1Q_XY
test_model = smq1Q_XY.target_model('full TP')
print(test_model.preps.default_param)
test_model.set_all_parameterizations('full')
print(test_model.preps.default_param)

The above prints 'full TP' both times.

This feels like unexpected behavior to me, and I'd expect this change in parameterizations to propagate through but I'd be interested in hearing if the other devs have thoughts on this (e.g. are there any places where I might break things by changing this behavior).

Environment (please complete the following information):

  • pyGSTi version: develop
  • python version 3.9
  • OS Windows 11
@coreyostrove coreyostrove added the bug A bug or regression label Nov 8, 2023
@sserita
Copy link
Contributor

sserita commented Nov 8, 2023

I suspect that this is actually the reason for #365 also. So a BOGO on bug fixes when I fix that!

@sserita sserita self-assigned this Nov 8, 2023
sserita added a commit that referenced this issue Nov 9, 2023
@sserita sserita added the fixed-but-not-in-release-yet Bug has been fixed, but isn't in an official release yet (just exists on a development branch) label Nov 9, 2023
@sserita
Copy link
Contributor

sserita commented Nov 29, 2023

Closed with release of 0.9.12.

@sserita sserita closed this as completed Nov 29, 2023
@sserita sserita removed the fixed-but-not-in-release-yet Bug has been fixed, but isn't in an official release yet (just exists on a development branch) label Dec 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A bug or regression
Projects
None yet
Development

No branches or pull requests

2 participants