As @ccoffrin pointed out, we need to chose a proper standard for naming the binary quadratic models under our attention.

Current cadidates are:

BQP (Binary Quadratic Program)

BQM (Binary Quadratic Model)

QUBO (Quadratic Unconstrained Binary Optimization) ✔️

UBQP (Unconstrained Binary Quadratic Program)

QP (Quadratic Programs)

New suggestions and additions to pros and cons are welcome!

As done in PseudoBooleanOptimization.jl, QUBOTools.jl should have a benchmark suite allowing for comparison between dev and main branches.
Identifying performance regression is a must for QUBOTools.jl to reach v1.

Should we depend on and implement features directed to the MOI/JuMP ecossystem in this package?

Pros:

1. This avoids duplicate code across packages when integrating QUBOTools and JuMP
2. We could provide advanced, homogeneous support for spin variables, i.e., $s \in \lbrace{\pm 1}\rbrace$
3. Also, there could be efficient MOI models for QUBO problems
4. We could better negotiate with the MOI file format system

Cons:

1. The package would be made less lightweight, which is a cool feature to deliver
2. It would also become less platform-agnostic

@pedroripper, @AndradeTiago, @joaquimg and @bernalde, feel free to add your toughts on this discussion!

The ExactSampler searches $2^n$ states but it is interesting to hold only a few. This could be implemented using a Heap.

Instead of implementing recipes using direct type dispatch, create wrappers that, for example, allow for different visualization schemes to be created from the same data.

Instead of doing

using QUBOTools
using Plots
sol = SampleSet(...)

plot(sol)

it should be

using QUBOTools
using Plots
sol = SampleSet(...)

plot(EnergyFrequencyPlot(sol))

write() command doesn't work.

Without any problems QUBOTools can read created model and give information about it. Yet it has problems with writing it.
It doesn't work even with the "problem.json" file mentioned in the markdown.

When retrieving topology / adjacency information from models and devices (#42), return a graph compatible with (Graphs.jl).

#5 was important to launch this project by adding it to the general registry.

Complete support to the BQPJSON format was granted but others are still missing.

As pointed out in #34, both ToQUBO.jl and QUBODrivers.jl will import MathOptInterface.jl and implement a couple methods to integrate MOI with QUBOTools.jl.

function QUBOTools.varlt(x::MOI.VariableIndex, y::MOI.VariableIndex)
    ...
end

function QUBOTools.sense(s::MOI.OptimizationSense)
    ...
end

Currently, both packages contain the same wrapper code.

%%{init: {'theme':'neutral'}}%%
flowchart LR;
    subgraph QUBO ["QUBO.jl"]
        direction LR;
        
        MOI(["MathOptInterface.jl"]);
        
        subgraph TOQUBO["ToQUBO.jl"]
            direction LR;
            TOQUBOWRAPPER["wrapper"];
        end
        
        MOI -..-> TOQUBOWRAPPER;
        
        subgraph QUBODRIVERS["QUBODrivers.jl"]
            direction LR;
            
            QUBODRIVERSWRAPPER["wrapper"];
        end
        
        PBO(["PBO.jl"]);
        QUBOTOOLS(["QUBOTools.jl"]);
        
        MOI -..-> QUBODRIVERSWRAPPER;
        
        QUBOTOOLS -.-> QUBODRIVERS;
        QUBOTOOLS -.-> TOQUBO;
        PBO -.-> QUBOTOOLS;
    end

When both are loaded in the same session, as done by QUBO.jl, the Julia compiler will warn about method redefinition and its impact in incremental compilation. Checking for definitions using hasmethod fails since the wrapped functions provide dispatch options on more abstract types, including Any. The ideal solution would be put the wrapper inside a module that would be imported by both packages. This could be done by creating an extra package or by using Package Extensions, which impose the drawback of requiring Julia 1.9 or greater.

%%{init: {'theme':'neutral'}}%%
flowchart LR;
    subgraph QUBO ["QUBO.jl"]
        direction LR;
        
        MOI(["MathOptInterface.jl"]);
        
        subgraph QUBOTOOLS["QUBOTools.jl"]
            direction LR;
            
            WRAPPER["wrapper"];
        end
        
        PBO(["PBO.jl"]);
        QUBODRIVERS(["QUBODrivers.jl"]);
        TOQUBO(["ToQUBO.jl"]);

        MOI -.-> WRAPPER;

        WRAPPER -.-> QUBODRIVERS;
        WRAPPER -.-> TOQUBO;
        PBO -.-> QUBOTOOLS;
    end

Another option would be to simulate C/C++'s #ifndef behavior using a hook defined by QUBOTools.jl or even environment variables.

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Add plot recipe to display the $Q$ matrix according to the magnitude (and sign maybe?) of its entries.

Example

Rationale

This measurement is useful to determine how far, in terms of state flips, a solution is from another, e.g., the groud state.

Suggestion

function hamming(x::Vector{U}, y::Vector{U}) where {U<:Integer}
    return count(x .!= y)
end

Example

julia> x = [0, 1, 0];

julia> y = [1, 1, 0];

julia> hamming(x, y)
1

We currently let the sampler tell us the time it took during optimization, as in:

function Anneal.sample(annealer::Optimizer{T}) where {T}
    sampler = neal.SimulatedAnnealingSampler()

    t₀ = time()
    records = sampler.sample_qubo(
        annealer.Q;
        num_reads=MOI.get(annealer, MOI.RawOptimizerAttribute("num_reads")),
        num_sweeps=MOI.get(annealer, MOI.RawOptimizerAttribute("num_sweeps")),
    ).record
    samples = [(pyconvert.(Int, s), pyconvert(Int, n), pyconvert(Float64, e + annealer.c)) for (s, e, n) in records]
    t₁ = time()

    δt = t₁ - t₀

    return (samples, δt)
end

Shouldn't we care about the sampling only and measure time automatically from outside of the Anneal.sample call, taking initialization and data formatting into account?

Define an interface for accessing information about a solver, including it's capacity, availability and connectivity.

I am working on adding a new format to QUBOTools.jl - HDF5.
In mentioned format in dataset I would like to have two-dimensional matrix. Model allows only dictionaries for linear and quadratic terms.
Yet, rewriting an array to dictionary takes plenty of time. I would like to skip this step and write it as matrix.
I was thinking about adding reading and writing terms for matrix to every other format, but I don't think it's the best way. Do you have any idea how to do it better?