Hi Torsten

I'd like to address a couple of your questions.

On the one hand, one of the main differences between gecode and mozart relies 
in the fact that the propagation in mozart is eager by default which is a 
limitation for batch recomputation, however as far as i remember, geoz 
architecture was designed to support batch recomputation. 


Now, regarding your question about run-time performances (gecode and geoz). 
Yes, one of the main problems is that *all* search strategies are mostly 
implemented in Oz (propagation is performed by gecode). So this becomes a 
comparison between c++ and Oz (not to mention a couple of extra issues to take 
into account in the integration).



Finally, regarding the point of space combinators, the problem is more related 
to a combination of Space.merge and speculative computation (if i remember 
correctly), because it is necessary to "copy" and "paste" all propagators and 
variables from one space to another one (keeping track of variables' 
references). So one might think that this can be easily reached by cloning 
spaces, but unfortunately  this is not the case, because doing so we'll lost 
the references of the variables from the cloned space.

btw, gecode doesn't include combinators, it basically uses reified propagators 
(if needed).

 
I hope this helps,

Alejandro



________________________________
From: Torsten Anders <[email protected]>
To: Mozart users <[email protected]>
Sent: Sat, December 19, 2009 11:38:38 AM
Subject: Re: Mozart Next Release

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?

Also, I understand that for this reason the performance figures reported for 
Gecode cannot be reached with Geoz?


>> 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?
> 
> It is hard to say when this is going to be finished. We are facing different 
> issues on this integration that are still unsolved from the design point of 
> view. To give you an idea on one of the main problems: you should know that 
> mozart supports several programming paradigms including logic programming. To 
> support this we have the concept of space combinators (or, not, etc.) for 
> this to work we relay on a gecode feature called reflection. This feature was 
> removed from gecode in version 3.0 and we don't have a clear idea on how to 
> handle combinators without it.


Sorry, I don't understand. Since Gecode 3 you cannot ask a Gecode space anymore 
whether it is entailed or failed etc.? Gecode itself does not provide 
combinators (anymore)? How does Gecode then implement solvers, don't these rely 
on this information as well?

I really like the flexibility allowed by something like Combinator.reify, it 
allows for a very high-level control to defined complex CSP. On the other hand, 
such an approach can lead to weak propagation...

Thank you!

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



      
_________________________________________________________________________________
mozart-users mailing list                               
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users

Reply via email to