CSE505/Assignment1
2024-02-22 23:50:15 -05:00
..
A feat: README 2024-02-22 23:50:15 -05:00
B feat: readme 2024-02-22 17:33:26 -05:00
C feat: readme 2024-02-22 17:33:26 -05:00
Extra feat: readme 2024-02-22 17:33:26 -05:00
randomgen.py feat: README 2024-02-22 23:50:15 -05:00
randompath.py feat: README 2024-02-22 23:50:15 -05:00
reachin1000 feat: README 2024-02-22 23:50:15 -05:00
README.md feat: README 2024-02-22 23:50:15 -05:00

Assignment 1

Part A

Append

xsb
['A/append.P'].
suffix([1,2], [1,2,3,4]).
cut([1,2,3]).

Reach

generate input set

python randomgen.py [number of nodes]
xsb
['A/reach.P'].
timeReach.
Input size Way 1 Way 2 Way 3 Way 4
1000 0.0 0.0 0.765 0.766
2000 0.0 0.0 3.047 3.047
5000 0.0 0.0 18.828 18.953

There is huge impact if we write edge(X,Y) before reach. But when I try this in swi-prolog(there is no cputime/1, so I cannot table it), there is no significant different between different ways of implementation.

Transitive closure and cycle

xsb
['A/cycle.P'].
path(1,2) .
cycle(1).

N-queens

xsb
['A/queens.P'].
timeNQueen(8).
timeOneQueen(8).
Number of queens Time for 1 queen Time for all queens
8 0.0 0.047
10 0.0 0.25
12 0.0 7.796
14 0.015 298.719
16 0.094 Too long to run
18 0.485 Too long to run
20 2.796 Too long to run
22 29.407 Too long to run

I found somewhing interesting when I tried to use swi-prolog to program this question. The following code works in swi-prolog(not xsb):

attacks((Row1, Col1), (Row2, Col2)) :-
    Row1 =:= Row2;
    Col1 =:= Col2;
    abs(Row1 - Row2) =:= abs(Col1 - Col2).

no_attacks(_, []).
no_attacks(Queen, [OtherQueen|OtherQueens]) :-
    \+ attacks(Queen, OtherQueen),
    no_attacks(Queen, OtherQueens).

queen_positions(0, []).
queen_positions(N, [(N, Col)|Queens]) :-
    N > 0,
    N1 is N - 1,
    queen_positions(N1, Queens),
    member(Col, [1,2,3,4,5,6,7,8]).

legal_queens([]).
legal_queens([Queen|Queens]) :-
    legal_queens(Queens),
    no_attacks(Queen, Queens).

n_queens(N, Solution) :-
    queen_positions(N, Solution),
    legal_queens(Solution).

but it runs ridiculously slow(takes seconds to compute one solution of 8 queens).Then I tried to play with it and rearrange it a little bit and the answer I got (in A/queens.P) now runs much faster in swi-prolog and runs succesfully in XSB.

Part B

Reach

generate input set

python randomgen.py [number of nodes]
clingo --models 0 B/reach.lp
Input size Way 1 Way 2 Way 3 Way 4
10000 0.655s 0.703s 0.664s 0.665s
20000 1.376s 1.446s 1.290s 1.292s
50000 3.355s 3.501s 2.750s 1.645s
100000 6.778s 5.002s 3.375s 3.438s
200000 12.119s 7.514s 7.267s 7.021s

Though it looks like the Way4 is way better tha Way 1(Almost twice as fast), but if we let the computer to rest for a while and rerun them the other way(start from 4, then 3, follow by 2 and 1), we got

Input size Way 1 Way 2 Way 3 Way 4
200000 7.146s 7.610s 7.120s 12.103s

It is exactly the other way around! I belive it is because the input file becomes too large (42 MByte), so it waste a lot of time to load it to memory then cache, and the following ones has much higher cache hits rate, so the first one takes way longer than the others.
The runtime grows linearly respect to the input size, and there is no significant difference between different implementations.

N-queens

clingo --models 0 B/nqueens.lp
clingo --models 1 B/nqueens.lp
Number of queens Time for 1 queen Time for all queens
8 0.004s 0.006s
10 0.003s 0.086s
12 0.004s 4.909s
14 0.006s Too long to run
20 0.011s Too long to run
50 0.073s Too long to run
100 0.463s Too long to run
200 3.233s Too long to run
500 35.073s Too long to run

Part C

N-queens

Number of queens Max k
4 3
8 3
10 4
12 5
14 5
16 5
18 5
20 5

Extra Credit

I

python .\randompath.py 5000
xsb
['A/cycle.P'].
timePath.
Number of Nodes Way1 Way 2 Way3
200 0.0 0.0 0.407
500 0.031 0.031 6.125
1000 0.109 0.093 50.75
2000 0.391 0.391 Too long to run
5000 2.484 3.093 Too long to run
10000 10.344 13.125 Too long to run

II

See Extra/2.pl

Number of queens Max k
4 3
8 3
10 4
12 5
14 5
16 5
18 5
20 5