I want to solve a MIP in Cplex (with IloCplex for C++) using only the branch & bound feature (i.e. without all the enhancements that speed up the solving like probing, running heuristics at each node, adding cuts etc.). The idea is to be able to test the impact of my own cuts without the results being blurred by the cuts and the various improvements of Cplex on the branch & bound.
I have already disabled many methods but the root relaxation is still better than the objective value I get when I run my MIP with all integrity constraints relaxed meaning that Cplex is still improving the branch & bound by any means.
I set the following parameters:
cplex.setParam(IloCplex::Param::Preprocessing::Presolve, IloFalse);
cplex.setParam(IloCplex::Param::MIP::Strategy::Search, IloCplex::Traditional);
cplex.setParam(IloCplex::Param::MIP::Strategy::Probe, -1);
cplex.setParam(IloCplex::Param::MIP::Strategy::HeuristicFreq, -1);
cplex.setParam(IloCplex::Param::Preprocessing::BoundStrength, 0);
cplex.setParam(IloCplex::Param::Preprocessing::CoeffReduce, 0);
cplex.setParam(IloCplex::Param::MIP::Limits::CutPasses, -1);
cplex.setParam(IloCplex::Param::MIP::Strategy::FPHeur, -1);
and I deactivate all cuts by:
cplex.setParam(IloCplex::Param::MIP::Cuts::BQP, -1);
cplex.setParam(IloCplex::Param::MIP::Cuts::Cliques, -1);
cplex.setParam(IloCplex::Param::MIP::Cuts::Covers, -1);
cplex.setParam(IloCplex::Param::MIP::Cuts::Disjunctive, -1);
cplex.setParam(IloCplex::Param::MIP::Cuts::FlowCovers, -1);
cplex.setParam(IloCplex::Param::MIP::Cuts::Gomory, -1);
cplex.setParam(IloCplex::Param::MIP::Cuts::GUBCovers, -1);
cplex.setParam(IloCplex::Param::MIP::Cuts::Implied, -1);
cplex.setParam(IloCplex::Param::MIP::Cuts::LiftProj, -1);
cplex.setParam(IloCplex::Param::MIP::Cuts::LocalImplied, -1);
cplex.setParam(IloCplex::Param::MIP::Cuts::MCFCut, -1);
cplex.setParam(IloCplex::Param::MIP::Cuts::MIRCut, -1);
cplex.setParam(IloCplex::Param::MIP::Cuts::PathCut, -1);
cplex.setParam(IloCplex::Param::MIP::Cuts::RLT, -1);
cplex.setParam(IloCplex::Param::MIP::Cuts::ZeroHalfCut, -1);
What am I missing?
As point out by Erwin, it is not possible to disable all Cplex enhancements in order to obtain a "vanilla" branch & bound. A more detailed explanation is available here
Related
I am making a Topdown 2d game in SDL2 with C++. It has a tiled map of each tile being 32x32 px in dimensions.
I have used the A* search algorithm so the enemy can find the player in the map. Currently the path is being correctly traced and after performing A*, it returns a stack of SDL_Point which are just x and y values on map. But I can't figure out how to make the enemy follow this path slowly overtime rather than just hopping on x and y points in the stack.
Below is the move function, the move function is constantly called in the main game loop:
void Gunner::move(std::array<Tile*, MAP_LENGTH>& map, double deltaTime) {
// calculate A* path from current pos to player pos
Astar astar(target, this);
stack<SDL_Point> path = astar.astar(map);
if (path.size() != 0) {
SDL_SetRenderDrawColor(renderer, 0, 0, 0, 255);
int xP = path.top().x;
int yP = path.top().y;
SDL_Rect r = { xP, yP, 32, 32 };
/*
Make the enemy follow path
*/
// debugging purpose
SDL_RenderFillRect(renderer, &r);
path.pop();
}
}
This is the path generated where e is enemy and p is player.
The keyword you're looking for is "path smoothing". There are lots of ways to implement this, which are too complex for a single Stackoverflow answer:
I believe the most popular option is string pulling, which, as the name suggests, is like pulling on your path as though it were a string to make it taut.
You could also use the grid points to generate a spline.
You could use a steering algorithm to have your unit approximate the path.
Another option that has become more popular in recent years is to use an "any-angle" path-finding algorithm, which generates smoothed paths from the get-go. Theta* is the most popular one, to my knowledge.
All of these options produce near-optimal results. If for some reason you need optimal results, this paper was released a few years ago. I don't know much about it, but I assume it's slower than the other options.
Here is a github page with a lot more options for path smoothing.
I try to compare images using method similar to Features2D + Homography to find a known object but replace findHomography() by self-writed findAffine() function.
I use Ceres Solver to obtain optimal affine matrix considering outliers.
double translation[] = {0, 0};
double angle = 0;
double scaleFactor = 1;
ceres::Problem problem;
for (size_t i = 0; i < points1.size(); ++i) {
problem.AddResidualBlock(
new ceres::AutoDiffCostFunction<AffineResidual, 1, 2, 1, 1>(
new AffineResidual(Eigen::Vector2d(points1[i].x, points1[i].y),
Eigen::Vector2d(points2[i].x, points2[i].y))),
new ceres::HuberLoss(1.0),
translation,
&angle,
&scaleFactor);
}
ceres::Solver::Options options;
options.linear_solver_type = ceres::DENSE_QR;
options.minimizer_progress_to_stdout = true;
ceres::Solver::Summary summary;
Solve(options, &problem, &summary);
Ceres solver provide LossFunction:
Loss functions reduce the influence of residual blocks with high residuals, usually the ones corresponding to outliers.
Of course, I can transform keypoints coordinates from first image by obtained matrix, compare with second and get deviation. But ceres solver already done it inside during work.
How I can retrieve it? Did not find it in the documentation.
I had the similar problem. After looking into Ceres library sources (particularly into ResidualBlock::Evaluate() method) I had a conclusion that there is no explicit "outlier" status for residual block. It seems that the loss function just affects resulting cost value for a block (which is exactly described by the phrase from documentation you have quoted - "Loss functions reduce the influence of residual blocks with high residuals"). So the answer is that you cannot retrieve outliers from Ceres, there is no such feature.
Workaround might be calculating residuals for your data with the solved result, and apply loss function to them. The comment from LossFunction::Evaluate() might help:
// For a residual vector with squared 2-norm 'sq_norm', this method
// is required to fill in the value and derivatives of the loss
// function (rho in this example):
//
// out[0] = rho(sq_norm),
// out[1] = rho'(sq_norm),
// out[2] = rho''(sq_norm),
//
// Here the convention is that the contribution of a term to the
// cost function is given by 1/2 rho(s), where
//
// s = ||residuals||^2.
//
// Calling the method with a negative value of 's' is an error and
// the implementations are not required to handle that case.
//
// Most sane choices of rho() satisfy:
//
// rho(0) = 0,
// rho'(0) = 1,
// rho'(s) < 1 in outlier region,
// rho''(s) < 0 in outlier region,
//
// so that they mimic the least squares cost for small residuals.
virtual void Evaluate(double sq_norm, double out[3]) const = 0;
I have the following implementation of a alpha beta minimax for an othello (reversi) game. I've fixed a few of it's problems from this thread. This time I'd like to improve the performance of this function. It's taking a very long time with MAX_DEPTH = 8. What can be done to speed up the performance, while keeping the AI somewhat decent?
mm_out minimax(Grid& G, int alpha, int beta, Action& A, uint pn, uint depth, bool stage) {
if (G.check_terminal_state() || depth == MAX_DEPTH) {
return mm_out(A, G.get_utility(pn));
}
// add end game score total here
set<Action> succ_temp = G.get_successors(pn);
for (Action a : succ_temp) {
Grid gt(G);
a.evaluate(gt);
}
set<Action, action_greater> successors(succ_temp.begin(), succ_temp.end());
// if no successor, that player passes
if (successors.size()) {
for (auto a = successors.begin(); a != successors.end(); ++a) {
Grid gt(G);
gt.do_move(pn, a->get_x(), a->get_y(), !PRINT_ERR);
Action at = *a;
mm_out mt = minimax(gt, alpha, beta, at, pn ^ 1, depth + 1, !stage);
int temp = mt.val;
// A = mt.best_move;
if (stage == MINIMAX_MAX) {
if (alpha < temp) {
alpha = temp;
A = *a;
}
if (alpha >= beta) {
return mm_out(A, beta);
}
}
else {
if (beta > temp) {
beta = temp;
A = *a;
}
if (alpha >= beta) {
return mm_out(A, alpha);
}
}
}
return mm_out(A, (stage == MINIMAX_MAX) ? alpha : beta);
}
else {
return mm_out(A, (stage == MINIMAX_MAX) ? (std::numeric_limits<int>::max() - 1) : (std::numeric_limits<int>::min() + 1));
}
}
Utility function:
int Grid::get_utility(uint pnum) const {
if (pnum)
return wcount - bcount;
return bcount - wcount;
}
There are several ways to speed up the performance of your search function. If you implement these techniques properly, they will cause very little harm to the accuracy of the algorithm while pruning many nodes.
The first technique that you can implement are transposition table. Transposition tables store in a hashtable all previously visited nodes in your game search tree. Most game states, especially in a deep search, can be reaches through various transpositions, or orders of moves that resurt in the same final state. By storing previously searched game states, if you find a state already searched, you can use the data stored in the tables and stop deepening the search at that node. The standard technique to store game states in a hashtable is called Zobrist Hashing. Detailed information on the implementation of transposition tables is available on the web.
The second thing your program should include is move ordering.This essentially means to examine moves not in the order you generate them, but in the order that seems most likely to produce an alpha beta cutoff (ie good moves first). Obviously you can't know which moves are best, but most moves can be ordered using a naive technique. For example, in Othello a move that is in a corner or edge should be examined first. Ordering moves should lead to more cutoffs and an increase in search speed. This poses zero loss to accuracy.
You can also add opening books. Usually the opening moves take the longest to search, as the board is full of more possibilities.An opening book is a database that stores every possible move that can be made in the first few turns, and the best response to it., In Othello, with a low branching factor, this will be especially helpful in the opening game
Probcut. Im not going to go into more detail here as this is a more advanced technique. However it has had good results with othello, so I figured I'd post this link.https://chessprogramming.wikispaces.com/ProbCut
I'm not sure if there is an actual performance increase to achieve, or if my computer is just old and slow, but I'll ask anyway.
So I've tried making a program to plot the Mandelbrot set using the cairo library.
The loop that draws the pixels looks as follows:
vector<point_t*>::iterator it;
for(unsigned int i = 0; i < iterations; i++){
it = points->begin();
//cout << points->size() << endl;
double r,g,b;
r = (double)i+1 / (double)iterations;
g = 0;
b = 0;
while(it != points->end()){
point_t *p = *it;
p->Z = (p->Z * p->Z) + p->C;
if(abs(p->Z) > 2.0){
cairo_set_source_rgba(cr, r, g, b, 1);
cairo_rectangle (cr, p->x, p->y, 1, 1);
cairo_fill (cr);
it = points->erase(it);
} else {
it++;
}
}
}
The idea is to color all points that just escaped the set, and then remove them from list to avoid evaluating them again.
It does render the set correctly, but it seems that the rendering takes a lot longer than needed.
Can someone spot any performance issues with the loop? or is it as good as it gets?
Thanks in advance :)
SOLUTION
Very nice answers, thanks :) - I ended up with a kind of hybrid of the answers. Thinking of what was suggested, i realized that calculating each point, putting them in a vector and then extract them was a huge waste CPU time and memory. So instead, the program now just calculate the Z value of each point witout even using the point_t or vector. It now runs A LOT faster!
Edit: I think the suggestion in the answer of kuroi neko is also a very good idea if you do not care about "incremental" computation, but have a fixed number of iterations.
You should use vector<point_t> instead of vector<point_t*>.
A vector<point_t*> is a list of pointers to point_t. Each point is stored at some random location in the memory. If you iterate over the points, the pattern in which memory is accessed looks completely random. You will get a lot of cache misses.
On the opposite vector<point_t> uses continuous memory to store the points. Thus the next point is stored directly after the current point. This allows efficient caching.
You should not call erase(it); in your inner loop.
Each call to erase has to move all elements after the one you remove. This has O(n) runtime. For example, you could add a flag to point_t to indicate that it should not be processed any longer. It may be even faster to remove all the "inactive" points after each iteration.
It is probably not a good idea to draw individual pixels using cairo_rectangle. I would suggest you create an image and store the color for each pixel. Then draw the whole image with one draw call.
Your code could look like this:
for(unsigned int i = 0; i < iterations; i++){
double r,g,b;
r = (double)i+1 / (double)iterations;
g = 0;
b = 0;
for(vector<point_t>::iterator it=points->begin(); it!=points->end(); ++it) {
point_t& p = *it;
if(!p.active) {
continue;
}
p.Z = (p.Z * p.Z) + p.C;
if(abs(p.Z) > 2.0) {
cairo_set_source_rgba(cr, r, g, b, 1);
cairo_rectangle (cr, p.x, p.y, 1, 1);
cairo_fill (cr);
p.active = false;
}
}
// perhaps remove all points where p.active = false
}
If you can not change point_t, you can use an additional vector<char> to store if a point has become "inactive".
The Zn divergence computation is what makes the algorithm slow (depending on the area you're working on, of course). In comparison, pixel drawing is mere background noise.
Your loop is flawed because it makes the Zn computation slow.
The way to go is to compute divergence for each point in a tight, optimized loop, and then take care of the display.
Besides, it's useless and wasteful to store Z permanently.
You just need C as an input and the number of iterations as an output.
Assuming your points array only holds C values (basically you don't need all this vector crap, but it won't hurt performances either), you could do something like that :
for(vector<point_t>::iterator it=points->begin(); it!=points->end(); ++it)
{
point_t Z = 0;
point_t C = *it;
for(unsigned int i = 0; i < iterations; i++) // <-- this is the CPU burner
{
Z = Z * Z + C;
if(abs(Z) > 2.0) break;
}
cairo_set_source_rgba(cr, (double)i+1 / (double)iterations, g, b, 1);
cairo_rectangle (cr, p->x, p->y, 1, 1);
cairo_fill (cr);
}
Try to run this with and without the cairo thing and you should see no noticeable difference in execution time (unless you're looking at an empty spot of the set).
Now if you want to go faster, try to break down the Z = Z * Z + C computation in real and imaginary parts and optimize it. You could even use mmx or whatever to do parallel computations.
And of course the way to go to gain another significant speed factor is to parallelize your algorithm over the available CPU cores (i.e. split your display area is subsets and have different worker threads compute these parts in parallel).
This is not as obvious at it might seem, though, since each sub-picture will have a different computation time (black areas are very slow to compute while white areas are computed almost instantly).
One way to do it is to split the area is a large number of rectangles, and have all worker threads pick a random rectangle from a common pool until all rectangles have been processed.
This simple load balancing scheme that makes sure no CPU core will be left idle while its buddies are busy on other parts of the display.
The first step to optimizing performance is to find out what is slow. Your code mixes three tasks- iterating to calculate whether a point escapes, manipulating a vector of points to test, and plotting the point.
Separate these three operations and measure their contribution. You can optimise the escape calculation by parallelising it using simd operations. You can optimise the vector operations by not erasing from the vector if you want to remove it but adding it to another vector if you want to keep it ( since erase is O(N) and addition O(1) ) and improve locality by having a vector of points rather than pointers to points, and if the plotting is slow then use an off-screen bitmap and set points by manipulating the backing memory rather than using cairo functions.
(I was going to post this but #Werner Henze already made the same point in a comment, hence community wiki)
I'm having a problem with color picking and antialiasing in OpenGL. When AA is activated results from glReadPixels are obviously wrong on object edges and object intersections. For example:
I render a box #28 (RGBA: 28, 0, 0, 0) near a box #32 (RGBA: 32, 0, 0, 0). With AA, I can get a wrong ReadPixel value (e.g. 30) where the cube and triangle overlap, or value of 14 on boxes edge, due to the AA algorithm.
I have ~4000 thousand objects I need to be able to pick (it's a jigsaw puzzle game). It is vital to be able to select objects by shape.
I've tried to disable AA with glDisable(GL_MULTISAMPLE) but it does not works with certain AA modes (I read it depends on AA implementation - SS, MS, CS ..)
So, how do I pick an underlying object?
A way do temporary disable AA?
Using a different buffer or even rendering context?
Any other suggestion?
Why not use an FBO as your pick buffer?
I use this hack: pick not just one pixel, but all the 3x3=9 pixels around the picking point. If they are all same, we are safe. Otherwise, it must be on edge and we can skip that.
int renderer::pick_(int x, int y)
{
static_assert(__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__,
"only works on little-endian architecture");
static_assert(sizeof(int) == 4,
"only works on architecture that has int size of 4");
// sort of edge detection. selection only happens at non-edge
// since the edge may cause anti-aliasing glitch
int ids[3*3];
glReadPixels(x-1, y-1, 3, 3, GL_RGBA, GL_UNSIGNED_BYTE, ids);
for (auto& id: ids) id &= 0x00FFFFFF; // mask out alpha
if (ids[0] == 0x00FFFFFF) return -1; // pure white for background
// prevent anti-aliasing glitch
bool same = true;
for (auto id: ids) same = (same && id == ids[0]);
if (same) return ids[0];
return -2; // edge
}