Benchmark uses DataFrames

[abelsiqueira]

• solve_problems returns a DataFrame
• bmark_solvers return a dictionary of solver => DataFrame
• profile_solvers receives a dictionary of solver => DataFrame

Example on examples/benchmark.jl.

[coveralls]

Coverage increased (+0.3%) to 70.365% when pulling 45a08a4a544d2cce3ba40acaa6e0b47cc4478157 on abelsiqueira:dataframes into be0a6198773d8529f4a4d7485c10eed5efbd2f85 on JuliaSmoothOptimizers:master.

[coveralls]

Coverage increased (+0.3%) to 70.365% when pulling 66dbc6a62951ad70f5d3d3410b09f19a6e702480 on abelsiqueira:dataframes into be0a6198773d8529f4a4d7485c10eed5efbd2f85 on JuliaSmoothOptimizers:master.

[dpo]

Do we still need the AbstractExecutionStats stuff, now that we are using DataFrames?

[dpo]

This works for me, although there's a lot of output when I include examples/benchmark.jl due to the default logging. We can resolve that in another PR though.

[abelsiqueira]

Do we still need the AbstractExecutionStats stuff, now that we are using DataFrames?

Do you mean (1) remove all *ExecutionStats; or (2) We should have only oneExecutionStats` and no abstract anymore.

1- I think it's good to have an ExecutionStats because the solver outputs more than is put in the DataFrame, and this way the output can be relied upon; 2- Having one ExecutionStats seems better, I don't think we'll have use for more than one.

On the amount of logging, I also find annoying, but it seems better to leave for another PR.

[dpo]

1- I think it's good to have an ExecutionStats because the solver outputs more than is put in the DataFrame, and this way the output can be relied upon;

Do you mean the solution, the multipliers, etc.?

[abelsiqueira]

Yes

[dpo]

Thank you!