Hi Torsten, Thanks for your response! Looks like our email filtering sometimes blocks some messages from Mozart/Oz user-group as I did not get this message in my email and only found later while browsing the messages in the web. Yes, indeed I did play with recomputation and it did solve the memory issues partially (by using bigger recomputation distance). But our demand for tackling larger problems continued to grow and the Oz engine is crashing as soon as we feed larger problem. Run time is also an issue for these as well. That is why we are thinking of switching to Gecode. But before complete switch we would like to play with Geoz.
I am having trouble to get the Geoz code to play with. Can you help me where I can download the latest mozart-gecode? Is it from here (https://gforge.info.ucl.ac.be/svn/mozart/branches/mozart-gecode)? It is asking for some authentication and I am providing my Mozart group username/password and that is not working. Please let me know if there is another location where I can download this from. Thanks, Ashis > Sorry for the late reply, but have you tried recomputation? With > recomputation you can trade memory consumption for run time. A few > variants exist (e.g., fixed recomputation and adaptive recomputation). > Gecode and Geoz support batch recomputation, which considerably > improves the efficiency. > Best > Torsten On 18.12.2009, at 14:47, Maity, Ashis K wrote: > Hi, > > Currently we have a scheduling application using Mozart/Oz, but we > are running into trouble as our application is crashing in need of > more memory. Hence, we are planning to move to Gecode. However, > seeing the email below about having a Mozart interface to access > Gecode, I was wondering would that solve our memory issue? Or would > it still have that 32 bit memory limitation since it will be > initiated through Mozart/Oz? However, improved recomputation using > Gecode functionalities might help? Any comment on this is > appreciated! Also, when are we expecting this release (of Mozart- > Gecode interface)-- in days, weeks or months? There is a project > website called GeOz (seems defunct now) -- is it the same thing? > > Thanks, > > Ashis -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Torsten Anders Sent: Tuesday, December 22, 2009 4:12 PM To: Mozart users Subject: Re: Mozart Next Release Dear Alejandro and Gustavo, Thank you very much for clearing up this matters. Best Torsten On 21.12.2009, at 06:50, Gustavo Gutierrez wrote: > > > 2009/12/19 Torsten Anders <[email protected]> > Dear Gustavo, > > Thanks for your detailed reply. > > > On 19.12.2009, at 03:47, Gustavo Gutierrez wrote: > 2009/12/18 Maity, Ashis K <[email protected]> > However, improved recomputation using Gecode functionalities might > help? > > The current design of the integration only consider constraint > propagation in gecode and search is done in mozart. This means that > we don't inherit neither the existing search engines in gecode nor > the search stop objects. Allowing the direct use of the serch > engines is not straight forward but we have some ideas on how to > handle it. > > Ah, that is good to know. I assume that one of the advantages of > this design is that Geoz (i.e. Mozart with Gecode interface) > distributor strategies (branching strategies) can employ arbitrary > Mozart code. > > Nevertheless, does that also mean that Gecode features like batch > recomputation are not available? If not, could that be reimplemented > on the Mozart side? > > > As Alejandro already pointed, the design of the integration handles > batch recomputation. From a simplistic point of view we transformed > the default eager propagation approach into a lazy one. Existing > distributors will continue working but *won't* take advantage of > batch recomputation. New distributors are implemented in such a way > that will take advantage of it. > > The main idea behind doing the search from mozart is two fold: the > user can easily implement new distributors and search engines. This > is basically the reason of why we don't inherit existing search > engines in gecode (i.e. LDS). For the distributor implementation > there is something special: even in the current design (mozart > 1.4.0) it is possible for the user to implement distributors in oz > but there are implementation of the most common distribution > strategies directly in C++ for performance reasons. The current > state of the mozart-gecode branch provides the same distributors as > gecode and you can implement your ones in oz. > > <ATT00001..txt> Best wishes, Torsten -- Torsten Anders Interdisciplinary Centre for Computer Music Research University of Plymouth Office: +44-1752-586219 Private: +44-1752-558917 http://strasheela.sourceforge.net http://www.torsten-anders.de _________________________________________________________________________________ mozart-users mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-users ail (2.936) X-Mailman-Version: 2.1.5 X-MessageGate-spam: 101 X-MessageGate-virus: 6 X-Original-To: [email protected] X-OriginalArrivalTime: 22 Dec 2009 21:11:36.0300 (UTC) FILETIME=[586FFAC0:01CA834B] X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=1 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-0911030000 definitions=main-0912220193 X-SA-Exim-Connect-IP: 134.96.254.200 X-SA-Exim-Mail-From: [email protected] X-SA-Exim-Scanned: Yes (on mail.ps.uni-saarland.de) X-SA-Exim-Version: 4.2.1 (built Tue, 09 Jan 2007 17:23:22 +0000) X-SGSI-From: [email protected] X-SGSI-MailScanner: Found to be clean, Found to be clean X-SGSI-MailScanner-ID: 4F344EC9FC.00000 X-SGSI-Spam-Status: No, No X-SGSI-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-1.599, requis 5, autolearn=not spam, BAYES_00 -1.60), n'est pas un polluriel, SpamAssassin (not cached, score=0, requis 5) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on james.ps.uni-sb.de X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.3 X-Virus-Scanned: clamav-milter 0.95.2 at smtp-2.sipr-dc.ucl.ac.be X-Virus-Status: Clean Dear Alejandro and Gustavo, Thank you very much for clearing up this matters. Best Torsten On 21.12.2009, at 06:50, Gustavo Gutierrez wrote: > > > 2009/12/19 Torsten Anders <[email protected]> > Dear Gustavo, > > Thanks for your detailed reply. > > > On 19.12.2009, at 03:47, Gustavo Gutierrez wrote: > 2009/12/18 Maity, Ashis K <[email protected]> > However, improved recomputation using Gecode functionalities might > help? > > The current design of the integration only consider constraint > propagation in gecode and search is done in mozart. This means that > we don't inherit neither the existing search engines in gecode nor > the search stop objects. Allowing the direct use of the serch > engines is not straight forward but we have some ideas on how to > handle it. > > Ah, that is good to know. I assume that one of the advantages of > this design is that Geoz (i.e. Mozart with Gecode interface) > distributor strategies (branching strategies) can employ arbitrary > Mozart code. > > Nevertheless, does that also mean that Gecode features like batch > recomputation are not available? If not, could that be reimplemented > on the Mozart side? > > > As Alejandro already pointed, the design of the integration handles > batch recomputation. From a simplistic point of view we transformed > the default eager propagation approach into a lazy one. Existing > distributors will continue working but *won't* take advantage of > batch recomputation. New distributors are implemented in such a way > that will take advantage of it. > > The main idea behind doing the search from mozart is two fold: the > user can easily implement new distributors and search engines. This > is basically the reason of why we don't inherit existing search > engines in gecode (i.e. LDS). For the distributor implementation > there is something special: even in the current design (mozart > 1.4.0) it is possible _________________________________________________________________________________ mozart-users mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-users
