Re: [eclipse-clp-users] Copying domain and delayed goals

Hello Joachim,

Thanks, that approach with undo query constraints using fail totally
makes sense.
I've just implemented it for my problem and for the problem it works
200 times faster than doing large set of constraints from scratch for
every query.

As far as I understand, 'report_answer' and 'report_no_answer' are
required to do something extra-logical, like writeln or setting
non-logical variable, right? (I've implemented it using non-logical
variables.)

Sergii.

On Tue, Apr 23, 2013 at 3:49 PM, Joachim Schimpf <jschimpf_at_coninfer.com> wrote:
> On 23/04/2013 22:38, Sergii Dymchenko wrote:
>> Hello,
>>
>> Is it possible to copy domain and delayed goals of some variables to
>> another variables?
>>
>> I tried (after lib(ic).):
>>
>>> A :: 1..3, B :: 1..3, A #\= B, copy_term([A, B], [AN, BN]).
>> A = A{1 .. 3}
>> B = B{1 .. 3}
>> AN = AN{1 .. 3}
>> BN = BN{1 .. 3}
>>
>> Delayed goals:
>>      -(B{1 .. 3}) + A{1 .. 3} #\= 0
>> Yes (0.00s cpu)
>>
>> But I'd also want to have delayed goal -(BN{1 .. 3}) + AN{1 .. 3} #\= 0
>
> The system does not attempt to do this automatically, because in
> general that would require to "project" the existing constraints
> onto the set of variables that gets copied, and there is no generic
> way to compute such a projection for arbitrary constraints.
>
> If you knew which constraints can occur (such as #\=), you could
> attempt to write your own copying routine, based on copy_term/3,
> copying the delayed goals explicitly, but that approach is probably
> too complex and fragile.
>
>
>> If it's not possible then I'd appreciate any suggestions how I should
>> implement the following scenario:
>> - Large number of constraints, that takes some time to propagate,
>> possibly leaving delayed goals.
>> - Many small independed 'queries', each query is an additional small
>> number of constraints.
>> - Do propagation for the first (large) set of constraints once
>> - For every query add additional constraints and label variables.
>> Obviously for every new query there should be a 'fresh copy' of the
>> large set of constraints - propagated, but not labeled.
>
> That does not sound very different from what is done during search:
> in every branch of a search tree node, a different "small additional
> constraint" is added and propagated.  Once a branch has been explored,
> backtracking takes you back to the computational state *before* the
> extra constraint was added, and a different one can be tried.
>
> That way, you don't copy the large constraint setup, you instead
> undo the incremental modification.  Your code structure would
> be something like this:
>
> main :-
>      setup_constraints,
>      % propagation happens automatically
>      answer_queries.
>
> answer_queries :-
>      get_query,
>      (
>         add_constraints,
>         % propagation happens automatically
>         labeling,
>         report_answer
>      ;
>         report_no_answer
>      ),
>      fail.
> answer_queries :-
>      answer_queries.
>
> On every recursive call of answer_queries you are back to the same
> starting point (because you have failed across add_constraints).
>
>
> -- Joachim
>
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
> _______________________________________________
> ECLiPSe-CLP-Users mailing list
> ECLiPSe-CLP-Users_at_lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/eclipse-clp-users