warm start

[andreadelprete]

@gabrielebndn I just saw that there is a version of Eiquadprog with warm-start capabilities and other juicy features here. It would be great to integrate their work into our version of the solver. This is a (partial) list of what they did on top of the version of eiquadprog I started from:

• Rewitre and optimize QuadProg++ to be fully based on Eigen. This leads to a more readable code, and significant speed up to compute step directons and add/delete constraints.
• Generalize QuadProg++ API to allow passing the inital guess, to export the resulting active-set, to pass a list of inequalities to satisfy first, and options and schedule the inequalities.
• Add various inequality scheduling heuristics:
  • WorstFirst : the default for QuadProg++
  • SlidingWindows: treat the worst of the current subset, and shift/grow the subset (the default for rational_quadprog)
  • WorstSetFirst: treat all the N worst before checking for the others
• Add new options for rational_quadprog:
  _scheduling_mode = args.get_string("scheduling-mode","SlidingWindows"); -> can also be "WorstFirt" or "WorstSetFirst"
  _scheduling_chunk_size = args.get_int("scheduling-chunk-size",-1); -> the default is usually very good
  _scheduling_grow_factor = args.get_float("scheduling-grow-factor",-1); -> not recommended
  _export_qp = args.is_defined("export-qp"); -> export QP problem to files for testing with other solvers
  _delta = args.get_float("delta", 1);
  _add_ls_energy = args.is_defined("add-ls-energy"); -> recommended
• Update rational_quadprog_parallel to reflect API changes

[gabrielebndn]

@andreadelprete, if quadprog++ is a viable implementation, endorsed by Gael Guennebaud himself, why not using this version directly? What are the advantages of using a version of our own? I would trust that Guennebaud's version is pretty good.
@jmirabel, @nim65s, what do you think?

[jcarpent]

I think this is just historical and if Andrea has known the package of Gael before, we would have used it.
But @andreadelprete implemented other features inside it.

[jmirabel]

Well @andreadelprete did use a version that was written by Gael and modified later by Benjamin. I think he tried many version of quadprog. But he is the one who can reply to that.

For some time, I hesitated to ask on eigen's mailing list whether adding quadprog as an unsupported module would make sense. I did not because the author was Gael and he did not do it. But that is not a good enough reason.

[jcarpent]

For some time, I hesitated to ask on eigen's mailing list whether adding quadprog as an unsupported module would make sense. I did not because the author was Gael and he did not do it. But that is not a good enough reason.

But it won't change for the current releases of Eigen.

[andreadelprete]

@andreadelprete, if quadprog++ is a viable implementation, endorsed by Gael Guennebaud himself, why not using this version directly? What are the advantages of using a version of our own?

The main improvement of my version was to ensure to dynamic memory allocation while solving the problem. If Gael's new version has the same feature, probably we should use his one. However, before switching, I'd suggest to compare them empirically to make sure computation times are (at least) as good.