Just saying what Raphael said a bit differently. It might help you decide what you really mean if you take into consideration that:
thread if B == 2 then ... end end will not fail when B \= 2, while thread (B == 2) = true ... end will. And by 'fail' here I mean 'raise (a) failure (exception)', which will produce a failed space. So, if you intend to post something like the the second option unconditionally, you might as well just write B=2 and those constraints right away, even without a new thread. Cheers, Jorge. 2009/7/19 mark richardson <[email protected]>: > Hi, > > Thanks for your reply. > I really, really wasn't expecting this sort of reply. I'm now in the > uncomfortable position of trying to decide exactly what I DO mean :+) > > To put the problem into a clearer perspective, it concerns 3 variables A,B > and C. > A is a FD integer which represents a virtual actor, B is a FS which > represents one or more other virtual actors. > C is a FD integer which represents an interaction which is possible between > virtual actors depending upon characteristics of those agents. > At the moment I'm using the format: > > thread > if C==x then > <post constraints on A and B to match interaction x> > end > end > > My thought was that I could possibly make speed improvements on this by > replacing the 'if' statement with something which would cause the thread to > fail sooner - namely the (C==x)=true idea. > > Now I'm struggling to decide if saying something completely different > semantically by doing this will fundamentally alter the function of my > program or even whether I'm structuring my problem logic correctly in the > first place. > I think some more thought on this might be in order :+) > > Regards > > Mark > > > Raphael Collet wrote: > > Dear Mark, > > Your two threads simply implement different semantics! See below: > > On Sun, Jul 19, 2009 at 10:05 PM, mark richardson <[email protected]> > wrote: >> >> Hi, >> >> I have a constraint based problem that implements constraints as >> explicitly defined threads. An if statement guards whether the constraint is >> imposed or not. For example one of the constraints could be something like: >> >> thread >> if B==2 then >> <post some constraint> >> end >> end > > This threads tries to enforce the logic statement (B==2 and <constraint>) or > (B\=2). If B is different from 2, the logic statement is equivalent to > 'true'. > >> >> My program isn't as simple as this and there IS a good reason why I'm >> doing things this way :+), but it demonstrates the basic idea. >> >> My question is this (although I can't think of a simplified example to >> test it with); would the above code block prove more efficient like this: >> >> thread >> (B==2)=true >> <post some constraint> >> end > > This second threads enforces the logic statement (B==2 and <constraint>). > In this case, if B is different from 2, the logic statement is equivalent to > 'false'. Therefore both threads are not equivalent from a logic point of > view. > >> >> Here I'm assuming this thread would signal failure whenever B was not 2 >> and subsequently fail the space it was in. >> In other words, are there any efficiency gains to be made by using failure >> as a guard for the constraint rather than a logic conditional statement? >> (Obviously I'm talking about a very large number of calls to this thread.) > > The first question is: which of the two logic statements correspond to the > problem? > > For the first semantics, it is possible to use an 'or' statement, and let > the posted constraint be evaluated in a subspace. > > or B=2 <post some constraint> > [] B\=:2 > end > > If the posted constraint fails, the 'or' statement will automatically > enforce the remaining clause, i.e., B\=2. Note that this technique should > be used with care, because it creates more computation spaces, but it can > pay off if the posted constraint is likely to fail... > > Cheers, > raph > > ________________________________ > _________________________________________________________________________________ > mozart-users mailing list > [email protected] > http://www.mozart-oz.org/mailman/listinfo/mozart-users > > -- > Mark Richardson > Research Assistant > University of Teesside, UK > [email protected] > [email protected] > [email protected] > > _________________________________________________________________________________ > 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
