Uhm... sì è vero: in questo caso un set() va meglio di un dict().
Comunque, credo anch'io che l'uso di "in" sia meno efficiente di un confronto
"<".
Però, in sé l'idea era intrigante:
Infine, se si conoscesse la massima lunghezza possibile si potrebbe sostiture
il dict/set con un sub-array.
Anc
> > 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-codice.
> > Problema:
> > - carico un CSV con 20
Il giorno lun, 06/09/2010 alle 22.04 +0200, Matteo Mattsteel Vitturi ha
scritto:
> Io proverei un approccio alternativo e forse più Pythonico...
> Considerando la singola colonna mi aspetto che la "varietà" delle
> lunghezze non sia molto ampia.
> Memorizzerei quindi in un dict tali lunghezze usan
Io proverei un approccio alternativo e forse più Pythonico...
Considerando la singola colonna mi aspetto che la "varietà" delle lunghezze non
sia molto ampia.
Memorizzerei quindi in un dict tali lunghezze usando come "chiave"
proprio la lunghezza, in questo modo non faccio alcun confronto ma
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
27 matches
Mail list logo
