Re: Is Prolog a good language for generating semi-random, constrained solutions?

On 03/24/2014 10:32 PM, Kaitain Jones wrote:
>> I'm not sure how fair it is to hold Prolog hardly be held accountable for
> shortcomings that would be as true, if not more true, with all other
> options.
>
> Oh, I agree, and I'm certainly not throwing any blame at Prolog: I think
> this is just a fundamental issue with the problem domain. PL has certainly
> proven well-equipped for specifying the constraints in an elegant manner,
> and my current system does seem to work. I had just been wondering if I was
> missing some ingenious ninja-level Prolog moves that could make things even
> better.

We only have a brought id of your latest ninja code :-) I think that
Prolog adds two things to tackle the case where naive generate-and-test
proves to be too slow: constraints and easy integration of DSLs.
Constraints provide a neat way to merge testing inside the generator,
such that it is executed as early as possible. In a sense, I guess we
can see that as a form of `aspect programming'. Instead of

	generate, test

you  get

	set_constraints, generate, test

where test can also become empty. In addition constraints allow to
reason about the domains of variables and avoid brute force generate and
test. DSLs allow you to express your problem natively and generate the
dirty stuff in the generate routine automatically, or do simple things
such as goal reordering to reduce backtracking.

The thesis by Markus Triska about clp(fd) brings all this nicely
together!

Also interesting is the tor pack (http://www.swi-prolog.org/pack/list?p=tor)
which allows separating the search strategy from the program logic, so you
can easily explore alternatives.

Finally, there is call_with_depth_limit, call_with_inference_limit and
threading which all allow you to explore alternative search strategies
together.  Might combine nicely with tor.

	Cheers --- Jan

P.s.	When I was in Vienna, Markus and I chatted briefly about the
	idea to have a Prolog thread `fork', i.e., a call that creates
	a new thread as a copy of the running one.  This would require
	some restrictions, i.e., we cannot fork if Prolog is called
	from C in an arbitrary way.  Is that worth investigating at
	some point?



> -------------- next part --------------
> HTML attachment scrubbed and removed
> _______________________________________________
> SWI-Prolog mailing list
> [email protected]
> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
>