What about this simple case:
a) Your solution
declare
proc {Foo Root}
A B C Dis
in
Root = solution(a:A b:B c:C)
[A B C]:::0#50
{FD.impl A=:1 (B::1#20)+(C::1#20)=:2 1}
A=1
{Space.waitStable}
Dis = {Record.filter Root fun {$ X} {Not {FD.reflect.min X} == 0}end}
{FD.distribute ff Dis}
end
{ExploreAll Foo}
b.) The solution that I suggest you
declare
proc {Foo Root}
A B C C1
in
Root = solution(a:A b:B c:C)
C1::0#1
[A B C]:::0#50
thread or C1=:0 A=:1 B::1#20 C::1#20 [] C1=:1 A\=:1 end end
A=1
{FD.distribute ff [C1]}
end
{ExploreAll Foo}
To reduce the number of threads you can take advantage of the following:
A->B1
A->B2
.
.
A->Bn
---------
A-> B1,B2,...,Bn
I think you are not spending too much in the computation simply because
your application is not generating cases like the above.
Ok, I think I see what you mean; and I get less solution printouts
(printing vars with '1#20'). Yet, these two examples are still no big
deal, if I leave out the System.show of the solution(s) I get almost
identical times. But I'll keep this is mind. Hmm, one thing just struck
me: are Oz threads equal to native OS threads...or are Oz threads
handled internally by some mechanism....(<sifting docs...>)...ah, I just
found a paragraph saying that 'Oz threads are so cheap that I can afford
to create 100000 of them'. That seems to imply that they have nothing to
do with OS threads? And, this probably removes my concern about the
thread count and thus makes your solution that much more viable.
A more immediate thing I think is to do the 'dynamic' posting of
constraints defined by some data file. But there I'm at a loss on if I
can dynamically create and refer to variable names...I mean, in the
samples I know about A, B, C and so on, but in dynamic generic code I
have to generate all this...?
BTW, disregarding a generic program, another optimization that I could
take advantage of for a fully generated program is what I think you
refer to above with 'A -> B1, B2,...,Bn'. Again, not using your
alternate solution, parts of the program now can look like this:
{FD.impl A=:1 B=:1 1}
{FD.impl A=:1 C=:1 1}
{FD.impl A=:1 D=:1 1}
Wouldn't it be more efficient if I could write this as one line? I
experimented, and came up with this:
{FD.impl A=:1 local DUMMY in B=:1 C=:1 D=:1 end 1}
For some reason, I can't leave out DUMMY but if I have it the compiler
warns...oh, I guess I could stick something stupid like 'DUMMY=1' in
there or something, but I'd just rather leave it out. Again, I've seen
the use of '_' in places, but am unable to find references to it in the
documentation other than it being a wildcard for an anonymous var...?
Anyway, I stuck it in there instead of DUMMY and the code compiles and
seems to give me the same answers as before so...but the question is, am
I doing it wrongly and how should it be done otherwise?
Luis, thanks for your time and patience with lots of stupid questions...
ken1
-
Please send submissions to users@mozart-oz.org
and administriva mail to users-request@mozart-oz.org.
The Mozart Oz web site is at http://www.mozart-oz.org/.