True, that makes total sense. This formulation of the problem is actually an adaptation from floating point constraints to integer constraints; so another way of solving it would be implementing something like FloatVar. But i couldn't find anything about that either.
Thanks anyway for the great work you are doing with Gecode! -- Javier Romero -- On Fri, Aug 20, 2010 at 5:49 PM, Guido Tack <[email protected]> wrote: > Javier Romero wrote: > > > Thanks for the fast answer. I tried decomposing the last constraint into > mul, sqr and linear rules, but i got the same result. I attached the code. I > compiled it by doing > > g++ parallelepiped.cpp -lgecodeminimodel -lgecodeint -lgecodesearch > -lgecodegist -lgecodedriver -o parallelepiped > > Ok, now it's easier to see what's going wrong. The problem is that the > equation may hold, but it cannot be expressed using IntVars because of the > limited domains. In your decomposition, the first constraint that exposes > the problem is > > sqr(*this,k,kk); > > At this point, k is already at least 2000000, but kk was initialized as an > IntVar with domain Int::Limits::min..Int::Limits::max. Therefore, the > problem has no solution, as 2000000*2000000 > Int::Limits::max. This is > expected and correct behavior. > Unfortunately, the minimodel layer lets you express constraints that are > (semantically) satisfiable, but the introduction of intermediate IntVars > makes them unsatisfiable. > For your actual problem, there's no way around this limitation except > implementing IntVars with arbitrary precision (using e.g. the gmp library). > This would be possible, but it's not something we're planning to do anytime > soon. > > Cheers, > Guido > > -- > Guido Tack, http://people.cs.kuleuven.be/~guido.tack/ > >
_______________________________________________ Gecode users mailing list [email protected] https://www.gecode.org/mailman/listinfo/gecode-users
