Domande sul Modulo Due

• Aggiungete le vostre domande in fondo alla pagina

---

(senza titolo)

-- FabioNatalucci - 18 Apr 2008

---

(senza titolo)

-- RiccardoMengarelli - 29 Apr 2008

---

(senza titolo)

Quando c'è la consegna? Grazie

R.

-- RiccardoMengarelli - 29 Apr 2008

---

watches list

1.nel vecp watches, il void** deve puntare ad un array di int? 2.bisogna implementarlo attraverso una pila? 3.il vecp watches,si riferisce a clausole ripetute o ad letterali ripetuti?

grazie

vec_p *watches; per ogni letterale contiene la liste della clausole watched. Si 
                                       tratta di un array di dimensione 2*nof_var, con la convenzione 
                                       che le info relative alla variabili xi vengono salvate in posizione
                                      2*i se la variabile è positiva e 2*i+1 se la variabile è negativa

-- AlessandroMiliucci - 30 Apr 2008

---

Dubbio su solver_search

salve! Qualcuno sa dirmi perchè il parametro nof_conflitti e nof_clauses devono essere inizializzati rispettivamente a "100" e a "numero di clausole /3" ?

solver_search( solver*s, double nof_conflitti, double nof_clauses)

-- MatteoDCarlo - 02 May 2008

---

Dubbio su solver_search 2

scusate, riformulo: Qualcuno sa dirmi perchè il parametro nof_conflitti e nof_clauses devono essere inizializzati rispettivamente a "100" e a "numero di clausole APPRESE /3" ? (ma il tasto modifica??? :D)

lbool solver_search( solver*s, double nof_conflitti, double nof_learnts)

-- MatteoDCarlo - 02 May 2008

---

Re: Dubbio su solver_search 2

Non ne ho idea... spero che prima o poi qualche professori passi sul forum a darci delle delucidazioni

-- DonatoCapitella - 02 May 2008

---

Re: Re: Dubbio su solver_search 2

I valori iniziali di nof_conflitti=100 e nof_clauses=apprese/3 sono "arbitrari", così come il loro aggiornamento moltiplicandoli per 1.1 e 1.5, rispettivamente, quando solve_search restituisce UNDEF. Sono stati scelti analizzando il comportamento del sistema con vari input (euristica)

-- FrancescoParisiPresicce - 02 May 2008

---

Stack e Code

Salve,

non ho ben chiari un paio di punti relativi al trattamento di alcuni campi del solver, che vanno trattati come stack e code:

1) vec_i Pcoda da trattare come coda -> va utilizzato il vettore di interi presente in vec_i come "storage" per gli elementi (lit) della coda?

2) lit *trail, vettore di interi, da trattare come stack -> Si intende che le primitive dovranno essere del tipo pop(lit *), push (lit *) ecc? In assenza di una struttura di stack vera e propria, e quindi di un counter di elementi, è possibile usare il valore 0 come terminatore dello stack? (Il letterale 0 non è utlizzato)

3) vec_i trail_lim, da trattare come stack -> Si intende che stavolta il vettore di interi in vec_i? Non posso usare le primitive del punto 2, devo quindi implementarne di nuove?

Grazie mille, CM

-- CristofaroMune - 04 May 2008

---

No such template def TMPL:DEF{PROMPT:thread}