https://mahout.apache.org/blog Apache Mahout Blog 2026-06-28T00:00:00.000Z https://github.com/jpmonette/feed Apache Mahout Blog https://mahout.apache.org/img/mahout-favicon.png <![CDATA[Introducing QuMat v0.6.0]]> https://mahout.apache.org/blog/2026/06/01/Qumat-0.6.0-Release 2026-06-28T00:00:00.000Z We are excited to announce QuMat v0.6.0, the next release of Mahout's quantum machine learning stack.

The main theme of this release is moving QDP from an NVIDIA-focused proof of concept into a broader GPU data plane for quantum ML. QuMat v0.6.0 brings AMD ROCm support to first-class status, closes encoder parity gaps between CUDA and ROCm, adds realistic benchmark workloads, and refreshes the documentation site for users and contributors.

Special thanks to everyone who contributed to this release. We would like to thank PMC members Jie-Kai Chang, Guan-Ming Chiu, Andrew Musselman, Shannon Quinn (PMC Chair) and Trevor Grant. We also thank Committers Hsien-Cheng Huang, and Kuan-Hao Huang, along with contributors Yu-Ting Hsiung (Microsoft), Guan-Hua Wen (Microsoft), An-Te Tsai (Phind), Chao-Hong Yeh (Trend Micro), Han-Wen Tsao, Yu-Chen Lai and the broader Apache Mahout community.

What's New in QuMat v0.6.0​

QuMat v0.6.0 rolls up 111 pull requests since v0.5.0 and introduces several important changes:

  • AMD ROCm support is now first-class. QDP can run native AMD GPU encoding paths through hand-written Triton kernels, making ROCm selectable from the same benchmark workflows as CUDA.
  • CUDA and ROCm encoder coverage is now aligned. Phase, IQP, and IQP-Z encodings now ship on both backends, joining the existing amplitude, angle, and basis paths.
  • QDP adds faster zero-copy and GPU-pointer paths. Float32 batch encoding, DLPack handoff, async prefetching, and IQP GPU-pointer encoding reduce host-device round trips in hot loops.
  • Benchmarks now exercise realistic workloads. The release adds SVHN IQP training, SVHN quantum kernel SVM, data-to-state latency, and amplitude DataLoader throughput benchmarks.
  • The documentation and contributor workflow are cleaner. The docs site now has page frontmatter, self-hosted KaTeX, troubleshooting content, type hints, review guidelines, and a simpler contributor entry point.

Let's look at the major pieces in more detail.

QDP Encoding Parity Across GPUs​

QuMat v0.5.0 introduced QDP as the first public proof of concept for direct state preparation. The goal was to avoid simulating state-preparation circuits just to load classical data into a quantum simulator. Instead, QDP constructs the equivalent state vector directly in GPU memory and exposes it to downstream tools through tensor-friendly interfaces.

QuMat v0.6.0 continues that direction by making the encoding layer more complete and more portable. Before this release, CUDA and AMD ROCm did not have the same encoder coverage, which made direct comparisons difficult and limited ROCm's usefulness in practice.

In v0.6.0, QDP supports the same core encoder set across CUDA and ROCm:

  • Amplitude encoding for normalized state-vector preparation.
  • Angle encoding for one-value-per-qubit rotation inputs.
  • Basis encoding for computational basis states.
  • Phase encoding for phase-feature preparation.
  • IQP encoding for entangled feature maps used in quantum ML workflows.
  • IQP-Z encoding for Z-basis IQP-style feature maps.

On the performance side, this release adds:

  • Float32 zero-copy batch paths for angle and basis encoders, including both single-sample and batched paths in qdp-core and the Python bindings.
  • GPU-pointer encoding for the IQP family, allowing CUDA tensors to pass through DLPack without a host round trip.
  • IQP kernel fusion and grid-stride optimizations to reduce kernel launch overhead and improve occupancy.
  • Async prefetching and native f32 dispatch pipelines to overlap I/O and compute for throughput-bound workloads.

Data-to-state latency scaling (ms/vector, log scale) for amplitude, angle, and basis encoding. QDP (orange) achieves orders-of-magnitude lower latency than both CPU and GPU backends.

Figure: Data-to-state latency scaling (ms/vector, log scale) for amplitude, angle, and basis encoding. QDP (orange) achieves orders-of-magnitude lower latency than both CPU and GPU backends.

AMD ROCm Support​

AMD support is the largest platform change in QuMat v0.6.0. QDP now includes a Triton AMD engine (TritonAmdEngine) with hand-written Triton kernels that run natively on ROCm. This is Mahout's implementation path, not a wrapper around PennyLane.

The AMD path covers amplitude, angle, basis, phase, IQP, and IQP-Z encodings. It is also selectable from the QDP encoding and throughput benchmarks with:

--qdp-backend amd

PennyLane-AMDGPU (lightning.amdgpu) is included in benchmark comparisons as a baseline, but QDP's AMD support does not depend on it.

This release also adds Dockerfile.qdp-amd, making it easier to create a reproducible ROCm test environment even when the developer machine is not an AMD GPU host.

For CUDA users, kernel build targets are now configurable. Instead of hard-coding a fixed compute capability list, build-time configuration can target the GPU architectures users actually need, which improves forward compatibility for newer NVIDIA hardware.

Acknowledgments​

The AMD GPU backend in QuMat v0.6.0 was made possible in large part through collaboration with AMD. A special thank-you goes to AMD Taiwan and Mr. Jeffrey Huang for their crucial support in providing our team with high-performance computing resources.

Access to AMD MI300X hardware was instrumental for contributors working on ROCm support, AMD benchmark coverage, and the broader QDP backend architecture. Their support helped the Apache Mahout community fully explore and enrich the quantum computing capabilities now available in this release.

Benchmarks for Real QML Workloads​

QuMat v0.6.0 adds benchmarks that go beyond synthetic encoder microbenchmarks. The goal is to measure where QDP matters in full or near-full quantum ML workflows: loading data, preparing quantum states, and feeding training or kernel pipelines.

SVHN IQP Variational Classifier​

The SVHN IQP benchmark trains a variational IQP classifier on the Street View House Numbers dataset, using digit 1 versus digit 7 with 200 samples and 200 iterations on two RTX 3090 Ti GPUs.

QDP offloads the IQP encoding step to the GPU in a one-shot pass before training begins. That keeps the training backend independent from encoding cost and makes the data-preparation bottleneck visible.

In this benchmark, QDP GPU outperforms PennyLane GPU at each tested qubit count:

  • 4 qubits: 41 samples/s with QDP GPU versus 33 samples/s with PennyLane GPU.
  • 10 qubits: 20 samples/s with QDP GPU versus 15 samples/s with PennyLane GPU.

SVHN IQP training throughput: QDP GPU vs PennyLane GPU at 4-10 qubits (RTX 3090 Ti)

SVHN Quantum Kernel SVM​

The SVHN Quantum Kernel SVM benchmark runs a precomputed squared inner-product quantum kernel SVM on SVHN amplitude-encoded features at 12 qubits. It measures the end-to-end path from raw pixels to SVM prediction:

feature encoding -> kernel matrix -> SVM fit/predict

This is important because it exercises the whole pipeline rather than just the encoding step.

Data-to-State Latency​

The data-to-state benchmark isolates the path from CPU RAM to a GPU-ready quantum state at 16 qubits, using 65,536-dimensional vectors.

Mahout QDP reaches 0.160 ms/vector in this benchmark:

  • 4.5x faster than PennyLane at 0.716 ms/vector.
  • 56x faster than Qiskit Statevector at 9.030 ms/vector.
  • 477x faster than Qiskit Initialize at 76.243 ms/vector.

PennyLane and Mahout both target GPU in this comparison. The Qiskit baselines run on CPU, with Qiskit Initialize also paying circuit decomposition and transpilation overhead.

Data-to-state latency: Mahout 0.160 ms, PennyLane 0.716 ms, Qiskit Statevec 9.030 ms, Qiskit Init 76.243 ms (log scale)

DataLoader Amplitude Throughput​

The DataLoader benchmark streams 12,800 amplitude-encoded vectors in batches of 64 at 16 qubits.

Mahout QDP reaches 6,101 vectors/s, compared with 1,604 vectors/s for PennyLane. That is a 3.8x throughput improvement for this data-loading workload.

Amplitude DataLoader throughput: Mahout 6,101 vs PennyLane 1,604 vectors/s

All QDP benchmarks can select the AMD backend with --qdp-backend amd, enabling direct CUDA-vs-ROCm comparisons on the same workload.

Installing QuMat with QDP​

The base QuMat package can be installed as usual:

pip install qumat==0.6.0

To install QuMat with QDP support:

pip install "qumat[qdp]==0.6.0"

This installs qumat 0.6.0 and resolves the QDP native extension package, qumat-qdp 0.2.0. As in v0.5.0, these are intentionally different package versions: QuMat is the top-level Mahout quantum ML package, while qumat-qdp is the separately published native extension behind the qdp extra.

The accelerated QDP path requires a compatible GPU runtime. The CUDA path targets Linux x86_64 with NVIDIA CUDA. The AMD path targets ROCm through the Triton AMD engine and is intended for ROCm-capable Linux environments.

Documentation and Developer Workflow​

This release also improves the project around the code. The docs site and contributor workflow received a broad cleanup:

  • Frontmatter on documentation pages so Docusaurus can generate cleaner metadata.
  • Self-hosted KaTeX so math rendering works offline and no longer depends on a CDN.
  • A troubleshooting guide for common install, GPU detection, CUDA, and ROCm issues.
  • CONTRIBUTING content merged into the README so new contributors have fewer entry points to check.
  • Python type hints in QuMat as a first step toward better IDE support and static analysis.
  • PR policy and review guidelines documenting merge criteria and review expectations.
  • Expanded Ruff rules and type-checking CI to keep new code more consistent.
  • pytest-xdist support to reduce CI wall-clock time on multi-core runners.

Other Improvements​

QuMat v0.6.0 also includes several smaller but useful improvements:

  • Cloud storage support for QDP data loading from S3 and GCS remote URLs in addition to local paths.
  • Encoding and dtype enums so Python callers can use structured values instead of bare strings.
  • Pure-PyTorch reference implementations for correctness comparison and CPU fallback.
  • Configurable CUDA kernel targets for better hardware compatibility.
  • More benchmark controls for comparing QDP, PennyLane, Qiskit, CUDA, and ROCm paths.

What's Next​

QuMat v0.6.0 makes QDP a broader GPU data plane rather than a single-vendor acceleration path. The next steps are to harden the CUDA and ROCm implementations, expand benchmark coverage, improve packaging for GPU-specific environments, and continue building end-to-end QML examples that show how QDP fits into real training and kernel workflows.

The QDP roadmap after this release focuses on:

  • More backend validation across NVIDIA and AMD GPU families.
  • Broader benchmark coverage for realistic quantum ML datasets.
  • Better documentation for choosing CUDA, ROCm, and CPU fallback paths.
  • Continued improvements to zero-copy tensor handoff and batched data loading.
  • More complete examples that connect QuMat circuits, QDP encoding, and downstream training code.

We welcome feedback and contributions on the dev@mahout.apache.org mailing list and on GitHub.

]]> Jie-Kai Chang https://github.com/400Ping Hsien-Cheng Huang https://github.com/ryankert01 Mahout Team https://mahout.apache.org <![CDATA[Introducing QuMat v0.5.0]]> https://mahout.apache.org/blog/2026/02/02/Qumat-0.5.0-Release 2026-02-02T00:00:00.000Z We are excited to announce QuMat v0.5.0, the next release of Mahout's quantum machine learning stack.

The main theme of this release is moving QuMat from a circuit abstraction into a more complete quantum ML development platform. The release introduces the first public proof-of-concept of QDP (Quantum Data Plane), adds GPU-accelerated data-to-state encoding, improves QuMat's backend behavior, and tightens the development workflow around testing, packaging, and documentation.

Special thanks to everyone who contributed to this release. We would like to thank PMC members Jie-Kai Chang, Guan-Ming Chiu, Andrew Musselman, Shannon Quinn (PMC Chair), and Trevor Grant. We also thank Committers Hsien-Cheng Huang, Kuan-Hao Huang and Krishna Dave, along with contributors Nai-Jui Yeh (Union.ai), Che-Yu Wu (Synology), Jia-Wei Jiang (TSMC), Guan-Hua Wen, Yu-Chen Lai, and the broader Apache Mahout community.

What's New in QuMat v0.5.0​

QuMat v0.5.0 introduces several important changes:

  • QDP makes its first release appearance. qumat 0.5.0 can now install the QDP extension through the qumat[qdp] extra; the native extension itself is distributed as qumat-qdp 0.1.0.
  • GPU state encoding is now part of the QuMat workflow. QDP prepares quantum states using Rust and CUDA kernels rather than Python-side preprocessing loops.
  • Encoded states can move into PyTorch without a host copy. QDP exposes DLPack-compatible tensors, making it possible to hand CUDA-backed state vectors directly to PyTorch.
  • QuMat's circuit APIs are more complete and better validated. The release expands gate coverage, improves parameter handling, and fixes backend-specific behavior across Qiskit, Cirq, and Amazon Braket.
  • The project is easier to develop and test. The release consolidates Python packaging, adds pytest markers for GPU/QDP tests, and expands CI and documentation around QuMat and QDP.

Let's look at the major pieces in more detail.

QDP: The New Data Plane for Quantum ML​

A common bottleneck in quantum machine learning is preparing quantum states from classical data. Most QML frameworks need to simulate state-preparation circuits to load data into a simulator. For amplitude encoding, that can mean applying a long sequence of rotation gates before the model has done any useful work.

We call this the Hiking Problem: spending most of the time hiking up the mountain, simulating gates only to load data, instead of flying the helicopter and running the actual QML model.

QDP is Mahout's answer to that problem. Instead of simulating a state-preparation circuit, QDP constructs the mathematically equivalent state vector directly in GPU memory. Conceptually, this turns an expensive gate-simulation problem into a memory and vector math problem.

The v0.5.0 release includes QDP as an early proof-of-concept. The target is to reduce data-loading overhead from circuit simulation complexity toward something closer to memory-copy cost, with the long-term goal of 50x-100x faster dataset loading in realistic QML simulation workflows.

The high-level architecture is:

[Disk / Parquet]
      |
      v  Apache Arrow
[CPU RAM]  Rust preprocessing: normalize and pad
      |
      v  PCIe host-to-device
[GPU VRAM]  CUDA kernels: direct state construction
      |
      v  DLPack
[Downstream: PyTorch / Qiskit / PennyLane]

In v0.5.0, QDP supports four encoding families:

  • Amplitude encoding for normalized state-vector preparation.
  • Angle encoding for one-value-per-qubit rotation inputs.
  • Basis encoding for computational basis states.
  • IQP-style encoding for entangled feature maps used in quantum ML workflows.

QDP can read from Python lists, NumPy arrays, PyTorch tensors, and file-backed sources such as Parquet, Arrow, NumPy, and PyTorch files.

Zero-Copy PyTorch Integration​

The first QDP extension package shipped with QuMat v0.5.0, qumat-qdp 0.1.0, focuses on a practical workflow: encode data on the GPU, then pass the encoded state into a tensor framework without copying it back through host memory.

import qumat.qdp as qdp
import torch

engine = qdp.QdpEngine(device_id=0)

qtensor = engine.encode(
    [1.0, 2.0, 3.0, 4.0],
    num_qubits=2,
    encoding_method="amplitude",
)

tensor = torch.from_dlpack(qtensor)
print(tensor)  # Complex tensor on CUDA

This DLPack path is the foundation for building faster quantum ML pipelines: preprocessing can happen in QDP, encoded tensors can stay on the GPU, and downstream training code can consume them through PyTorch.

The proposal-level interface for QDP started from a lower-level direct-amplitude API:

import pyarrow as pa
import torch

import mahout_qdp as qdp

raw_vector = [0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8]
input_data = pa.array(raw_vector, type=pa.float64())

state_vector_gpu = qdp.encode_amplitude(input_data)
dlpack_handle = state_vector_gpu.to_dlpack()
tensor = torch.utils.dlpack.from_dlpack(dlpack_handle)

print(tensor)
print("device:", tensor.device)

The packaged v0.5.0 user-facing API is exposed through qumat.qdp.QdpEngine, but the underlying idea is the same: direct state preparation, GPU-resident buffers, and zero-copy handoff to downstream tensor tools.

Installing QuMat with QDP​

The base Qumat package can be installed as usual:

pip install qumat==0.5.0

To install Qumat with QDP support:

pip install "qumat[qdp]==0.5.0"

This installs qumat 0.5.0 and resolves the QDP native extension package, qumat-qdp 0.1.0. These are intentionally different package versions: Qumat is the top-level Mahout quantum ML package, while qumat-qdp is the first separately published QDP extension behind the qdp extra.

The qumat-qdp 0.1.0 wheels support Python 3.10, 3.11, and 3.12 on manylinux x86_64. The accelerated QDP path requires an NVIDIA CUDA-capable GPU.

The core package is also available directly on PyPI:

For the QDP extension, the development target is Rust 1.85 or newer, CUDA Toolkit 12.2.x or newer, Python 3.11 or newer, PyTorch 2.2.x or newer, PyArrow 16.x or newer, and PyO3 0.21.

Verification and Benchmarking Strategy​

The QDP is designed to be verified in two ways: correctness and performance.

For correctness, the plan is to compare QDP against reference circuit-based initialization:

  1. Generate random input vectors across a broad range of sizes.
  2. Use QDP to construct a state vector directly on GPU.
  3. Use a reference framework such as Qiskit to build and simulate a standard amplitude-initialization circuit.
  4. Compare the resulting states for fidelity.

For performance, the goal is to isolate the Data-to-State pipeline: the time from having a classical vector in CPU RAM to obtaining a ready-to-use quantum state in GPU memory. This explicitly excludes downstream model training so the benchmark measures state preparation itself.

The key baselines are:

  • Qiskit initialize() — the circuit-simulation path.
  • PennyLane AmplitudeEmbedding — a common ML-oriented workflow.
  • Qiskit Statevector(data) — a raw data-loading path.

The two key metrics are:

  • Time-to-State latency — how long one vector takes to become a valid GPU-backed quantum state.
  • Throughput — how many vectors per second the loader can sustain under batched workloads.

The initial benchmark plan targets NVIDIA RTX 30-series GPUs, with scaling tests across state sizes and DataLoader-style batch tests that simulate hybrid QML training loops.

QuMat API and Backend Improvements​

QuMat 0.5.0 also improves the core circuit layer. The release expands gate coverage, adds validation, and fixes backend behavior that could previously make circuits behave differently depending on the selected framework.

Highlights include:

  • Additional gate support, including rotational gates, T gate, CSWAP, and U gate coverage.
  • Better parameter validation, including partially bound parameter checks.
  • Stronger qubit index validation to catch invalid circuits earlier.
  • Backend fixes for Qiskit, Cirq, and Amazon Braket.
  • AWS session support for Amazon Braket backend initialization.
  • draw_circuit() fixes so circuit visualization returns a usable string.
  • Measurement improvements, including overlap measurement and swap-test support.

These changes make Qumat more predictable as a cross-framework API. Users can write circuits at the Qumat layer and move more confidently between simulators and hosted backends.

Better Testing, Packaging, and Documentation​

This release also invests in project infrastructure. That work is less visible than QDP, but it matters for contributors and downstream users.

The v0.5.0 cycle includes:

  • uv-based Python dependency management.
  • Expanded pytest configuration and custom GPU/QDP markers.
  • Ruff and pre-commit integration.
  • Python build workflows and broader CI coverage.
  • New QDP getting-started, concepts, and benchmark documentation.
  • Documentation restructuring under the Qumat and QDP namespaces.

Together, these changes make it easier to reproduce local development environments, run CPU-only tests on ordinary machines, and reserve GPU-specific tests for machines with CUDA available.

What's Next​

QuMat v0.5.0 establishes QDP as a first-class part of Mahout's quantum stack. The next step is to build on that foundation: more encoding coverage, better GPU benchmark coverage, stronger end-to-end quantum ML examples, and smoother documentation for users moving from Qumat circuits into QDP-backed training pipelines.

The QDP roadmap after this release focuses on:

  • Hardening the Rust workspace, CUDA build configuration, pre-commit checks, and integration tests.
  • Expanding the direct-state-preparation core with CUDA kernels, CPU-side normalization and padding, GPU memory management, and Apache Arrow/Parquet ingestion.
  • Improving DLPack safety and resource management around tensor ownership and deleters.
  • Continuing PyO3-based Python binding work.
  • Adding broader fidelity and performance testing across devices.
  • Expanding encoder support and future integrations, including TensorFlow/Cirq paths and larger dataset or multi-GPU workflows.

We welcome feedback and contributions on the dev@mahout.apache.org mailing list and on GitHub.

]]> Jie-Kai Chang https://github.com/400Ping Mahout Team https://mahout.apache.org <![CDATA[Meeting Minutes]]> https://mahout.apache.org/blog/2025/10/24/Meeting-Minutes 2025-10-24T00:00:00.000Z Weekly community meeting​

Subscribe to the Mahout User list for details on joining.

Attendees​

  • Andrew Musselman
  • Trevor Grant
  • Krishna Dave

Discussion​

  • Intro discussion about PyPi to Krishna
  • Discussion on updation of Qumat PyPi release

Next Steps​

  • Krishna, Wes to learn more about PyPi and make accounts
  • New release 0.4.1 to be done, currently on 0.4.
  • Andrew to try using ATR for 0.4.1 release Minutes on GitHub Discussions.
]]> Mahout Team https://mahout.apache.org <![CDATA[Meeting Minutes]]> https://mahout.apache.org/blog/2025/08/01/Meeting-Minutes 2025-08-01T00:00:00.000Z Weekly community meeting​

Subscribe to the Mahout User list for details on joining.

Attendees​

  • Andrew Musselman
  • Trevor Grant
  • Krishna Dave

Discussion​

  • Andrew and Trevor discussed certain UI changes that need to be implemented.
  • They will be reviewing Krishna’s PRs for GSoC in the coming days.
  • Krishna will create GitHub issues for all files that require updates, based on the provided sheet, to track progress and assign work accordingly.

Next Steps​

  • Andrew and Trevor to review Krishna’s PRs.
  • Krishna to prepare and log GitHub issues for required file updates.
  • Follow up on UI changes discussed in the meeting. Minutes on GitHub Discussions.
]]> Mahout Team https://mahout.apache.org <![CDATA[Meeting Minutes]]> https://mahout.apache.org/blog/2025/05/16/Meeting-Minutes 2025-05-16T00:00:00.000Z Weekly community meeting​

Minutes on GitHub Discussions.

]]> Mahout Team https://mahout.apache.org <![CDATA[Qumat 0.4.0 Release]]> https://mahout.apache.org/blog/2025/04/17/Qumat-0.4.0-Release 2025-04-17T00:00:00.000Z Qumat 0.4 Released​

Release notes on GitHub Discussions.

]]> Mahout Team https://mahout.apache.org <![CDATA[Meeting Minutes]]> https://mahout.apache.org/blog/2025/04/11/Meeting-Minutes 2025-04-11T00:00:00.000Z Weekly community meeting​

Minutes on GitHub Discussions.

]]> Mahout Team https://mahout.apache.org <![CDATA[Meeting Minutes]]> https://mahout.apache.org/blog/2025/03/21/Meeting-Minutes 2025-03-21T00:00:00.000Z Weekly community meeting​

Minutes on GitHub Discussions.

]]> Mahout Team https://mahout.apache.org <![CDATA[Meeting Minutes]]> https://mahout.apache.org/blog/2025/03/13/Meeting-Minutes 2025-03-13T00:00:00.000Z Weekly community meeting​

Subscribe to the Mahout User list to ask for details on joining.

Attendees​

  • Andrew Musselman
  • Trevor Grant
  • Krishna Dave

Old Business​

New Business​

  • Word back from PyPi about qumat ownership, they are going to contact the owner of the current package #470 Add Qumat to PyPi
  • Andrew contacted INFRA, got help, will push an ASF Qumat release out
  • Krishna is looking for work when he's back from break
  • Continued meetings with qBraid
  • Gofannon talk at meetup including Qumat
  • PR reviewer from gofannon included on GitHub, reviewed together
]]> Mahout Team https://mahout.apache.org <![CDATA[Meeting Minutes]]> https://mahout.apache.org/blog/2025/02/14/Meeting-Minutes 2025-02-14T00:00:00.000Z Weekly community meeting​

Subscribe to the Mahout User list to ask for details on joining.

Attendees​

  • Andrew Musselman
  • Trevor Grant
  • Krishna Dave

Old Business​

New Business​

]]> Mahout Team https://mahout.apache.org <![CDATA[Mahout at FOSDEM - Introducing Qumat]]> https://mahout.apache.org/blog/2025/01/24/FOSDEM-Talk 2025-01-24T00:00:00.000Z FOSDEM 2025, ULB Solbosch Campus​

Feb 2nd, Brussels, Belgium​

Introducing Qumat! (An Apache Mahout Joint)

There seem to be as many quantum computing languages as there are quantum computers. IBM’s qiskit attempts to address this by providing interfaces to multiple backends, but do we really want a vendor owning the coding ecosystem? What could go wrong? Lulz. Apache Mahout’s Qumat project allows users to write their circuits once and then run the same code on multiple vendors. In this talk we’ll discuss how Apache Mahout’s Samsara project introduced the idea of avoiding vendor lock-in by allowing machine learning experts to author algorithms in a vendor-neutral language that would then run everywhere. This spirit is living on in the Qumat project which allows user to write quantum circuits and algorithms (in a vendor-neutral Python library), which are then transpiled to run on IBM’s qiskit, Google cirq, Amazon Braket, or to extend the library to run on other hardware.

Presented by​

  • Trevor Grant
  • Andrew Musselman
]]> Mahout Team https://mahout.apache.org <![CDATA[Meeting Minutes]]> https://mahout.apache.org/blog/2025/01/24/Meeting-Minutes 2025-01-24T00:00:00.000Z Weekly community meeting​

Subscribe to the Mahout User list to ask for details on joining.

Attendees​

  • Andrew Musselman
  • Trevor Grant

Old Business​

New Business​

]]> Mahout Team https://mahout.apache.org <![CDATA[Meeting Minutes]]> https://mahout.apache.org/blog/2024/12/06/Meeting-Minutes 2024-12-06T00:00:00.000Z Weekly community meeting​

Subscribe to the Mahout User list to ask for details on joining.

Attendees​

  • Andrew Musselman
  • Trevor Grant

Old Business​

New Business​

]]> Mahout Team https://mahout.apache.org <![CDATA[Meeting Minutes]]> https://mahout.apache.org/blog/2024/11/15/Meeting-Minutes 2024-11-15T00:00:00.000Z Weekly community meeting​

Subscribe to the Mahout User list to ask for details on joining.

Attendees​

  • Andrew Musselman
  • Trevor Grant

Old Business​

New Business​

]]> Mahout Team https://mahout.apache.org <![CDATA[Meeting Minutes]]> https://mahout.apache.org/blog/2024/11/01/Meeting-Minutes 2024-11-01T00:00:00.000Z Weekly community meeting​

Subscribe to the Mahout User list to ask for details on joining.

Attendees​

  • Andrew Musselman
  • Trevor Grant

Old Business​

New Business​

Trevor and Andrew taking these

]]> Mahout Team https://mahout.apache.org <![CDATA[Meeting Minutes]]> https://mahout.apache.org/blog/2024/10/04/Meeting-Minutes 2024-10-04T00:00:00.000Z Weekly community meeting​

Subscribe to the Mahout User list to ask for details on joining.

Attendees​

  • Andrew Musselman
  • Jowanza Joseph
  • Tommy Naugle
  • Trevor Grant

Old Business​

New Business​

]]> Mahout Team https://mahout.apache.org <![CDATA[Meeting Minutes]]> https://mahout.apache.org/blog/2024/09/27/Meeting-Minutes 2024-09-27T00:00:00.000Z Weekly community meeting​

Subscribe to the Mahout User list to ask for details on joining.

Attendees​

  • Andrew Musselman
  • Tommy Naugle
  • Trevor Grant

Old Business​

New Business​

]]> Mahout Team https://mahout.apache.org <![CDATA[Meeting Minutes]]> https://mahout.apache.org/blog/2024/09/20/Meeting-Minutes 2024-09-20T00:00:00.000Z Weekly community meeting​

Subscribe to the Mahout User list to ask for details on joining.

Attendees​

  • Andrew Musselman
  • Tommy Naugle

Old Business​

New Business​

]]> Mahout Team https://mahout.apache.org <![CDATA[Meeting Minutes]]> https://mahout.apache.org/blog/2024/08/30/Meeting-Minutes 2024-08-30T00:00:00.000Z Weekly community meeting​

Subscribe to the Mahout User list to ask for details on joining.

Attendees​

  • Andrew Musselman
  • Tommy Naugle
  • Trevor Grant

Old Business​

New Business​

]]> Mahout Team https://mahout.apache.org <![CDATA[Meeting Minutes]]> https://mahout.apache.org/blog/2024/08/09/Meeting-Minutes 2024-08-09T00:00:00.000Z Weekly community meeting​

Subscribe to the Mahout User list to ask for details on joining.

Attendees​

  • Andrew Musselman
  • Tommy Naugle
  • Trevor Grant

Old Business​

New Business​

  • Move to GitHub Issues
  • Added GitHub Issues, Projects, and Wiki
  • Add "talks" page to web site
]]> Mahout Team https://mahout.apache.org