roboptim / roboptim-shared-tests Goto Github PK

View Code? Open in Web Editor NEW

1.0 1.0 8.0 831 KB

RobOptim Shared Tests (to be used as a Git submodule)

C++ 97.18% CMake 2.82%

roboptim-shared-tests's People

Contributors

Stargazers

Watchers

Forkers

bchretien kayusawa stanislas-brossette francois-keith aescande etrigger stjordanis

roboptim-shared-tests's Issues

Add tests that show the influence of sparse matrices

For now, the tests available are too "small" to really demonstrate the influence of the sparsity of the Jacobian matrix for solvers that support it. We need larger sparse problems to really compare dense and sparse implementations.

What we could do at first is create a RobOptim filter that "duplicates" or "copy-pastes" a problem to artificially increase its size:

Problem:              --->     Enlarged problem:
  cost: f(x0,x1)                  cost: f(x0,x1) + f(x2,x3) + f(x4,x5) + ...
  constraints:                    constraints:
    g0(x0,x1)                       g0_0(x0,x1), g0_1(x2,x3), g0_2(x4,x5), ...
    g1(x0,x1)                       g1_0(x0,x1), g1_1(x2,x3), g1_2(x4,x5), ...

The solver would be solving several times the same problem, with a very sparse structure. Also, if we know the optimal solution of the problem, we also know the optimal solution of the enlarged problem.

Having actual problems would of course be better, but this trick may be sufficient for now.

Workload for Travis CI

Now that we have roughly 120 tests if compiled in dense + sparse, I'm afraid that we are reaching the limits set in Travis CI, cf. the last build log for the Ipopt plugin:

[ 90%] Building CXX object tests/CMakeFiles/problem_66-sparse.dir/shared-tests/schittkowski/problem_66.cc.o
cd /tmp/_travis/build/tests && /usr/bin/g++   -DHAVE_CSTDDEF -DHAVE_STDDEF_H -DBOOST_TEST_DYN_LINK -DBOOST_TEST_MAIN --coverage -Werror  -pedantic -Wno-long-long -Wall -Wextra -Wcast-align -Wcast-qual -Wformat -Wwrite-strings -Wconversion -fvisibility=hidden -I/tmp/_travis/build -I/tmp/_travis/build/include -I/home/travis/build/roboptim/roboptim-core-plugin-ipopt/include -I/home/travis/build/roboptim/roboptim-core-plugin-ipopt/tests/shared-tests -isystem /tmp/_travis/install/include -isystem /tmp/_travis/install/include/eigen3    -DSOLVER_NAME='"ipopt-sparse"' -DPLUGIN_PATH='"/tmp/_travis/build/src"' -DFUNCTION_TYPE=::roboptim::EigenMatrixSparse -DCOST_FUNCTION_TYPE=::roboptim::GenericDifferentiableFunction -DCONSTRAINT_TYPE_1=::roboptim::GenericLinearFunction -DCONSTRAINT_TYPE_2=::roboptim::GenericDifferentiableFunction -DTESTS_DATA_DIR='"/home/travis/build/roboptim/roboptim-core-plugin-ipopt/tests"' -DLOG_FILENAME='"problem_66-sparse.log"'  -DROBOPTIM_DO_NOT_CHECK_ALLOCATION -DEIGEN_RUNTIME_NO_MALLOC -I/tmp/_travis/install/include -I/tmp/_travis/install/include/eigen3 -o CMakeFiles/problem_66-sparse.dir/shared-tests/schittkowski/problem_66.cc.o -c /home/travis/build/roboptim/roboptim-core-plugin-ipopt/tests/shared-tests/schittkowski/problem_66.cc


I'm sorry but your test run exceeded 50.0 minutes. 

One possible solution is to split up your test run.

We may need to select a subset of the tests to remain within the bounds, until caching becomes available (e.g. caching Eigen 3.2 and roboptim-core).

Fix tests when multiple optimal solutions exist

cc @thomas-moulard

While checking problem_9 with the Ipopt plugin, I realized that Ipopt returns:

Result: 
  Size (input, output): 2, 1
  X: [2](-39,-52)
  Value: [1](-0.5)
  Constraints values: [1](0)
  Lambda: [1](-0.0327249)

Yet the test fails because it expects:

// minimal local are x_k for k = 0, +/-1, +/-2, etc.
const double ExpectedResult:: k = 0;
const double ExpectedResult::x[] = {12 * k - 3, 16 * k - 4};
const double ExpectedResult::fx = -.5;

i.e. Ipopt converges to the solution for k = -3, but it is tested against k = 0.

I guess we could compare fx and test the constraints, and if fx is wrong or the constraints are violated, we then compare x to help the user investigate the issue.

Regroup tests by optimization problem "properties"

Different solvers can handle different kinds of problems: constrained or unconstrained, support for equality constraints etc. I guess we could find a way to help filter relevant problems for a given solver, rather than trying to launch the whole Schittkowski test suite or expect the developer to go through each problem to find the ones that could work.

I guess that information could be processed by tests.cmake or Schittkowski's CMakeLists.txt to only use relevant problems.

roboptim / roboptim-shared-tests Goto Github PK

roboptim-shared-tests's People

Contributors

Stargazers

Watchers

Forkers

roboptim-shared-tests's Issues

Add tests that show the influence of sparse matrices

Workload for Travis CI

Fix tests when multiple optimal solutions exist

Regroup tests by optimization problem "properties"

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent