Originally posted by: SystemAdmin

I read the manual about getRay(), it saying

public void getRay(IloNumArray vals,
                   IloNumVarArray vars) const

"This method returns an unbounded direction (also known as a ray) corresponding to the present basis for an LP that has been determined to be an unbounded problem. CPLEX puts the the variables of the extracted model into the array vars and it puts the corresponding values of the unbounded direction into the array vals."

But I do not know when CPLEX put the varialbes into the array vars what kind of order it used. I want to figure out how to map the varilabes in array vars to the varaibles in array which I defined by myself in my model.

Thus, I used it as follows, is it correct? (Since recently I found some problem in my program, so I am thinking about probably this part is not correct)

//defind varialbes and constraints, and build the model
//solve the model (disabled presolve and used primal rootalg)
//then try to get ray...
 
IloInt num_ray;
IloNumVarArray vars(env);       
IloNumArray vals(env);
 
cplex.getRay(vals, vars);
num_ray = vals.getSize();
 
for(j=0; j<m; j++)
{
   for(i=0; i<num_ray; i++)
   {
        if(vars[i].getImpl()==one[j].getImpl())  //one is the arrary of variables defined in my model 
        {
            one_val[j] = vals[i];   //one_val is the array of corresponding values 
            break;
        }
        else;
   }
}

#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

That looks correct as long as you initialize one_val to all-zero.
To be safe/sure I would just expand the code to clear all values for which there are no non-zeros in the ray:

//defind varialbes and constraints, and build the model
//solve the model (disabled presolve and used primal rootalg)
//then try to get ray...
 
IloInt num_ray;
IloNumVarArray vars(env);       
IloNumArray vals(env);
 
cplex.getRay(vals, vars);
num_ray = vals.getSize();
 
for(j=0; j<m; j++)
{
   for(i=0; i<num_ray; i++)
   {
        if(vars[i].getImpl()==one[j].getImpl())  //one is the arrary of variables defined in my model 
        {
            one_val[j] = vals[i];   //one_val is the array of corresponding values 
            break;
        }
        else;
   }
   // THIS IS THE NEW CODE
   if (i == num_ray) {
        // variable not in vars => zero coefficient in ray.
        one_val[j] = 0;  // <- THIS IS THE NEW CODE
   }
}

#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

I think it would be a bit easier (and slightly faster) if, at the time you built your model, you also created a map with IloNumVar as the key type and int as the value type, mapping one[j] to j. (I've done this in Java but not C++, so I'm not positive, but I think you want to map the actual variables and not their implementations.) Then you can just look up vars[k] in the map and get the corresponding index j of one[].

/Paul

Mathematicians are like Frenchmen: whenever you say something to them, they translate it into their own language, and at once it is something entirely different. (Goethe)
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Paul, you are right, a map would be faster and result in better code. However, you have to be careful in C++. By default a map in C++ uses the "less than" operator to compare two keys. This operator is overloaded for IloNumVar so that

IloNumVar x(env), y(env);
x < y // <- This is of type IloConstraint!

produces a constraint rather than a boolean value. When you try to do

std::map<IloNumVar,int> varmap;
map.insert(std::pair<IloNumVar,int>(x, 1));

you will get an error that IloConstraint cannot be converted to bool. So you either have to provide your own comparator to the map or use the values returned by IloNumVar::getId() or IloNumVar::getImpl() as key in the map (operator "less than" is not overloaded for those).
I think it is simpler to just use id or pointer to implementation as key but for the sake of completeness, here is one way (among many others) to actually use the variables as keys:

#include <map>
#include <iostream>
#include <ilcplex/ilocplex.h>
 
struct IloNumVarLess {
   bool operator()(IloNumVar const& v1, IloNumVar const& v2) const {
      return v1.getId() < v2.getId();
   }
};
 
int
main(void)
{
   try {
      IloEnv env;
 
      IloNumVar x(env);
      IloNumVar y(env);
      IloModel model(env);
 
      std::map<IloNumVar,int,IloNumVarLess> varmap;
 
      varmap.insert(std::pair<IloNumVar,int>(x, 1));
      varmap.insert(std::pair<IloNumVar,int>(y, 2));
 
      model.add(x < y);
 
   } catch (IloException& e) {
      std::cerr << "IloException: " << e.getMessage() << std::endl;
      return -1;
   }
   return 0;
}

#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Daniel,

Thanks for the caveat about the operator overload. Another reason for me to prefer Java to C++ (and if I get one more reason, I'll have to change the counter from int to long to avoid overflow).

/Paul

Mathematicians are like Frenchmen: whenever you say something to them, they translate it into their own language, and at once it is something entirely different. (Goethe)
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Completely off-topic but if you ever want to decrement that counter then look at C++ templates. They are a very powerful tool (I think much more powerful than Java generics) and are one good reason to use C++.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

> dju358 wrote:
> Completely off-topic but if you ever want to decrement that counter then look at C++ templates. They are a very powerful tool (I think much more powerful than Java generics) and are one good reason to use C++.

I use generics (meaning write new generic classes) only occasionally, and I don't recall bumping into any limitations that bothered me. I'm willing to believe that C++ templates are more flexible, so perhaps more powerful. That said, a flame thrower is more powerful than a flyswatter, but the flyswatter will make the fly dead enough for my purposes, and it's considerably easier to control. :-)

/Paul

Mathematicians are like Frenchmen: whenever you say something to them, they translate it into their own language, and at once it is something entirely different. (Goethe)
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Thank you very much. I got the answer.
#CPLEXOptimizers
#DecisionOptimization