I slightly modified 'check/roman.cpp' to perform series of 10 tests using the same model (everything: variables, constraints and model are initialized separately in each iteration).
When compiled and run on Debian 2.4.18 (gcc 2.95.4) all works fine, but exactly the same code built on Red Hat 2.6.9 (gcc 3.4.4) produced inconsistent results (see below):
It does not matter how many times I build and run this program, it always looks the same.
Moreover, when I embedded that test function in some larger program results were different (e.g. 3 out of 10 tests fail) but also the same for each run...
Once I've linked Red Hat version of my program with -lelisaboehm option the problemm disappeared!
As far as I know 'elisaboehm' library had been removed from standard elisa build, so why is it still vital for test application to run properly?!
My final test matrix looks as follows:
Debian
libelisaboehm, no Valgrind - OK
libelisaboehm, with Valgrind - OK
no libelisaboehm, no Valgrind - OK
no libelisaboehm, with Valgrind - FAILED
Red Hat
libelisaboehm, no Valgrind - OK
libelisaboehm, with Valgrind - OK
no libelisaboehm, no Valgrind - FAILED
no libelisaboehm, with Valgrind - FAILED
In both cases I've used Valgrind v2.2.0
Has anyone any hint, what might be wrong?
Regards
Roman
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I identified the location of the anomaly. It is in the NewtonReduction algorithm (returns randomly inconsistent!). I haven't repaired it yet. In the meantime, you can use "useBC4()" in main program instead of "useBC5()"
Best regards,
Marc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This block works excellent, heavily reducing initial domains! But now I've got into trouble...
Using default settings I've quickly received 'ChangeHeapOverflow' exception, so I started increasing values of ChangeHeap::_defaultSizeHeap' and 'ChangeHeap::_defaultMaxBox' finishing with 512 MB(!) and 67,108,864 (65536 * 1024) respectively. Each consecutive try returned more and more results (last test reported over 4 millions!) but I never managed to get complete solution (without exception raised). Apart from that, last test took about 20 minutes...
My primary goal is to compute values of v0, v2, v4 - is there any way to reduce computation complexity?
Where should I look for optimization hints?
Most probably I will face problems with about 12 variables and ~10 constraints - I'm really affraid that complexity may be the most serious problem...
Regards
Roman
P.S. Is it possible to alter post already published on this forum (by me, of course)?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Recenty I've been doing some memory management in elisa (mainly searching for memory leaks) but haven't released them in the repository yet. Can you send me your file by mail. I'll check if my modifications can help.
Btw, I don't know if is possible to alter post. I'll check in sf documentations tomorrow.
Marc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I slightly modified 'check/roman.cpp' to perform series of 10 tests using the same model (everything: variables, constraints and model are initialized separately in each iteration).
When compiled and run on Debian 2.4.18 (gcc 2.95.4) all works fine, but exactly the same code built on Red Hat 2.6.9 (gcc 3.4.4) produced inconsistent results (see below):
Test no. - solutions found
1 - 6005
2 - 0
3 - 6005
4 - 6005
5 - 6005
6 - 0
7 - 6005
8 - 0
9 - 6005
10 - 0
It does not matter how many times I build and run this program, it always looks the same.
Moreover, when I embedded that test function in some larger program results were different (e.g. 3 out of 10 tests fail) but also the same for each run...
Thanks for any help!
Roman
My test program
---------------
#include <elisa/elisa.h>
#include <iostream>
using namespace std;
using namespace elisa;
bool elisaTest( int testNo )
{
cout << endl;
cout << "-----------------------------------" << endl;
cout << "Starting Elisa test no. " << testNo << "..." << endl << endl;
IntVar v0( 670, 2000, "v0" );
IntVar v2( 234, 234, "v2" );
IntVar v4( 103, 198, "v4" );
IntVar v6( 670, 1875, "v6" );
IntVar v8( 29, 320, "v8" );
IntVar v10( 1, 450, "v10" );
RealConstraint c1(v10==189);
RealConstraint c2(v8==41);
RealConstraint c3(v6==1266);
RealConstraint c4(v0*1>=1201*1+1);
RealConstraint c5(v0*1<=1400*1);
RealConstraint c6((v0*v2*v4+0)*1>=(v6*v8*v10+0)*4);
RealConstraint c7((v0+0)*1<=(v6+80)*1);
RealConstraint c8((v0+0)*1>=(v6+-5)*1);
Model model = c1 && c2 && c3 && c4 && c5 && c6 && c7 && c8;
IntervalSolver solver( model );
solver.solve();
cout << endl;
cout << "Subsolutions found: " << solver.numSolutions() << endl;
cout << "Boxes processed : " << solver.numProcessedBoxes() << endl;
cout << "Elisa test no. " << testNo << " finished!" << endl;
cout << "-----------------------------------" << endl;
return ( solver.numSolutions() > 0 );
}
int main()
{
init();
double fPrecision = 0.5;
RealVar::SetPrecision( fPrecision );
BoxReduction::SetPrecision( fPrecision );
RealVar::SetDigits( 1 );
useBC5();
int nTest1 = 0;
int nTestTotal = 10;
for( int k = 1; k <= nTestTotal; ++k )
{
if( elisaTest( k ) ) ++nTest1;
}
int nTest0 = nTestTotal - nTest1;
cout << endl << "Test summary" << endl;
cout << "-----------------------------" << endl;
cout << "Number of tests performed: " << nTestTotal << endl;
cout << "Of which succedeed : " << nTest1 << endl;
cout << "Of which failed : " << nTest0 << endl << endl;
return 0;
}
My next observation:
Once I've linked Red Hat version of my program with -lelisaboehm option the problemm disappeared!
As far as I know 'elisaboehm' library had been removed from standard elisa build, so why is it still vital for test application to run properly?!
My final test matrix looks as follows:
Debian
libelisaboehm, no Valgrind - OK
libelisaboehm, with Valgrind - OK
no libelisaboehm, no Valgrind - OK
no libelisaboehm, with Valgrind - FAILED
Red Hat
libelisaboehm, no Valgrind - OK
libelisaboehm, with Valgrind - OK
no libelisaboehm, no Valgrind - FAILED
no libelisaboehm, with Valgrind - FAILED
In both cases I've used Valgrind v2.2.0
Has anyone any hint, what might be wrong?
Regards
Roman
Hi Roman,
I identified the location of the anomaly. It is in the NewtonReduction algorithm (returns randomly inconsistent!). I haven't repaired it yet. In the meantime, you can use "useBC4()" in main program instead of "useBC5()"
Best regards,
Marc.
Hi Marc,Hi Marc,
Thanks a lot! I switch to BC4 and all (ok, at least some) my problems dissapeared!
To continue bothering you, I have another question:
Consider the following problem:
Model =
(v6+0)*5 <= (v12+2)*1 &&
(v6+0)*5 >= (v12+-2)*1 &&
(v0+0)*1 == (v6+0)*1 &&
(v0*v2*v4+0)*1 >= (v6*v8*v10+0)*1 &&
(v12 == 1212) &&
(v14 == 300) &&
(v16 == 4087) &&
(v6*v8*v10+0)*125 >= (v12*v14*v16+0)*1;
Startup variables:
v0 = <143, 400> (size: 258)
v2 = <210, 260> (size: 51)
v4 = <80, 384> (size: 305)
v6 = <143, 400> (size: 258)
v8 = <210, 260> (size: 51)
v10 = <80, 384> (size: 305)
v12 = <650, 3900> (size: 3251)
v14 = <180, 15500> (size: 15321)
v16 = <60, 13000> (size: 12941)
Variables after 'solver::reduce()':
v0 = <242, 242> (size: 1)
v2 = <210, 260> (size: 51)
v4 = <153, 384> (size: 232)
v6 = <242, 242> (size: 1)
v8 = <210, 260> (size: 51)
v10 = <189, 384> (size: 196)
v12 = <1212, 1212> (size: 1)
v14 = <300, 300> (size: 1)
v16 = <4087, 4087> (size: 1)
This block works excellent, heavily reducing initial domains! But now I've got into trouble...
Using default settings I've quickly received 'ChangeHeapOverflow' exception, so I started increasing values of ChangeHeap::_defaultSizeHeap' and 'ChangeHeap::_defaultMaxBox' finishing with 512 MB(!) and 67,108,864 (65536 * 1024) respectively. Each consecutive try returned more and more results (last test reported over 4 millions!) but I never managed to get complete solution (without exception raised). Apart from that, last test took about 20 minutes...
My primary goal is to compute values of v0, v2, v4 - is there any way to reduce computation complexity?
Where should I look for optimization hints?
Most probably I will face problems with about 12 variables and ~10 constraints - I'm really affraid that complexity may be the most serious problem...
Regards
Roman
P.S. Is it possible to alter post already published on this forum (by me, of course)?
Hi Roman,
Recenty I've been doing some memory management in elisa (mainly searching for memory leaks) but haven't released them in the repository yet. Can you send me your file by mail. I'll check if my modifications can help.
Btw, I don't know if is possible to alter post. I'll check in sf documentations tomorrow.
Marc.
Marc, I've tried to send you my test program but your mailbox seems to be full :-(
Regards
Roman
If you wish to contact me directly, simply write to: RLichszteld@interia.pl