Originally posted by: SystemAdmin

Hi,

I'm trying to use CPLEX 12.4 (64bit) to solve an integer linear problem with large numbers.
The problem is saved in a lp file, which I read and then try to solve using mipopt.

The integer variables are currently modeled as "GENERAL".

When trying to solve, cplex tells me
CPLEX Error 3018: Magnitude of variable x10: 2.14853e+09 exceeds
integer limit 2100000000.

Apparently cplex is able to display values beyond the integer limit, but unable to solve the ILP. Is there a way to increase the integer limit? Unfortunately reformulating the problem is not an option.

Thanks a lot

Arno
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

No there, is no way to increase the bound. The value (and bound) of an integer variable must be representable by a 32bit signed integer and must not exceed the internal upper limit 2.1e9 (which is almost the biggest value possible).
Are you sure you need the full range of numbers up to 2^31-1? Or do you just use very large values to represent "infinity"?
You said that reformulating the problem is not an option but would it be an option to just shift the variables by some large constant to get them into the supported range?
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Thanks for your reply. We use CPLEX in real-time systems research to find optimal solutions for memory address allocation. The variables represent memory addresses. Some of our systems make use of the complete memory range of the target architecture so shifting or cutting of the address space is not possible.

At the moment, as a workaround for 32bit target systems, we found out that we can use SEMI-CONTINUOUS instead of GENERAL for the variables. However SEMI-CONTINUOUS variables have a limit of 10^10-1 resulting in the same problems as soon as we analyze architectures with larger address spaces. As (10^10)-1 needs 34bit for its representation which is well beyond the 32bit address limit I wonder if there are any numerical reasons for these hard-coded limitations?
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

It might be a bit tedious, but my guess is you could model memory spaces by dividing them into "panes" of a size less then the CPLEX integer variable bound, then model each address by an integer variable (or, more likely, a set of binary variables) signaling which pane contains the address plus a general integer variable for the offset within the pane. There'd be a bit of tedium dealing with address blocks that straddle a pane boundary, but I'm pretty sure it can be handled.

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

Just curious: Can you really allocate/place objects at any address? Don't you have alignment issues/requirements? Even if you require only a 2-byte-alignment (which I think is not enough in real world) you are in business since the number of addresses you can assign to drops below 2.1e+9.
The technical reason for the 2^31-1 limit is that internally the bounds of integer variables are sometimes represented as 32bit signed integers.
Also note that there is another kind of limit: Usually all computations are done using IEEE double precision floating point numbers (data type 'double' in C). This data type can represent integral numbers. However, although double precision numbers can go up to very large values, there is a problem: If you go beyond a certain magnitude (2^53) then double precision numbers cannot represent all integers beyond that. There will be "holes" between integers and an operation like "x += 1" is not even guaranteed to change x at all.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Our current platform indeed uses a 2-byte alignment. However, as soon as we analyse 64bit architectures, saving one digit won't really help. The current workaround (adding the variables to SEMI-CONTINUOUS and GENERAL) raises the variable limit to 10^10-1 which is enough for 32bit architectures (I suppose the new limit results from the maximum double precision minus some kind of margin).

Thanks for all your replies. We'll probably stick to SEMI-CONTINUOUS+GENERAL and try Paul's approach for 64bit architectures.
#CPLEXOptimizers
#DecisionOptimization