che un dict... non conosco i dettagli implementativi, ma (sempre
> in teoria) un dict è un po' uno spreco per quel che ti serve.
>
> ciao
>
> Pietro
>
>
> >
> > Matteo.
> > __
> &g
> > From: vittorio.zucc...@gmail.com
> > Date: Thu, 2 Sep 2010 14:41:10 +0200
> > To: python@lists.python.it
> > Subject: [Python] Algoritmo in CSV
> > Buongiorno,
> > chiedo consiglio su un algoritmo da usare che sia veloce.
> > Anche solo in meta-codi
osco i dettagli implementativi, ma (sempre
in teoria) un dict è un po' uno spreco per quel che ti serve.
ciao
Pietro
>
> Matteo.
>
>
>
> __________________
> From: vittorio.zucc...@gmail.com
> Date: Thu, 2 Sep 2010 14:41:10 +0200
> To: python@lists.python.it
> Subject: [Pyth
ttorio.zucc...@gmail.com
Date: Thu, 2 Sep 2010 14:41:10 +0200
To: python@lists.python.it
Subject: [Python] Algoritmo in CSV
Buongiorno,
chiedo consiglio su un algoritmo da usare che sia veloce.
Anche solo in meta-codice.
Problema:
- carico un CSV con 200 colonne e 2 milioni di righe
- voglio trov
2010/9/4 enrico franchi :
> La teoria, insomma, vince. Il mio discorso era un pelino piu'
> generale. Ovvero che dal momento che la teoria nasconde sempre le
> costanti moltiplicative, ma nella pratica queste possono avere un
> impatto non indifferente, spesso un controllo non guasta.
>
Puo` esse
Il giorno sab, 04/09/2010 alle 10.09 +0200, enrico franchi ha scritto:
> 2010/9/3 Pietro Battiston :
>
> >> Potrebbe essere. La teoria dice che hai ragione tu; in pratica quello
> >> che succede non lo so
> >
> > Cioè sospetti che _in pratica_ un sort possa prendere meno tempo di un
> > max?
>
>
2010/9/3 Pietro Battiston :
>> Potrebbe essere. La teoria dice che hai ragione tu; in pratica quello
>> che succede non lo so
>
> Cioè sospetti che _in pratica_ un sort possa prendere meno tempo di un
> max?
Non lo *sospetto*. Ma *dipende*. Il sort di cui parliamo e' il
timsort, che e' *molto*
ef
Grazie per le risposte. Scusate ma mi sono affidato a risorse "poco
precise" (ho spulciato qua e là in rete). Quando mi sono occupato di
sorting ho dovuto solo scegliere il più veloce e semplice da
reimplementare, perchè la struttura dei dati che avevo mi prendeva più
tempo per sistemare i dati
2010/9/3 Giuseppe Amato :
> Non mi sono mai occupato di max finding quindi non so se è più veloce o
> meno, ho cercato qualcosa, ma con scarsi risultati, mi puoi indicare qualche
> risorsa dove trovare informazioni?
>
In un array non ordinato e` necessario visitare tutti gli elementi una
volta per
Il giorno ven, 03/09/2010 alle 21.44 +0200, Pietro Zambelli ha scritto:
> In data venerdì 3 settembre 2010 21:10:11, Giuseppe Amato ha scritto:
> > >Ma il problema vero è che il sort ha costo più che lineare, mentre il
> > >
> > >max ha costo lineare
> >
> > Non mi sono mai occupato di max finding
Il giorno ven, 03/09/2010 alle 21.10 +0200, Giuseppe Amato ha scritto:
> >Ma il problema vero è che il sort ha costo più che lineare, mentre il
>
> >max ha costo lineare
>
>
>
> Non mi sono mai occupato di max finding quindi non so se è più veloce
> o meno, ho cercato qualcosa, ma con scarsi r
In data venerdì 3 settembre 2010 21:10:11, Giuseppe Amato ha scritto:
> >Ma il problema vero è che il sort ha costo più che lineare, mentre il
> >
> >max ha costo lineare
>
> Non mi sono mai occupato di max finding quindi non so se è più veloce o
> meno, ho cercato qualcosa, ma con scarsi risultat
>Ma il problema vero è che il sort ha costo più che lineare, mentre il
>max ha costo lineare
Non mi sono mai occupato di max finding quindi non so se è più veloce o
meno, ho cercato qualcosa, ma con scarsi risultati, mi puoi indicare qualche
risorsa dove trovare informazioni?
Però mi sono occ
Il 03 settembre 2010 17:50, enrico franchi
ha scritto:
> 2010/9/3 Pietro Battiston :
>> Il giorno ven, 03/09/2010 alle 15.58 +0200, Giuseppe Amato ha scritto:
>>> Ti conviene ordinare e prendere l'ultimo per ogni colonna utlizzando
>>> sort(cmp) sulle colonne. L'algoritmo di sort è già ottimizzato
Il giorno ven, 03/09/2010 alle 17.50 +0200, enrico franchi ha scritto:
> 2010/9/3 Pietro Battiston :
> > Il giorno ven, 03/09/2010 alle 15.58 +0200, Giuseppe Amato ha scritto:
> >> Ti conviene ordinare e prendere l'ultimo per ogni colonna utlizzando
> >> sort(cmp) sulle colonne. L'algoritmo di sort
2010/9/3 Giuseppe Amato :
> Ti conviene ordinare e prendere l'ultimo per ogni colonna utlizzando
> sort(cmp) sulle colonne. L'algoritmo di sort è già ottimizzato rispetto
> ai confronti che hai previsto tu. Se hai bisogno anche dell'indice del
> campo butti tutto in un dizionario del tipo {:} però
2010/9/3 Pietro Battiston :
> Il giorno ven, 03/09/2010 alle 15.58 +0200, Giuseppe Amato ha scritto:
>> Ti conviene ordinare e prendere l'ultimo per ogni colonna utlizzando
>> sort(cmp) sulle colonne. L'algoritmo di sort è già ottimizzato rispetto
>> ai confronti che hai previsto tu. Se hai bisogno
Il giorno ven, 03/09/2010 alle 15.58 +0200, Giuseppe Amato ha scritto:
> Ti conviene ordinare e prendere l'ultimo per ogni colonna utlizzando
> sort(cmp) sulle colonne. L'algoritmo di sort è già ottimizzato rispetto
> ai confronti che hai previsto tu. Se hai bisogno anche dell'indice del
> campo
Ti conviene ordinare e prendere l'ultimo per ogni colonna utlizzando
sort(cmp) sulle colonne. L'algoritmo di sort è già ottimizzato rispetto
ai confronti che hai previsto tu. Se hai bisogno anche dell'indice del
campo butti tutto in un dizionario del tipo {:} però devi
fare attenzione alle dupl
2010/9/3 Marco Mariani :
> No, se in postgres crei un indice funzionale su LENGTH(colonna), una volta
> creata la tabella e' sufficiente un index scan per recuperare i valori con
> lunghezza massima.
>
> Chiaramente, 200 colonne fanno 200 indici con milioni di righe :")
>
Infatti il consiglio era
Il cvs lo prepari tu in una parte del tuo progetto? Forse sarebbe
meglio mettere tutto in un database che conserva i dati in maniera
piu` furba del cvs come diceva Nicola, pero` farlo solo per vedere i
massimi non serve a niente perche` dovresti comunque leggerti tutti i
righe*colonne dati
2010/9/2 Vittorio Zuccala' :
> Ecco: il mio problema è che vengono effettuati 200*2.000.000 di IF e la cosa
> non mi piace molto.
> Qualcuno ha un consiglio per ottimizzare?
>
Se un array non e` ordinato trovare il massimo costa O(n) in tempo e
O(1) in spazio. Le colonne del tuo file immagino non
On 02/09/2010 14:41, Vittorio Zuccala' wrote:
> Buongiorno,
> chiedo consiglio su un algoritmo da usare che sia veloce.
> Anche solo in meta-codice.
>
> Problema:
> - carico un CSV con 200 colonne e 2 milioni di righe
> - voglio trovare la lunghezza maggiore per ogni campo
>
> Meta-codice
> * apri
Il giorno gio, 02/09/2010 alle 15.22 +0200, Daniele Varrazzo ha scritto:
> On Thu, 2 Sep 2010 14:41:10 +0200, "Vittorio Zuccala'"
> wrote:
> > Buongiorno,
> > chiedo consiglio su un algoritmo da usare che sia veloce.
> > Anche solo in meta-codice.
> >
> > Problema:
> > - carico un CSV con 200 col
Vittorio Zuccala' wrote:
> Problema:
> - carico un CSV con 200 colonne e 2 milioni di righe
> - voglio trovare la lunghezza maggiore per ogni campo
> [snip]
> Qualcuno ha un consiglio per ottimizzare?
Butta tutto in un database e fai fare il lavoro sporco a lui. :-)
--
Nicola Larosa - http://www
Il giorno gio, 02/09/2010 alle 14.41 +0200, Vittorio Zuccala' ha
scritto:
> Buongiorno,
> chiedo consiglio su un algoritmo da usare che sia veloce.
> Anche solo in meta-codice.
>
> Problema:
> - carico un CSV con 200 colonne e 2 milioni di righe
> - voglio trovare la lunghezza maggiore per ogni ca
On Thu, 2 Sep 2010 14:41:10 +0200, "Vittorio Zuccala'"
wrote:
> Buongiorno,
> chiedo consiglio su un algoritmo da usare che sia veloce.
> Anche solo in meta-codice.
>
> Problema:
> - carico un CSV con 200 colonne e 2 milioni di righe
> - voglio trovare la lunghezza maggiore per ogni campo
> Ecco
Buongiorno,
chiedo consiglio su un algoritmo da usare che sia veloce.
Anche solo in meta-codice.
Problema:
- carico un CSV con 200 colonne e 2 milioni di righe
- voglio trovare la lunghezza maggiore per ogni campo
Meta-codice
* apri file csv
* crea un oggetto csv_reader
* crea un array "lunghezza
28 matches
Mail list logo
