Maity, Ashis K wrote:
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)?
Hi Ashis,
That's the correct address. The svn repository is hosted at GForge/UCL. You
have two choices here. Either you create a gforge user for you, or you use our
generic mozart user, which is simpler:
svn checkout --username mozart \
https://gforge.info.ucl.ac.be/svn/mozart/branches/mozart-gecode
And the password is mozart too.
cheers
Boriss
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
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
