C interface

[spoorendonk]

This is a suggestion for a minimum C interface for using Dip. This allows easy integration with other languages etc.

Then the user can do:

int main(int argc, char *argv[])
{
        struct UtilParameters *utilParam = Dip_UtilParameters_new();
        Dip_UtilParameters_ScanCmdLineArgs(utilParam, argc, argv);
        struct DecompApp *app = Dip_DecompApp_new(utilParam);

        int numCols = 100;
        int numRows = 100;

        // objective
        double objective[numCols]; 
        // ... set objective
        Dip_DecompApp_setModelObjective(app, objective, numCols);

        // models
        DecompConstraintSet *modelCore = Dip_DecompConstraintSet_new();
        Dip_DecompConstraintSet_init(modelCore, numCols, numRows);

        // put rows in model
        // Dip_DecompConstraintSet_appendRow(modelRelaxed, size, inds, elems, lb, ub, "rowName");

        Dip_DecompApp_setModelCore(app, modelCore, "modelCore");

        // same for relaxed problems
        // Dip_DecompApp_setModelRelax(app, modelRelaxed, string, k);

        DecompAlgo* algo = Dip_DecompAlgoPC_new(app, utilParam);
        Dip_DecompApp_setCallbackSolveRelaxed(app, callback_SolvedRelaxed);

        AlpsDecompModel *alps = Dip_AlpsDecompModel_new(utilParam, algo);
        int status = Dip_AlpsDecompModel_solve(alps);
}

This was the easy option using the current classes and way of setting stuff up. My idea was just to expand the interface when needed but keeping it a very thin wrapper.

Some thoughts:

1. Should Dip maybe implement OsiSolverInterface? And should that be the one that is wrapped? This would allow a common interface for adding vars and rows. It should be extended to specify what vars/rows goto what blocks when using PC algo.
2. I named the files Dip_. I am thinking that the other files should also be renamed from Decomp to Dip at some point? But perhaps Decomp is also better for the C interface at the time?

[tkralphs]

OK, I see that you do have methods here for setting callbacks C-style. And yes, both of the points you mentioned here have long been on my TODO list!

• Everything internally should be renamed from Decomp to Dip, just never got to it. The name of the project was DECOMP in the beginning, but that name was too generic so when we went on COIN-OR, we renamed it without renaming the internal symbols.
• I have long wanted Dip to implement OsiSolverInterface and this would certainly make lots of things easier. The former is pretty mechanical, but will break all backwards compatibility so we should be careful. The latter might not be without difficulty, although not to bad in principle. I would be very happy to try to make these things happen as part of the effort to create a C interface.

[spoorendonk]

The callback sneaked in there. I was playing around with the implementation. It should not be part of this PR but added when we have resolve #109

Given my current time and effort I would be happy if we could agree on this version of the c interface for now. It can be expanded when the OsiSolverInterface is implemented, but for now I am little reluctant open up that issue - I think it should be an issue by itself?

For renaming Decomp -> Dip prefix should also be done elsewhere. For now I could rename these files to Decomp to be consistent?

I am unable to figure out why the AppVeyor build fails...

[tkralphs]

OK, sure, I don't want to hold you up with a long discussion of details. I'm happy if you move ahead with this and we can put off the OsiSolverInterface implementation until later. Perhaps we can open an issue to keep track of it. And sure, naming with Decomp for now makes sense. We can change Decomp to Dip en masse at some later point, probably when moving to a new stable so that it doesn't matter if things break.

[spoorendonk]

I renamed the files. I will add an example later

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}