Choosing delta ratio automatically, discretization->disc refactoring, and some minor fixes

[jac0320]

Major changes:

• Refactoring "discretization" to "disc"

Algorithm changes and Function additions:

• Added disc_ratio branching scheme into the main algorithm
• Modularized nonlinear term evaluators as individual functions in operators.jl

Error schemes and default changes:

Test changes:

• New tests added associated with
• Re-organized test instances into a folder

-------------- OLD Comments ---------------- This PR is about choosing Delta ratio automatically using a heuristic idea discussed so far. This PR branch off #72 .

[codecov[bot]]

Codecov Report

Merging #74 into master will increase coverage by 0.49%. The diff coverage is 87.23%.

@@            Coverage Diff            @@
##           master     #74      +/-   ##
=========================================
+ Coverage      79%   79.5%   +0.49%     
=========================================
  Files          28      28              
  Lines        5898    5988      +90     
=========================================
+ Hits         4660    4761     +101     
+ Misses       1238    1227      -11

Impacted Files	Coverage Δ
test/examples/exprstest.jl	8.66% <ø> (ø)	:arrow_up:
test/examples/multi.jl	57% <ø> (+18.69%)	:arrow_up:
test/expression.jl	100% <ø> (ø)	:arrow_up:
test/examples/castro2m2.jl	99.82% <ø> (ø)	:arrow_up:
test/examples/nlp.jl	89.28% <ø> (ø)	:arrow_up:
test/examples/blend029.jl	99.57% <ø> (ø)	:arrow_up:
test/examples/convex.jl	0% <ø> (ø)	:arrow_up:
src/presolve.jl	88.63% <100%> (ø)	:arrow_up:
src/multi.jl	74.77% <100%> (ø)	:arrow_up:
test/algorithm.jl	100% <100%> (ø)	:arrow_up:
... and 10 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 9ff7bf1...576c583. Read the comment docs.

[ccoffrin]

Just as a general suggestion, it can be preferable to break core functionalities into different branches with separate pull requests. For example, in this PR you are doing a feature add and also some bug fixes. The reviewers need to accept all or nothing. Having a separate PR for each functionality lets the PR reviewers more flexibility in which parts to merge immediately and which to have discussions on.

[harshangrjn]

Agreed with @ccoffrin! Also my suggestion would be to avoid explaining the algorithmic details in the PR/Issues as we all have been discussing the ideas together and are well aware. Its also important from the paper point of view since we haven't published any of these yet.

[jac0320]

@ccoffrin @harshangrjn Thanks for the suggestions. I have reverted the commit to focus on purely the algorithm. In the same time, I created a new PR #75 for strengthening the linear lifting functionalities. Descriptions of the algorithm details are removed as well.