[gecode-users] ViewArray <-> VarArgArray

Christian Schulte schulte at imit.kth.se
Wed Jan 18 10:39:06 CET 2006


The detour is due to coercion: there might not be an automatic coercion but
only a copy constructor declared "explicit".

Yes, always take fresh instances: this is also done when a propagator using
a view array is posted as a new copy of the array is created. The reason is
that the propagators actually change their data structures while
propagating.

No bounds, just limited by memory. This is tru for everything. The only
limit is min/max of variable domains.

Cheers
Christian

--
Christian Schulte, http://www.imit.kth.se/~schulte/ 

-----Original Message-----
From: users-bounces at gecode.org [mailto:users-bounces at gecode.org] On Behalf
Of Lars Otten
Sent: Wednesday, January 18, 2006 2:41 AM
To: users at gecode.org
Subject: Re: [gecode-users] ViewArray <-> VarArgArray


On 01/16/06 15:53, Guido Tack wrote:
> However, you can easily create your own IntVarArgs.
> Suppose x is an IntView array:
> 
> IntVarArgs xa(size);
> for (int i=size; i--; ) {
>    IntVar v(x[i]);
>    xa[i] = v;
> }

Just a minor point: Is there any reason why you did not just write
  xa[i] = x[i];
as the body of the for loop, but instead took the 'detour' via the explicit
IntVar?

Am I right in assuming that for every element propagator instance I want to
post I have to create a distinct IdxView<View,View>* instance? I tried using
the same instance for two propagator instances but then it segfaulted on
me...

Also, is there a theoretical bound on the number of propagators one can post
/ that can be present in a computation space at any given time (not
considering the limitedness of the computer's memory)? If yes, can one
predict what happens if this bound is exceeded?

Enough for today, it's really time to go to bed I guess... ;)

Cheers,
/Lars

_______________________________________________
Gecode users mailing list
users at gecode.org https://www.gecode.org/mailman/listinfo/gecode-users





More information about the gecode-users mailing list