An interface to GNU Octave language

[pr0m1th3as]

An interface to GNU Octave language is missing. It would be nice to have a volesti package in the Octave Packages index that would allow Octave users to use your library with native Octave code.

This library would be a very useful extension to the statistics package that already provides a significant set of statistical analysis functions.

Consider this feature request as a project idea for GSoC 2026!

[Adityabaskati-weeb]

@TolisChal can i start implementing above idea ?

[KrishanYadav333]

An interface to GNU Octave language is missing. It would be nice to have a volesti package in the Octave Packages index that would allow Octave users to use your library with native Octave code.

This library would be a very useful extension to the statistics package that already provides a significant set of statistical analysis functions.

Consider this feature request as a project idea for GSoC 2026!

Hi ! I'd like to work on implementing the GNU Octave interface for volesti.

Proposed Solution

I’m planning to build an Octave package using MEX wrappers, taking inspiration from how the R interface is organized.

My plan is to build a small Octave package using MEX wrappers, similar to how the R interface is structured. I’ll create a C++ wrapper layer with octave/oct.h, set up the standard Octave package layout, and expose the main VolEsti functions like:

volume(A, b)
sample_uniform(A, b, n)
sample_gaussian(A, b, n)

and the basic polytope generators.

I’ll use the existing C++ core with minimal changes and compile everything with mkoctfile to ensure smooth integration with Octave’s native matrix types. I’ll also include documentation, examples, and optional integration with the Octave statistics package workflows.

If this approach looks good, could this issue be assigned to me? I can also provide more detailed information if needed.

[ChinmayRout9040895625]

An interface to GNU Octave language is missing. It would be nice to have a volesti package in the Octave Packages index that would allow Octave users to use your library with native Octave code.

This library would be a very useful extension to the statistics package that already provides a significant set of statistical analysis functions.

Consider this feature request as a project idea for GSoC 2026!

Hi @pr0m1th3as! Thanks for sharing this idea — I agree that an Octave interface for volesti would be a valuable addition, especially in combination with the existing statistics package.

A practical and maintainable approach could be to implement a thin Octave binding layer on top of the existing C++ core, using Octave’s native C++ interface (oct-files / MEX-style bindings). This would allow us to reuse volesti’s well-tested algorithms directly, without duplicating logic in Octave code.

Concretely, a possible design could be:
(1) "A standalone Octave package (e.g. volesti-octave) that wraps selected volesti functionality."
(2) "Initial focus on a small, high-impact subset:'
() "volume estimation for standard convex bodies (e.g. cubes, simplices, H-polytopes),"
() "Gaussian and uniform sampling via existing random walks."
(3) "Octave-facing functions that return native Octave data structures (matrices, vectors), making them easy to combine with workflows from the statistics package."

This package could remain loosely coupled to the statistics package at first (interoperable rather than tightly integrated), while following similar conventions so that users can naturally combine both in Monte Carlo and statistical pipelines.
I’d be very interested in developing this further if the approach aligns with the project’s goals.

Thank you!

[Sid0004]

I can do it...may i?

Hi @TolisChal , @pr0m1th3as,

I would like to work on this.

I’ve reviewed the requirements and the suggestions above. I agree that using the native Octave C++ API (oct-files) via mkoctfile is the best approach for performance and integration with volesti's existing C++ core.

To move this forward, I propose submitting an initial "skeleton" PR. My plan is to:

Set up the basic directory structure and build script (integrating mkoctfile).

Implement a single wrapper for the volume function to validate the conversion between Octave matrices and volesti types.

This will establish the build pipeline so we can incrementally add the samplers and other features. Shall I proceed with this initial setup?

[codesensei-tushar]

Hi @pr0m1th3as, @vissarion, and @TolisChal,

I am very interested in picking up this feature request (potentially as part of a GSoC 2026 proposal).

To get started, I have submitted a Proof of Concept (PoC) in PR #403.

This PR implements a "vertical slice" of the native interface, focusing on:

Build Infrastructure: Successfully linking mkoctfile with C++17 and Volesti dependencies.

Architecture: I implemented a "Single Copy" strategy using Eigen::Map to handle data transfer. I noticed this differs from Rvolesti (which appears to use deep copying), so I achieved a significant performance gain (~0.01s for 10D hypercubes) but I am very curious to hear your thoughts on the safety vs. speed trade-off here.

I would love your feedback on the architecture, specifically regarding the memory management strategy outlined in the PR description. I am eager to learn and ready to iterate on this based on your suggestions!