Closed VidicL13 closed 6 years ago
Poleg tega pa, ko sva zagnala kodo, ki jo imava v sage-u, je le ta v hipu vrnila vse rešitve, R pa je potreboval veliko časa za EN sam ne preveč obsežen primer. To nekako spodbija celoten članek, ki trdi da je dinamični program hitrejši. Znate morda to pojasniti?
Pa izpustila sva algoritme pri dinamičnem algoritmu, ki izračunajo seznam predmetov ki so v nahrbtniku pri OPT.. Ali je to krivo za tako odstopanje?
Če prav razumem, Merge združi rešitev za podproblem (N1, C1) velikosti 1 z rešitvijo splošnega podproblema (N*, C*) v rešitev za podproblem (N1 ∪ N*, C1 + C*). Vse, kar je potrebno narediti, je unija obeh rešitev, saj je na tem mestu cena za to delno rešitev že predpisana (in tako ne obstaja "boljša" rešitev).
Če je Sage vrnil rešitev v hipu, sklepam, da je bil podani primer majhen. Poskusita z večjim primerom - morda lahko poskusita bolj povečati število elementov kot pa samo kapaciteto nahrbtnika (na kar zna biti ILP bolj občutljiv). Samo računanje rešitve kot seznama elementov iz izhoda linearnega programa se opravi v linearnem času in tako ne bi smelo bistveno vplivati na odstopanje.
Problem je v tem, da sva v sageu naredila zanko ki gre čez vse podatke.. torej tudi čez primere ki so večji.. pa še vedno izračuna v prb 0.1 s. Tudi vsakič ko zaženeva zanko ki gre čez primere vrne vsakič drugačen čas, odstopanja so približno na 10^(-4)
Zanko lahko vidite na githubu... ta prebere csv datoteke in vrne čas trajanja ter optimum.
Problem bi znal biti tukaj:
V vsakem obhodu glavne zanke se torej (večkrat) izračuna delna vsota, zaradi česar je časovna zahtevnost algoritma O(n2 + nC) namesto samo O(nC). Delne vsote lahko vnaprej izračunata s funkcijo cumsum
, npr.
W <- cumsum(I$w)
P <- cumsum(I$p)
Vseeno svetujem še, da poskusita z večjimi primeri. Kolikor vidim, imata na repozitoriju primere z največ 100 predmeti - lahko poskusita z npr. 1000 predmeti (ali pa to nekoliko zmanjšata, če bi trajalo predolgo).
Sedaj sem popravil vsote in je zgodba popolnoma drugačna 👍 imam pa še vedno težavo pri interpretaciji X(N,C).
Ali je X(N,C) = [x1 ... x len(N) ]T vektor ali gre za seznam oziroma matriko...
Sedaj želiva dodati še kapaciteto algoritmu v Sageu, vendar ne veva kako pretvoriti list
v vector
. Posodobljen algoritem je na Githubu. Kako izvoziva rezultat?
*** WARNING: Code contains non-ascii characters ***
Error in lines 26-33
Traceback (most recent call last):
File "/cocalc/lib/python2.7/site-packages/smc_sagews/sage_server.py", line 1013, in execute
exec compile(block+'\n', '', 'single') in namespace, locals
File "", line 4, in <module>
ValueError: need more than 0 values to unpack
Tole napako mi vrže, ko skušam zagnati algoritem na sagu, brez dodanegakoncniC
X*(N, C) je v osnovi množica izbranih elementov za dana N in C - kako ga predstavita (npr. kot seznam elementov, ali kot logični vektor), je vajina izbira (in tudi ne bo težko prehajati iz enega načina v drugega).
Za računanje končne kapacitete lahko naredita tako:
resitev = program.get_values(vzamemo)
koncniC = sum(resitev[i] * w for i, w in enumerate(W))
Meni sicer ni vrnilo zgornje napake - z nepopravljenim algoritmom sem dobil le napako, da ni mogoče množiti slovarja in seznama. Poskusil sem s podatki iz #4 in s Korelirani_R10_N10.csv
.
Pri iskanju optimalne rešitve problema, se mi je zataknilo pri algoritmu. V pseudo-kodi je navedeno, da moram izvesti Merge na nizu delnih rešitev, vendar si ne znam predstavljati kako naj to zgleda.
Originalna koda se nahaja v
MCMKP.rmd
vrstica 213-289 prilagam tudi algoritem.