apache/mahout

What pyproject.toml declares requires-python = ">=3.10,<3.13", so pip install qumat on Python 3.13 falls back to the ancient qumat 0.0.1 and tries to build old qiskit-aer from source, which fails. This bites anyone on a current Google Colab runtime, whose default is Python 3.13. Why All of qumat 0.6.0's dependencies (qiskit, qiskit-aer, cirq, amazon-braket-sdk, numpy, scipy) already ship wheels for Python 3.13. Installing with pip install --ignore-requires-python "qumat==0.6.0" works, and the test suite passes, so only Qumat's own metadata is holding support back. How Lift the cap in pyproject.toml to requires-python = ">=3.10,<3.14" (and check uv.lock / any tool.uv overrides still resolve). Add "3.13" to the matrix in .github/workflows/python-testing.yml. Run uv sync && uv run pytest testing/qumat on 3.13 and fix anything that surfaces. Update the supported-versions note in the docs. Scope note: this is for the pure-Python qumat package only. The qumat-qdp wheel (Rust + CUDA) has no

What QuMat currently exposes these gates: not, hadamard, cnot, toffoli, swap, cswap, pauli_x, pauli_y, pauli_z, t, rx, ry, rz, u. Several common gates are missing. This issue tracks adding them, one gate per pull request: apply_s_gate (S, phase of π/2) apply_sdg_gate (S-dagger) apply_tdg_gate (T-dagger) apply_cz_gate (controlled-Z) apply_phase_gate (Phase P(λ), accepting a float or a parameter name like rx) Why S, S†, T† and CZ show up in most textbook circuits and in standard transpilation targets, and the Phase gate is needed for parameterized feature maps. Users currently have to drop down to the underlying SDK to use them, which defeats the point of the unified API. How Follow the pattern of apply_t_gate: Add QuMat.apply_<gate>_gate in qumat/qumat.py. Implement it in all three backends: qumat/qiskit_backend.py, qumat/cirq_backend.py, qumat/amazon_braket_backend.py. Add a row to docs/qumat/basic-gates.md. Add a test in testing/qumat/test_single_qubit_gates.py or test_m

What QuMat.create_empty_circuit() without num_qubits behaves differently on each backend: qc.create_empty_circuit() qc.apply_hadamard_gate(0) # qiskit: CircuitError: 'Index 0 out of range for size 0.' # cirq / braket: ok, the qubit is allocated on demand Actual result: code that runs on Cirq and Braket crashes on Qiskit with a low-level error, so the "write once, run on any backend" promise does not hold for this case. Expected result: one documented behavior shared by all three backends. The quick option is a clear ValueError from QuMat.create_empty_circuit() when num_qubits is missing (or not a positive integer). Alternatively, allocate qubits on demand everywhere, but that is more work on the Qiskit side. Where: qumat/qumat.py and the three backends in qumat/. Add tests covering the chosen behavior on all backends. Environment OS: macOS 14 / Linux Python version: 3.12 Qumat version: 0.6.0 (PyPI) and main at 2d94f8f Part of the Apache Mahout hackathon at Community over Code

What Using the same parameter name on two gates works on Cirq and Braket but fails on Qiskit: from qumat import QuMat qc = QuMat({"backend_name": "qiskit", "backend_options": {"simulator_type": "aer_simulator", "shots": 100}}) qc.create_empty_circuit(2) qc.apply_rx_gate(0, "t") qc.apply_rx_gate(1, "t") # qiskit: CircuitError: "name conflict adding parameter 't'" # cirq: ok [Counter({3: 100})] # amazon_braket: ok Counter({'11': 100}) Actual result: qiskit.circuit.exceptions.CircuitError: name conflict adding parameter 't'. The Qiskit backend creates a new qiskit.circuit.Parameter(name) on every gate call (qumat/qiskit_backend.py, around lines 201 to 219), and Qiskit treats two Parameter objects with the same name as a conflict. Expected result: a parameter name refers to one symbolic parameter wherever it is used, on all three backends. Sharing an angle across gates is the normal case in variational circuits (for example a layer of Rx(theta) on every qubit). How: cach

What cirq_backend.initialize_backend() creates and returns a simulator, but execute_circuit() and get_final_state_vector() ignore the backend argument they receive and construct a fresh cirq.Simulator() each time (qumat/cirq_backend.py, around lines 139 and 211). Actual result: the simulator object chosen at initialization is never the one that runs the circuit. Any simulator configuration (seed, dtype, a different simulator class) is silently lost, and future support for other Cirq simulators (for example DensityMatrixSimulator) cannot work. Expected result: the backend object returned by initialize_backend() is the one used in execute_circuit() and get_final_state_vector(), matching how the Qiskit and Braket backends behave. Where: qumat/cirq_backend.py. Add a test that passes a simulator with a fixed seed (or a mock) and asserts it is the one used. Density-matrix simulation on Cirq (simulator_type="density_matrix") is a natural follow-up once this is fixed. Environment OS: macOS 14