juliadecisionfocusedlearning / inferopt.jl Goto Github PK

It would be nice to be able to fix the random samples once and for all.
Once solution would be to store the RNG within the Perturbed object: see https://docs.julialang.org/en/v1/stdlib/Random/

We should be able to provide keywords arguments as input of the SPOPlusLoss, in a similar way as for the FenchelYoungLoss. Also needs to be implemented for SSVMLoss.

Let users supply their own

High priority:

• Use https://github.com/JuliaDocs/DocStringExtensions.jl
• Background page for math (optim + ML), focus on discrete functions rather than linear programs
• Guide for choosing the right tool (as in https://scikit-learn.org/stable/tutorial/machine_learning_map/index.html)
• Lots of tutorials (remove GridGraphs from the graph tuto)
• Separate API between specific problems, losses, optim layers and internals
• Specify private API

Low priority:

• Way to test without gradient descent, or to avoid testing the full tensor problem * layers
• Flux or Lux?

At the moment, InferOpt uses ChainRulesCore for rrules, but it would be nice to be compatible with ForwardDiff dual numbers

https://arxiv.org/abs/2205.09589

Hello I have a task to create a graph from the output of the convolutional neural network that then will be used in graph neural network.
I have a cost function that can tell wheather graph was well created.
My main problem is that graph by its nature is discrete hence constructing graph creation algorithm in a way that will enable back propagation is problematic (as you see in my architecture gradients need to pass from graph neural networks to CNN)

Can it be potentially possible to use your package for differentiable graph creation from 3D array?

https://aviatesk.github.io/JET.jl/stable/jetanalysis/#JET.test_package

As of today, Enzyme.jl allows custom rules, written in a different format than ChainRules.jl. It would be nice to test InferOpt.jl with this new autodiff backend

Frank-Wolfe related tests fail due to the linear solver for implicit differentiation not converging

Main suspect: ZIB-IOL/FrankWolfe.jl#387

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!

Currently, most of our code deals with values $y$ or $\theta$ that are typed as AbstractArray{<:Real}. This restriction is not used for dispatch, so it is not essential, and may even prevent the use of other interesting number formats that do not subtype Real. I suggest we remove it

We should add some tests checking that gradients computed by our rrules are correct.
For this, we can use FiniteDifferences.jl or ChainRulesTestUtils.jl.

We should see if we can easily implement generalized imitation losses as described in the paper.

It would be nice to be compatible with Julia's Long Term Support (LTS) version 1.6.
I think the main obstacle at the moment is the use of the destructuring syntax (; a, b) = x, which was introduced in Julia 1.7. Shouldn't be hard to fix, and the test CI needs to be updated too.

It would be interesting to be able to run perturbed maximizers in parallel, especially when nb_samples is high or/and the combinatorial algorithm has a long runtime.

One option would be to use ThreadsX.jl. For this, we need to wait until the following PR is merged: tkf/ThreadsX.jl#195 in order to not have conflict with SetField version.

Quick tests are nicer for test-driven development

According to the paper, θ_perturbed = θ .* exp.(ε .* Z .- ε^2) (here) should be θ_perturbed = θ .* exp.(ε .* Z .- ε^2 / 2) instead

We urgently need a better documentation with

• a better intro to the theory
• examples for all types of loss functions
• examples for using kwargs to pass instances (#56)
• a guide for choosing your layer à la scikit-learn

• https://discourse.julialang.org/t/ann-documenter-1-0/103888#catch-large-html-pages-6
• https://documenter.juliadocs.org/v1.0.0/release-notes/

Reverse rules for PerturbedAdditive and PerturbedMultiplicative take a sum instead of a weighted mean. As a result we've been computing M * J instead of J this whole time

At the moment it's not clear in the documentation which kwargs are given to which pipeline element at which time. Even I'm a bit lost ^^

At the moment, DifferentiableFrankWolfe (see the giom branch) only works when θ is a vector, not a higher-dimensional array.
It should be easy to implement flattening / unflattening to generalize it.

As the title

Currently, InferOpt fully supports predictors of the form $\arg\max_y \theta^\top y$ in combinatorial layers.
It would be interesting to allow the more general form $$\arg\max_y \theta^\top g(y) + h(y)$$
For the moment, a workaround is to make your predictor return $g(y)$ instead of $y$. This way, gradient computation are correct, but loss value computations are not when $h\neq0$ (there is a missing term), therefore the training will work but the loss metric value will be slightly incorrect.

One implementation option would be to enforce returning the objective value as an additional output of the predictor.

https://arxiv.org/abs/2205.15213

I must make it easier for contributors to understand how chain rules are written. This requires:

• basics of autodiff and VJPs
• formulas

https://www.ijcai.org/proceedings/2021/0390.pdf

We have a generic implementation of a PerturbedOracle that also does variance reduction.

Beware however: for arbitrary perturbation distributions, the Fenchel-Young loss must be reworked

We can speed up loading of InferOpt by replacing ThreadsX with built-in threads:

res = ThreadsX.map(f(i) for i in 1:n)

would become

f1 = f(1)
res = Vector{typeof(f1)}(undef, n)
res[1] = f1
@threads for i in 2:n
    res[i] = f(i)
end

Downsides:

• less readable code
• performance hit due to the first element: complexity 1 + (n-1)/t instead of n/t for t threads

Upsides:

• less dependencies, faster loading of InferOpt
• improved type stability?

I think traits are a hassle for users who want a quick and easy implem. If the required methods do not exist for their structures, Julia will throw an error anyway. I suggest we get rid of SimpleTraits and just use unconstrained type parameters for regularization and imitation losses.

Is there a downside to this?

Since I figured out how to use JET.report_package properly, it throws a few errors for interface functions that are not implemented. For now the test is skipped, but we need to reactivate it.

Underline best coding practices

Duplicate of #62

Julia 1.8 is no longer a pre-release

https://github.com/axelparmentier/InferOpt.jl/blob/b9f4f69f1214338c54399fe4e00fa45e10b65e75/src/perturbed/multiplicative.jl#L55

It would be nice to put alternatives in the docs:

Julia:

• DiffOpt.jl
• ImplicitDifferentiation.jl
• StochasticAD.jl

Python:

• JAXopt
• PyEPO
• storchastic

In this page of the documentation, $f$ if defined as the $\max$, but should be an $\arg\max$, because:

• only the $\arg\max$ is piecewise constant,
• the maximizer argument of InferOpt layers should return the $\arg\max$.

Show an example in the docs that uses eg. LBFGS instead of SGD

https://arxiv.org/abs/2006.08063

At the moment this predictor only supports the forward pass, but we need a backward pass too

See #37 (comment)