Yes, I mean a ViewArray. Cheers, Guido
> On 21 Oct 2015, at 11:21 AM, Tommaso Urli <tommaso.u...@nicta.com.au> wrote: > > Thanks Guido, > > Didn’t know about SharedArray. That seems the way to go for IntArgs. > Regarding the access from brancher, when you say “store a copy of the > IntVarArray inside the brancher” do you mean a ViewArray? > > Cheers, > > — > Dr. Tommaso Urli > Researcher, Optimisation Research Group > > DATA61 | CSIRO > E tommaso.u...@nicta.com.au > M +61 403 464 731 > Tower A, Level 3 > 7 London Circuit, > Canberra ACT 2601 > www.data61.csiro.au <http://www.data61.csiro.au/> > > CSIRO’s Digital Productivity business unit and NICTA have joined forces to > create digital powerhouse Data61 > > <CEB6FFF4-AD8B-4410-A802-D02DCB6D6512[4].png> > > From: Guido Tack <guido.t...@monash.edu <mailto:guido.t...@monash.edu>> > Date: Wednesday, 21 October 2015 at 11:16 AM > To: Tommaso Urli <tommaso.u...@uniud.it <mailto:tommaso.u...@uniud.it>> > Cc: "users@gecode.org <mailto:users@gecode.org>" <users@gecode.org > <mailto:users@gecode.org>> > Subject: Re: [gecode-users] Best practice: accessing IntArgs/IntVarArgs from > multiple places? > > Hi, > > IntArgs will have to be copied deep, so you shouldn’t keep them in the space. > IntVarArgs are not supposed to be kept as members of spaces (that’s why they > don’t have an update method), you should use IntVarArrays in that case. If a > brancher requires access to the variables, but you don’t want to store a copy > of the IntVarArray inside the brancher (which would be the usual way to do > it), you need to store it in the space and update it during copying (so that > they point to the correct copy of the variables). > > For parameters there’s another option: use a SharedArray. That one uses > shallow copying (based on reference counting), so it’s cheap to keep a > reference to a SharedArray in every space. You can also create your own > SharedObject if you need more than a single array. > > Cheers, > Guido > >> On 21 Oct 2015, at 9:39 AM, tommaso.urli <tommaso.u...@uniud.it >> <mailto:tommaso.u...@uniud.it>> wrote: >> >> Dear all, >> >> I have a question about the memory handling of IntArgs and IntVarArgs, and I >> cannot find an answer in the MPG. >> >> Let’s start with the IntArgs: when I write a model, I often copy the input >> data inside some IntArgs objects, so that I can then use them through the >> matrix interface, or post element constraints on them. This is fine, because >> I am in the constructor, and I can access them until the end of the scope >> which is enough to post the model. Sometimes, however, I need to access the >> same set of data in the print method, or in a custom brancher. I seem to >> have two choices here: either I build them from scratch by reading the input >> again (which is verbose, expensive, and clutters the code), or I can store >> them somewhere so that they stay accessible even out of the constructor’s >> scope. If I decide to store them, I can either store them as static members >> (which I don’t like, but allows me to forget about updating them throughout >> the space copies) or I can update them in the copy constructor. My doubt is: >> what is the memory footprint of keeping the IntArgs in the space? Will they >> be deep- or shallow-copied if I use their copy constructor? >> >> A similar question arises for IntVarArgs. I usually use them for temporary >> variables and the such, however sometimes I need to access them from a >> brancher. Should I just transform them in IntVarArrays in this case? >> >> Thanks for the insight, >> >> — >> Dr. Tommaso Urli >> Researcher, Optimisation Research Group >> >> DATA61 | CSIRO >> E tommaso.u...@nicta.com.au <mailto:name.surn...@domain.au> >> M +61 403 464 731 >> Tower A, Level 3 >> 7 London Circuit, >> Canberra ACT 2601 >> www.data61.csiro.au <http://www.data61.csiro.au/> >> >> CSIRO’s Digital Productivity business unit and NICTA have joined forces to >> create digital powerhouse Data61 >> >> <CEB6FFF4-AD8B-4410-A802-D02DCB6D6512[1].png> >> _______________________________________________ >> Gecode users mailing list >> users@gecode.org <mailto:users@gecode.org> >> https://www.gecode.org/mailman/listinfo/gecode-users >> <https://www.gecode.org/mailman/listinfo/gecode-users> > > > > The information in this e-mail may be confidential and subject to legal > professional privilege and/or copyright. National ICT Australia Limited > accepts no liability for any damage caused by this email or its attachments.
_______________________________________________ Gecode users mailing list users@gecode.org https://www.gecode.org/mailman/listinfo/gecode-users
