Originally posted by: GrandWazoo

I don't understand why I cannot multiply a float by 100 --

I discovered this problem while I was trying to figure out how to round allAllocs to 2 decimal places.

What do you think?

/*********************************************
 * OPL 12.7.1.0 Model
 * Creation Date: Oct 15, 2017 at 11:23:55 AM
 *********************************************/
{int} x = {1, 2, 3, 4, 5, 6, 7} ;

float divAllocs[x] = [ 
20986610,
7020720,
36674193.2,
14019716.8,
47841192,
30766644.8,
24619784 ] ;

float allAllocs = sum( i in x ) divAllocs[i] ;

execute {
 writeln( allAllocs ) ;
 writeln( allAllocs * 100 ) ;
} ;

/* Output:
181928860.80000001   <- correct to 7 decimal places
2147483647           <- wrong, should be: 18192886080.000001
*/

Hi,

the writeln in scripting is 32 bits but the value can be good even if the display is bad.

Let me change a bit your example:

{int} x = {1, 2, 3, 4, 5, 6, 7} ;

float divAllocs[x] = [
20986610,
7020720,
36674193.2,
14019716.8,
47841192,
30766644.8,
24619784 ] ;

float allAllocs = sum( i in x ) divAllocs[i] ;
float v=100*allAllocs;
float v1=floor(v / 1e8);
float v2=v-v1*1e8;
execute {
 writeln( allAllocs ) ;
 writeln( allAllocs * 100.0 ) ;
 writeln(v);
 writeln(v1);
 writeln(v2);
 writeln(v1,v2);
} ;

/* Output:
181928860.80000001   <- correct to 7 decimal places
2147483647           <- wrong, should be: 18192886080.000001
*/

dvar float xx;
subject to
{
xx==v;
}

gives

181928860.80000001
2147483647
2147483647
181
92886080
18192886080

and in the solution tab we see

xx = 1.8193e+10;

regards

Originally posted by: GrandWazoo

>> the writeln in scripting is 32 bits

I don't know whether to laugh or cry.

1. Is this limitation, among any others, documented somewhere?

2. CPLEX Studio is said to require, and exploit, 64-bit... I am running 64-bit hardware and operating system (Win 10).

CPLEX requirements

There is no note saying "... except the writeln function" :-)

Furthermore, it appears that the Java in use by the IDE is 64-bit:

C:\Program Files\IBM\ILOG\CPLEX_Studio1271\opl\oplide\jre\bin>.\java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build pwa6480sr4fp1-20170215_01(SR4 FP1))
IBM J9 VM (build 2.8, JRE 1.8.0 Windows 10 amd64-64 Compressed References 20170209_336038 (JIT enabled, AOT enabled)
J9VM - R28_20170209_0201_B336038
JIT  - tr.r14.java.green_20170125_131456
GC   - R28_20170209_0201_B336038_CMPRSS
J9CL - 20170209_336038)
JCL - 20170215_01 based on Oracle jdk8u121-b13

So it's hard for me to understand the root cause of this 32-bit limitation.

Do you think this example alone will be a sufficient basis for development to accept a defect PMR on this?

Thank you very much, Alex.