feat: compile ramp pulses to stitched pulses

Nicolas Piotrequested to merge
SPIN_add_long_ramp_pulse_in_RampPulse into main

Explanation of changes

This MR introduces support for compiling long_ramp_pulses in the same way long_square_pulses are handled. The main objectives were to add the new compilation step and reduce redundancy across the codebase. Here's a breakdown of what's included:

  • Unified recursive replacement logic for both long_square_pulse and long_ramp_pulse using a new PulseReplacementSpec dataclass.
  • Refactored replacement logic into a single replace_long_pulses_recursively function to improve maintainability and reduce duplication.
  • Added parameterized tests using pytest.mark.parametrize to validate both pulse types efficiently with minimal duplication.
  • Improved docstrings and naming for clarity and consistency after refactoring.
  • Default empty dict passed via extra_kwargs where no additional pulse arguments are needed.

The changes are backward-compatible and improve readability while enabling extension to more pulse types in the future if needed.

Motivation of changes

Motivate why the particular solution was chosen.

Merge checklist

See also merge request guidelines

  • Merge request has been reviewed (in-depth by a knowledgeable contributor), and is approved by a project maintainer.
  • New code is covered by unit tests (or N/A).
  • New code is documented and docstrings use numpydoc format (or N/A).
  • New functionality: considered making private instead of extending public API (or N/A).
  • Public API changed: added @deprecated and entry in deprecated code suggestions (or N/A).
  • Newly added/adjusted documentation and docstrings render properly (or N/A).
  • Pipeline fix or dependency update: post in #software-for-developers channel to merge main back in or update local packages (or N/A).
  • Tested on hardware (or N/A).
  • CHANGELOG.md for breaking changes and AUTHORS.md have been updated (or N/A).
  • Update Hardware backends documentation if backend interface change or N/A
  • Check whether performance is significantly affected by looking at the Performance metrics results.
  • Windows tests in CI pipeline pass (manually triggered by maintainers before merging).
    • Maintainers do not hit Auto-merge, we need to actively check as manual tests do not block pipeline

For reference, the issues workflow is described in the contribution guidelines.

Merge request reports