[Oz] beginner: distributing data fields over documents

[Garibald Hennes]

Denys, thanks for the fast answer, but it gives no solutions for realistic
problem sizes, see below. Maybe someone can give me a hint at how to debug
and/or start to optimize this (Not even Explorer.one does work)

On 28 Nov, Denys Duchier wrote:
>[...]
> Here is my interpretation of your problem:
> * there is a finite set of fields
> * each document is described by a subset of these fields
> * you want to partition the set of fields into blocks
>   such that the documents can now be described in terms
>   of blocks (i.e. for each block and each document, the block
>   is either a subset or disjoint with the set of fields of
>   the document)
> * furthermore, you want the smallest number of blocks
>=20

Correct.

> Here is my solution. =20

Works nice for examples, but: using it on real data (22 documents, 174
fields) seems to lead nowhere. I tried using explorer, search.best.bab
and search.best.restart (both with different recomputation distance, 1,
2, 5 and 10) and get no solution after (max) 20 Hours run.

This is my data set:
[{2 4#5 9 12#14 16#17 19 35#38}#14 
 {2#6 8 10 12#14 16#17 35#37}#15 
 {2#8 10 22#23 27}#11 {21#28 30#33 123#124 126}#15 
 {12 22#24 117#118 145#155}#17 {22#23 53#98}#48 
 {2 5 22#24 29 32#33}#8 {22#24 32 116#119}#8 
 {4#5 22#24 32 121#143}#29 
 {22#23 53 55#58 65#67 69#70 72 83 87#88 114 138 140 150}#20 
 {5 22#24 100#114}#19 {166#169 171}#5 {12 47#50}#5 
 {12 22#23 40#45}#9 {22#24 32#33 157#163}#12 
 {2 4 22#24 29 32#33}#8 {5#7 13 56 114 173#174}#8 
 {3 5#6 12#13 17 36#38 107 121#122 130 151 174#175}#16 
 {3#7 52 121}#7 
 {2#3 6 8 12#13 16#17 24#26 31 36#38}#15]

If I start the panel, it will stop producint output after a time.

The system statistics shows (after from a few minutes to an hour,
depening on machine, OS and possibliy recomp distance) about 90% system
time, allmost no user time. Where does this come from.

This is on a 2-processor system, running FreeBSD-4.2, using recomp
distance of 10 and after 14 hours running time:

last pid:  3972;  load averages:  1.03,  1.02,  1.00              up
0+19:1=
8:51  10:55:44
75 processes:  2 running, 73 sleeping
CPU states:  0.0% user,  4.7% nice, 45.3% system,  0.0% interrupt, 50.0%
id=
le
Mem: 245M Active, 195M Inact, 42M Wired, 18M Cache, 61M Buf, 1028K Free
Swap: 1029M Total, 1029M Free

  PID USERNAME    PRI NICE  SIZE    RES STATE  C   TIME   WCPU    CPU
COMMA=
ND
 2697 mathiasp     69   5   140M   139M CPU0   1 986:40 98.93% 98.93%
emula=
tor.
 3965 mathiasp      2   5 10336K  9340K select 0   0:09  0.59%  0.59%
wish8=
.2
 2710 root         28   0  2088K  1280K CPU1   0   1:24  0.00%  0.00% top
 2526 awieden      10   0  1772K  1068K nanslp 0   1:19  0.00%  0.00%
asclo=
ck
  744 root          2   0 16264K 14416K select 1   1:00  0.00%  0.00%
XF86_=
SVGA
 2560 root          2   0  2440K  1644K select 1   0:26  0.00%  0.00% sshd
  265 nobody        2   0 24480K 23560K poll   0   0:25  0.00%  0.00%
squid
 2519 awieden       2   0 11484K 10156K select 1   0:20  0.00%  0.00%
GWork=
spac
  574 root          2   0  3292K  2876K select 1   0:17  0.00%  0.00% gdnc
 2396 awieden       2   0  3612K  2692K select 1   0:12  0.00%  0.00%
wmake=
r


How can one debug such a behaviour??

The panel show about 338 solutions and > 140000 failed spaces before it
stops to update the display.

All this is really fascination, I now start to explore it using
Explorer.one, but this takes allready 20 minutes without a solution,
almost locking up my (350Mhz single-cpu Linux RedHat 6.0) machine.

Cheers, Mathias

-- 
Sent through GMX FreeMail - http://www.gmx.net

-
Please send submissions to users at mozart-oz.org
and administriva mail to users-request at mozart-oz.org.
The Mozart Oz web site is at http://www.mozart-oz.org/.