Skip to content

Conversation

@rileyjmurray
Copy link
Contributor

@rileyjmurray rileyjmurray commented Oct 17, 2025

This PR is split off of #664, which I've since closed for being too large in scope.

This PR has major backward-compatible changes to the gaugeopt_to_target and _create_objective_fn functions in gaugeopt.py.

  • Changes to gaugeopt_to_target are designed to clarify how it serves as a wrapper to gaugeopt_custom (which is also a wrapper, of wrappers, ...).
  • Changes to _create_objective_fn are to split out its two codepaths into separate functions: _legacy_create_scalar_objective_fn and _legacy_create_least_squares_objective_fn.

Both of these changes are stepping stones so we can introduce new types of gauge optimization in the future. My vision is that one day we'll be able to include user-defined black-box objective functions in gauge optimization suites. This will enable future prototyping without reaching into gauge optimization plumbing.

This PR also changes the definition of fidelity as a gauge optimization objective. It's now defined in such a way that if two models exhibit no relational errors with respect to one another, then it's possible to drive the fidelity-based loss function to zero even if the models are not gauge-equivalent. As part of this effort I introduced a new function in optools.py called eigenvalue_fidelity. This function computes fidelity of two states in a way that pretends they share an eigenbasis. There's an option of ordering eigenvalues in a gauge-invariant way or in a way that's technically gauge-dependent yet still robust.

Small changes to model.py and explicitopmodel.py: type annotations for copy methods.

…two codepaths in _create_objective_fn into their own functions, called _legacy_create_scalar_objective and _legacy_create_least_squares_objective
…s to values based on module-wide or class-wide constants
@rileyjmurray
Copy link
Contributor Author

Note: the fact that eigenvalue_entanglement_fidelity in reportables.py rather than optools.py is a weirdness related to issue #526.

Comment on lines +1631 to +1642
if is_unitary and is_tp:
evA = _np.linalg.eigvals(a)
evB = _np.linalg.eigvals(b)
_, pairs = _tools.minweight_match(evA, evB, lambda x, y: abs(x - y),
return_pairs=True) # just to get pairing
fid = abs(_np.sum([_np.conjugate(evB[j]) * evA[i] for i, j in pairs])) / d2
else:
Ja = _tools.fast_jamiolkowski_iso_std(a, mx_basis)
Jb = _tools.fast_jamiolkowski_iso_std(b, mx_basis)
from pygsti.tools.optools import eigenvalue_fidelity
fid = eigenvalue_fidelity(Ja, Jb, gauge_invariant=True)
return 1.0 - fid
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Would be nice to figure out how to do eigenvalue matching in the is_unitary and is_tp codepath to be consistent with the matching in the second codepath.

…lt values to values based on module-wide or class-wide constants"

This reverts commit b2b6746.

I moved the contents of that commit to another branch.
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.

1 participant