Hi Ryan, Thank you for the detailed feedback — that’s very helpful.
I’ll start working on the POC focusing first on: - Implementing the Rust encoder with linear entanglement - Reusing the IQP encoding dispatch patterns where possible - Validating numerically against Qiskit on small circuits (2–4 qubits) I’ll open a draft PR once I have the core working end-to-end. Also, I’d love to join the Slack and the bi-weekly meeting — my preferred email is: [email protected] Looking forward to contributing further! Best, Alisha On Mon, Feb 23, 2026 at 5:37 AM Ryan Huang <[email protected]> wrote: > Hi Alisha, > > Thanks for the detailed write-up — this is a well-scoped proposal and > ZZFeatureMap is a natural addition to the encoding suite. > > We'd love for you to go ahead and put together a POC. A few thoughts to > guide you: > > API design: keeps it consistent with the rest of the codebase and plays > better with the Rust type system. > > Qiskit parity: Numerical parity with Qiskit's reference implementation is > the right goal for validation, but we don't need to mirror their API > surface. Matching the gate-level math is what matters. > > Architectural note: Take a look at how the IQP encoding handles its CUDA > kernel dispatch — the ZZ interaction pattern will have similar two-qubit > parallelism constraints and it's worth reusing those patterns where you > can. > > For the POC, I'd prioritize: > 1. The Rust encoder + CUDA kernel with at least linear entanglement working > end-to-end > 2. A basic numerical comparison against Qiskit on a small circuit (2–4 > qubits) > 3. Python bindings can be minimal for now — just enough to run the > validation > > Once the POC is up, open a draft PR against the relevant issue and we can > give more detailed feedback from there. > > To engage with the community, you can join our slack channel (you can give > me your preferred email) and join our bi-weekly community meeting at google > meet. > > Looking forward to seeing you in the community meeting! > > Best, > Ryan Huang > > On Mon, Feb 23, 2026 at 3:49 AM Alisha <[email protected]> wrote: > > > Hi all, > > > > I would like to propose implementing the ZZFeatureMap encoding for QDP > > (GitHub issue #1008, JIRA GSOC-312). > > > > Background > > ---------- > > ZZFeatureMap is widely used in quantum machine learning frameworks such > as > > Qiskit for quantum kernels and variational classifiers. Adding it to QDP > > would complete the encoding suite alongside amplitude, angle, basis, and > > IQP > > encodings. > > > > Understanding > > ------------- > > Each repetition layer consists of: > > > > 1. Applying Hadamard gates to all qubits > > 2. Applying RZ(x_i) rotations per feature > > 3. Applying exp(i x_i x_j Z_i Z_j) ZZ entangling interactions > > 4. Supporting configurable entanglement patterns (full, linear, circular) > > > > Implementation Plan > > ------------------- > > > > 1. Rust Encoder > > - Implement QuantumEncoder trait > > - File: qdp-core/src/gpu/encodings/zzfeaturemap.rs > > - Parameters: num_qubits, reps, entanglement enum > > > > 2. CUDA Kernel > > - File: qdp-kernels/src/zzfeaturemap.cu > > - Parallel RZ application > > - Efficient ZZ interaction implementation > > - Optimized memory access for NVIDIA 30-series GPU > > (I have access to a compatible GPU.) > > > > 3. Python Bindings > > - Integrate via existing QDP API > > - Expose reps and entanglement configuration > > > > 4. Testing > > - Validate against Qiskit reference implementation > > - Numerical tolerance comparison > > - Unit tests for multiple entanglement modes > > > > I would appreciate feedback on: > > - Preferred API design for entanglement configuration > > - Any architectural constraints to consider before implementation > > - Whether exact Qiskit parity is desired or QDP-style adaptation > > > > Looking forward to your feedback. > > > > Best regards, > > Alisha Gupta > > >
