Transport Plan with Negative Value

[davibarreira]

I was updating one of the examples, and I realized that the transport plan was coming out with negative values.
I don't remember if we already discussed the issue, or if it's somehow wrongfully passing our tests. Here is the code I'm running:

using OptimalTransport
using Distances
using Plots
using Tulip

using LinearAlgebra
using Random

Random.seed!(1234)
M = 200
μ = fill(1 / M, M)
μsupport = rand(M,2)

N = 250
ν = fill(1 / N, N)
νsupport = rand(N,2);
C = pairwise(SqEuclidean(), μsupport', νsupport'; dims=2);
γ = emd(μ, ν, C, Tulip.Optimizer());

Of course, the problem is just the numerical approximation of the floats, when the values should actually be zero. But I wonder if we should enforce it to round up to zero or something.

[devmotion]

We already specify that the solution has to be non-negative:

ExactOptimalTransport.jl/src/exact.jl

Line 74 in 1b1d3da

MOI.add_constraint(model, MOI.SingleVariable(xi), MOI.GreaterThan(zero_T))

So it's not our fault but you just observe the behaviour of Tulip (which apparently accepts if constraints are satisfied approximately). Some other LP solver might return non-negative values with these constraints... My suggestion would be to ask in Tulip if this behaviour is expected or should be considered a bug. But I think we should not change anything in our implementation for now.

[davibarreira]

Great, thanks! Perhaps we should write something in our docs?