Thanks for your reply, Raphael! I totally agree with you that that way of doing things should be avoided. However, the current implementation draw upon concurrency very rarely (when there are only two choices remaining), limitedly (the two recursive calls do run in the same thread) and apparently side-effectively. What's more: then we have Search.parallel, which is the only branch that really benefits from concurrency/paralelism.
My real _question_ is: wouldn't we be better-off if we could trust the sequentiality of the activation of alternatives in certain search procedures, even if it is not advisable to rely on it? Otherwise, I think the docs should point out the possibility of concurrency explicitly. Cheers, Jorge. Quoting Raphael Collet <[EMAIL PROTECTED]>: > Jorge Marques Pelizzoni wrote: > > Much to my dismay, I found out that the above solution does not work > because > > SearchAll runs both alternatives (partially) concurrently, as in > (extracted > > form Search.oz): > (snip) > > My question is: in the light of this, can the behaviour of SearchAll be > > considered to contain a (slight) bug? > > Not at all. You are assuming that search *must* be sequential, which is > the (old) Prolog view. Oz proved that that assumption was wrong. It > prohibits yourself from parallel search and recomputation. The latter > one improves performance in such a way that Oz can be competitive with > industrial CSP tools! > > What you are doing is messing up with the search engine. Don't. Don't > do that, ever! This is too bug-prone, and almost guaranteed to fail > some day. > > Filip Konvicka's approach, using penalties and a branch-and-bound search > looks like a good idea to me. > > I know an example of that same technique here. My colleague Fred > Spiessens had a problem, but he was interested into a set of "relevant" > solutions only. We found out that those "relevant" solutions were > maximal with respect to some partial order. He first hacked a search > engine of his own, but was quickly overwhelmed by the complexity of the > job. Then I suggested a reformulation of the problem that was giving > exactly what he was looking for, with SearchBest. He never got back to > his search engine... ;-) > > raph > _________________________________________________________________________________ mozart-users mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-users
