linux user group brescia

On Sat, Jul 12, 2003 at 11:24:44AM +0200, Vernia Damiano wrote:
> > ??? Cosa vuoi dire ???
> 
> 	Esempio:
> 
> p net 21 26 19 5 8
> n 32 1600
> a 1 2 100 10
> d   19    4   48
> 
> 	Questo e' il file piu' piccolo che devo analizzare. Sono 740 byte, 
> che corrispondono ad un'istanza di problema di 56-57 kbyte (occhio al k).
Pochi tipi. Se la complessita' e' su questi livelli potresti evitare le
regex e analizzare direttamente le stringhe.
 
> > di solito si vuole fare il contrario: trasformare files binari in 
> > testo (formattato) per poterlo meglio processare...
> > usare files binari e' una brutta cosa(tm)
> 
> 	Ti credo, ora occhio a questo caso: il file sopra corrisponde alla 
> descrizione di una rete di telecomunicazioni. Io devo trovare dei percorsi 
> all'interno di questa rete. Questi percorsi vengono memorizzati come un 
> vettore lungo quanto il numero di nodi (numero che puo' raggiungere al 
> massimo 65000, quindi 2 byte) quindi un percorso (comunque lungo) occupa 
> in memoria 2 * Nnodi byte. Devo tenere in memoria 2 percorsi per ogni 
> relazione di traffico, senza contare tutte le altre diverse correlazioni 
> con dati che non sto a citare, tra cui esistono numerosi bitmap.
> 	Gia' il programma e' complesso di suo, se poi mi studio anche un 
> formato testuale per salvare e ricaricare i dati buonanotte.
Mi viene un'idea un po' idiota. Si potrebbe usare un pianificatore con un
dominio ad hoc?

> > > 	Se non ricordo male awk e' un linguaggio interpretato (tanto per
> > > questa fase non ho assolutamente bisogno di velocita') pensato apposta per
> > > questo lavoro. Mi sbaglio?
> > 
> > Senti... il discorso velocita' di esecuzione ha poco senso quando si parla
> > di selezione del linguaggio per lo sviluppo di software.
> 
> 	Sinceramente non credero' mai che un linguaggio interpretato sia 
> piu' veloce (o simile) a uno compilato. Sono un fan dei linguaggi 
> interpretati piu' che dei compilati, ma se mi metto a scrivere 
> l'ottimizzatore in python (tanto di cappello, lo voglio imparare), sempre 
> ammesso che il relatore non mi squarti, penso che ci metterebbe 
> decisamente di piu' ad ottenere lo stesso risultato ottenibile con lo 
> stesso algoritmo implementato in C (che a sua volta da risultati peggiori 
> dell'ASM, es. sui DSP anche 8-9 volte...).
...
Puo' darsi. Ma garantisco che la cosa dipende in primis dalla qualita'
dell'implementazione. Esempio:
mi dicono di usare un programma in C che da una rete completamente connessa
in modo bidirezionale trancia un certo numero di links controllando con
Dijkstra che tutto sia raggiungibile. Per un problema con 90 nodi e 40% di
links da tranciare ci mette piu' di 1/2 ora su un athlon 2000.
Non ho messo le mani nel programma e non so come funziona ma mi pare troppo.
Scrivo 100 righe di Python che fanno la stessa cosa, giusto con qualche
opzione in piu' che mi serve, e per lo stesso problema ci mette ~1 minuto.
E non ho dei poteri magici, ne' sono il dio del python.
Se conti che questa roba doveva generare 90000 problemi vedi quanto ho
risparmiato...
 
> > Personalmente suggerirei il perl se devi fare anche dell'i/o binario, ma
> > ripeto e ribadisco che non penso sia una buona idea.
> 
> 	Perl lo sento nominare tantissimo, non ne conosco nulla, ma penso 
> che a questo punto dovro' impararne un pochino...
Per trattare testo e' fantastico, ha moduli per il porco e tutto, ha una
sintassi flessibilissima. Per lavorare su OOP e grossi progetti la vedo
male.
 
-- 
        Giuseppe "Cowo" Corbelli ~\/~ My software: http://cowo.yoda2000.net
          -<! windoze: no need of an hammer to crash it! !>-