.dsy:it. (http://www.dsy.it/forum/)
- Algoritmi e strutture dati (http://www.dsy.it/forum/forumdisplay.php?forumid=207)
-- [Algoritmi] Progetto "RICHIAMI" (http://www.dsy.it/forum/showthread.php?threadid=17192)

diomio.... sentite, cercate di capirmi, io ho appena finito di seguire il corso di programmazione (primo anno) e ho ancora la testa che pensa in Java... non è che in questi giorni trovo al silab qualcuno di voi che possa darmi una mano sulle cose più futili del C? sigh sigh

__________________
Mai sottovalutare l'ampiezza di banda di una station wagon piena di nastri lanciata a tutta velocità lungo l'autostrada. - Andrew S. Tanenbaum - Reti di Calcolatori

Originally posted by p2p
backtracking funziona "come" se stesse visitando un albero, ma non è che devi usarlo solo con gli alberi, basta che gli passi i punti adiacenti per continuare la ricorsione, almeno io sto cercando di farlo cosi'

backtracking, dfs?!?!
....ma fiorentini quando mai ha pronunciato (non dico nemmeno spiegato) queste cose!?!?!?

il problema che si presentava con i grafi era che bisogna memorizzare nel grafo tutti i punto compresi nel rettangolo tra automa e sorgente, generando un grafo anche molto grande... quindi si cercava di fare qualcosa di alternativo... solo che ti dico, con il backtracking non è che sia cosi facile come sembra perchè inanzitutto se dentro alla funzione di backtracking si fa un ciclo per vedere se il punto è un ostacolo o meno(la checkpos del prof) bisogna considerare che le coordinate a partite dalla x e la y dell automa, potrebbero aver bisogno di essere incrementate o decrementate a seconda di dove si trova l automa rispetto la sorgente, e gia' qui un doppio for puo' coprire solo uno dei 4 casi.. non so se mi sono spiegato... insomma ci sono un po' di problematiche...
se qualcuno volesse dire come sta facendo....

Originally posted by mattcobain
backtracking, dfs?!?!
....ma fiorentini quando mai ha pronunciato (non dico nemmeno spiegato) queste cose!?!?!?

Sto ancora riguardando il testo del progetto...
Prima ho capito di essermi sbagliato ad interpretare le specifiche a quanto sembra su come devono muoversi questi automi e l'ho detto nel post.

Ora però, o è troppo tempo che lo rileggo.. tuttavia..

sull'esempio di input.. sbaglio anche questa volta o l'utente non immette alcun comando per il segnale fino alla fine ?
Io non lo vedo nella lista dei comandi.
Allora se non c'è, come faccio a calcolarmi i comandi e e t per esistePercorso e tortuosità ?

Se non viene immesso un segnale prima, come posso calcolare percorsi liberi e tortuosità ? E' tutto lì il problema.. ma se i segnali vengono immessi alla fine di tutti i comandi in input .. l'esempio sbaglio anche questa volta o semplicemente è impossibile che funzioni così ?

Io non leggo nessun comando s fino alla fine dei comandi in input...

Originally posted by wingzero
Sto ancora riguardando il testo del progetto...
Prima ho capito di essermi sbagliato ad interpretare le specifiche a quanto sembra su come devono muoversi questi automi e l'ho detto nel post.

Ora però, o è troppo tempo che lo rileggo.. tuttavia..

sull'esempio di input.. sbaglio anche questa volta o l'utente non immette alcun comando per il segnale fino alla fine ?
Io non lo vedo nella lista dei comandi.
Allora se non c'è, come faccio a calcolarmi i comandi e e t per esistePercorso e tortuosità ?

Se non viene immesso un segnale prima, come posso calcolare percorsi liberi e tortuosità ? E' tutto lì il problema.. ma se i segnali vengono immessi alla fine di tutti i comandi in input .. l'esempio sbaglio anche questa volta o semplicemente è impossibile che funzioni così ?

Io non leggo nessun comando s fino alla fine dei comandi in input...

mah, a logica è:

- arriva il segnale
- vedo la posizione da cui arriva
- prendo gli automi interessati
- per ognuno di questi controllo esistePercorso
- se esistePercorso cambio la posizione degli automi con la posizione da cui arriva il segnale

Mi pare che la tortuosità non contribuisca a determinare se gli automi si muovono o meno... si muovono solo se esiste un percorso di lunghezza minima, la tortuosità è un punto a parte... nessuno ci chiede di dire quale percorso segue l'automa per spostarsi, mi pare.

Comunque rinnovo il disperato appello... nessuno passa o passerebbe al silab in questi giorni a parlare un po' di questo progetto? <;-(

__________________
Mai sottovalutare l'ampiezza di banda di una station wagon piena di nastri lanciata a tutta velocità lungo l'autostrada. - Andrew S. Tanenbaum - Reti di Calcolatori

Originally posted by Jacoposki
mah, a logica è:

- arriva il segnale
- vedo la posizione da cui arriva
- prendo gli automi interessati
- per ognuno di questi controllo esistePercorso
- se esistePercorso cambio la posizione degli automi con la posizione da cui arriva il segnale

Mi pare che la tortuosità non contribuisca a determinare se gli automi si muovono o meno... si muovono solo se esiste un percorso di lunghezza minima, la tortuosità è un punto a parte... nessuno ci chiede di dire quale percorso segue l'automa per spostarsi, mi pare.

Comunque rinnovo il disperato appello... nessuno passa o passerebbe al silab in questi giorni a parlare un po' di questo progetto? <;-(

ragazzi, io dopo un po' di elucubrazioni sono giunto alla conclusione che "forse" il breadth-first search è la cosa piu' fattibile, perchè:
1) individua qualsiasi punto raggiungibile dalla sorgente(e quindi basta controllare se uno dei nostri automi è posizionato nei punti trovati dall' algoritmo,e poi si eseguono i controlli riguardanti le distanze);
2)il backtracking mi sembra un casino e non sono ancora riuscito ad implementarlo decentemente.

aspetti negativi:
1)bisogna costruire un grafo con tutti i punti compresi tra i vari automi e la sorgente cercando di eliminare i punti doppi, ovviamente.... anche qui non che sia poi cosi uno spreco di risorse xchè se devi vedere tutti i percorsi possibili non hai molte altre scelte.
2)bisogna fare una cifra di confronti... per vedere i punti, per vedere se gli automi ricadono nei punti, per gli ostacoli, ecc...

problema: come tengo traccia dei cambi di direzione???non saprei...

vorrei qualche commento da parte di chi si sta spaccando il cervello come me...


voi che ne dite? cosa state facendo?

__________________
{¯`·._)-•°o.O`·._.·´¯`•¸·´¯).·´¯`·-> IN DA EEKS <-·´¯`·.(¯`·¸•´¯`·._.·´O.o°•–(¯`·._}

mi spiegate cosa intende con l'output


SI
4
NO
-1
etc.. ?

grazie 1000

__________________
Non ti perdere di coraggio se ti tocca lavorare molto e raccogliere poco.....

pardon, trovato; mi era sfuggito

__________________
Non ti perdere di coraggio se ti tocca lavorare molto e raccogliere poco.....

Originally posted by wingzero
Riguardo la tortuosità.. rileggi la definizione perchè c'è scritto chiaramente che l'automa fra i percorsi liberi deve scegliere quello a tortuosità minore (minor numero di cambi direzione).
Io avevo all'inizio pensato ad una restrizione al riguardo un pò diversa, poi ho capito che non voleva quello, tuttavia la tortuosità è comunque un parametro necessario per scegliere quale percorso far seguire all'automa.

__________________
Mai sottovalutare l'ampiezza di banda di una station wagon piena di nastri lanciata a tutta velocità lungo l'autostrada. - Andrew S. Tanenbaum - Reti di Calcolatori

scusate ma non ho capito come lavora esistePercorso()

Il testo del progetto recita: se esiste un percorso libero di lunghezza D(P(n) , (x,y))

cosa vuol dire ?


altra particolarità: ma il programma dovrà generare l'output solo quando viene inserito il carattere 'f' ??

__________________
Non ti perdere di coraggio se ti tocca lavorare molto e raccogliere poco.....