[C++] Caricare dati float da txt

[Vincenzo1968]

Originariamente inviato da cionci

Chiaro, se tu dovessi controllare un centinaio di file diversi, ma se ne dovessi controllare uno da 1000 righe ?

In quel caso meglio Python(o C# o Java).

[Vincenzo1968]

Originariamente inviato da Mattiatn

Pensavo anche io inizialmente che un programma così non lungo (data la mia inesperienza) fosse estremamente lento, ma invece è molto veloce, e questo è ben accetto sopratutto in previsioni di applicazioni real-time.
...

Questo per ricordare che Mattia ha espresso le sue preferenze riguardo alla velocità del programma

[marco.r]

Originariamente inviato da Vincenzo1968

Il che vuol dire che, se devo processare un centinaio di file, il programma in Python impiega circa 56 minuti, quello di Cionci circa 45 e il mio 15. Giusto?

Se il programma non fa che caricare in memoria, allora si' . Bisogna vedere cos'altro bisogna farci. Se il tempo di elaborazione e' dominante e il collo di bottiglia non e' nel caricamento, e' un'ottimizzazione inutile che comporta codice piu' complesso piu' difficile da mantenere. Ad esempio se come sembra deve macinare i dati in tempo reale, magari vorra' elaborare una riga alla volta. Alla macchina a stati bisogna cambiare un po' di cose, al codice "semplice" basta riutilizzare il solo ciclo interno (o in python usare i generatori per risultati ancora piu' carini).
Se il collo di bottiglia non e' nella lettura del file secondo me quelle quattrocento e passa linee di codice per leggere dei float da file sono un tantino overkill.

[Vincenzo1968]

Originariamente inviato da marco.r

Se il programma non fa che caricare in memoria, allora si' . Bisogna vedere cos'altro bisogna farci. Se il tempo di elaborazione e' dominante e il collo di bottiglia non e' nel caricamento, e' un'ottimizzazione inutile che comporta codice piu' complesso piu' difficile da mantenere. Ad esempio se come sembra deve macinare i dati in tempo reale, magari vorra' elaborare una riga alla volta. Alla macchina a stati bisogna cambiare un po' di cose, al codice "semplice" basta riutilizzare il solo ciclo interno (o in python usare i generatori per risultati ancora piu' carini).
Se il collo di bottiglia non e' nella lettura del file secondo me quelle quattrocento e passa linee di codice per leggere dei float da file sono un tantino overkill.

Che cos'altro si potrebbe farci? Un esempio che mi viene in mente è questo:
supponiamo che il file contenga i dati per gestire delle statistiche. Per esempio, le colonne potrebbero rappresentare i livelli di reddito e le righe gruppi di età. Il programma deve caricare in memoria la matrice e trovare la sottomatrice rettangolare di somma massima ( Contest 5 ).
Anche nei casi in cui bisogna eleborare una riga per volta, non mi spaventa l'idea di dover apportare qualche modifica all'automa. Ti assicuro che anche in questo caso le prestazioni rimarrebbero migliori.
Se m'è venuta la fissazione per la velocità di esecuzione, è perchè mi sono scassato i cabasisi, in tanti anni di lavoro, a sentire gente che si lamenta della lentezza dei programmi. Già si lamenterebbero se propronessi un programma che compie il lavoro in un quarto d'ora. Figurati se ne proponessi uno che fa lo stesso lavoro in tre quarti d'ora

Ciao

[cionci]

Originariamente inviato da Vincenzo1968

In quel caso meglio Python(o C# o Java).

Ma mi immagino che lo debba inserire in un'applicazione già fatta in C++. Quindi queste altre scelte non sono possibili.

Bello il tuo codice marco.r, un po' troppo "insensibile" agli errori di formato, ma bello
In sostanza dipende tutto dalla quantità di dati letti in input. Se fossero centinaia di MB è chiaro che un pensierino alle prestazioni bisogna farlo. Se sono pochi MB assolutamente no.
Imho bisogna, sempre, non solo in questo caso, tenere conto del giusto compromesso manutenibilità/leggibilità e prestazioni in base all'uso che ne dobbiamo fare. E ripeto: se quella parte fa da collo di bottiglia lo vedremo successivamente con un profiler: "Premature optimization is the root of all evil" (cit. Donald Knuth)

Senza contare magari arrivando all'implementazione si vede che il collo di bottiglia sta nell'accesso ai dati caricati e non nel caricamento, e la cosa sarebbe davvero comica

[Vincenzo1968]

Originariamente inviato da cionci

Ma mi immagino che lo debba inserire in un'applicazione già fatta in C++. Quindi queste altre scelte non sono possibili.

Bello il tuo codice marco.r, un po' troppo "insensibile" agli errori di formato, ma bello
In sostanza dipende tutto dalla quantità di dati letti in input. Se fossero centinaia di MB è chiaro che un pensierino alle prestazioni bisogna farlo. Se sono pochi MB assolutamente no.
Imho bisogna, sempre, non solo in questo caso, tenere conto del giusto compromesso manutenibilità/leggibilità e prestazioni in base all'uso che ne dobbiamo fare. E ripeto: se quella parte fa da collo di bottiglia lo vedremo successivamente con un profiler: "Premature optimization is the root of all evil" (cit. Donald Knuth)

Senza contare magari arrivando all'implementazione si vede che il collo di bottiglia sta nell'accesso ai dati caricati e non nel caricamento, e la cosa sarebbe davvero comica

Ciao Cionci,

si hai perfettamente ragione. Intendevo semplicemente dire che, se l'input è di dimensioni ridotte, va bene qualunque linguaggio e qualunque algoritmo. Per esempio, nel caso dell'ordinamento, andrebbe bene e, anzi forse sarebbe meglio, utilizzare il bubble sort anziché quicksort.
Riguardo alla frase di Knuth(che considero un dio nel campo della programmazione) ti vorrei far notare una cosa:

Premature optimization is the root of all evil

I tre volumi di The Art of Computer Programming sono un monumento alla ricerca delle massime prestazioni dei programmi.

Ciao

P.S.
Proprio Knuth è uno dei pionieri nel campo del parsing e della teoria degli automi. Non vedo l'ora che escano gli altri due volumi della serie e in particolar modo il quinto: Syntactic Algorithms che sarà interamente dedicato all'analisi lessicale(leggi automi a stati ) e alle tecniche di parsing.

[cionci]

Originariamente inviato da Vincenzo1968

Premature optimization is the root of all evil

Appunto. Ma sono perfettamente d'accordo. Nessuno ha detto che non bisogna ottimizzare, ma bisogna farlo quando abbiamo un contesto di lavoro tipo e una prova del fatto che quella parte del codice vada ottimizzata.
Imho usare il tuo codice, per carità bello e prestante, le macchine a stati l'ho usate spesso in passato, è come sparare ad una mosca con un cannone se non lo applichiamo in un contesto preciso: cioè un'enorme quantità di dati.
Tra l'altro le macchine a stati si trovano perfettamente a proprio agio in un contesto Object Oriented: vedi lo State pattern. E fortunatamente sparisce quello switch

[Vincenzo1968]

Originariamente inviato da cionci

Appunto. Ma sono perfettamente d'accordo. Nessuno ha detto che non bisogna ottimizzare, ma bisogna farlo quando abbiamo un contesto di lavoro tipo e una prova del fatto che quella parte del codice vada ottimizzata.
Imho usare il tuo codice, per carità bello e prestante, le macchine a stati l'ho usate spesso in passato, è come sparare ad una mosca con un cannone se non lo applichiamo in un contesto preciso: cioè un'enorme quantità di dati.

Ma dovendo sviluppare un'applicazione non su commissione ma, diciamo, per il mercato, quale criterio adotteresti?
Ti baseresti sul fatto che il programma verrà probabilmente utilizzato su input di piccole dimensioni o cercheresti di ottimizzarlo al massimo?

P.S.
Che cabaso vuol dire 'imho'?

[cionci]

Originariamente inviato da Vincenzo1968

Ma dovendo sviluppare un'applicazione non su commissione ma, diciamo, per il mercato, quale criterio adotteresti?
Ti baseresti sul fatto che il programma verrà probabilmente utilizzato su input di piccole dimensioni o cercheresti di ottimizzarlo al massimo?

P.S.
Che cabaso vuol dire 'imho'?

Imho = in my humble opinion

Come già detto dipende dal contesto e dal programma. Bisognerebbe stabilire un testbed tipo ed uno straordinario e vedere se ci sono problemi di prestazioni. Se ci sono prendo un profiler e vedo qual'è la parte del codice che mi fa da collo di bottiglia. A quel punto comincio ad ottimizzarla. E così avanti fino a quando non ottengo prestazioni decenti.

[Vincenzo1968]

Originariamente inviato da cionci

Imho = in my humble opinion

Come già detto dipende dal contesto e dal programma. Bisognerebbe stabilire un testbed tipo ed uno straordinario e vedere se ci sono problemi di prestazioni. Se ci sono prendo un profiler e vedo qual'è la parte del codice che mi fa da collo di bottiglia. A quel punto comincio ad ottimizzarla. E così avanti fino a quando non ottengo prestazioni decenti.

M'hai fatto venire la curiosità con questa cosa del profiler.
Propongo una specie di contest. Realizziamo un programma per un ipotetico istituto di statistica. Il programma dovrà leggere una serie di file di testo(ogni file potrebbe rappresentare, per esempio, i dati di ognuno dei comuni italiani) che contengono i dati raggruppati per livelli di reddito(le colonne) e gruppi di età(le righe).
Bisogna leggere in memoria la matrice e calcolando la media, sottrarre quest'ultima da ogni elemento della matrice ottenendo una seconda matrice con valori e positivi e negativi; altrimenti, con tutti i valori positivi, la soluzione risulterebbe banale: la somma degli elementi dell'intero array. È la stessa tecnica che si utilizza quando bisogna ricercare la brightest area di una bitmap.
Da questa seconda matrice si calcolino le sottomatrici rettangolari di somma minima e massima.

Penso che sia una cosa di interesse generale vedere come utilizzare in pratica un profiler per ottimizzare le prestazioni di un programma.

[banryu79]

Bella idea permun contest Vincenzo, potresti aprire una nuova discussione e intitolarla "Contest 6: ..." così da continuare la tradizione iniziata con GugoXX

[Vincenzo1968]

Originariamente inviato da banryu79

Bella idea permun contest Vincenzo, potresti aprire una nuova discussione e intitolarla "Contest 6: ..." così da continuare la tradizione iniziata con GugoXX

Ciao Banryu,
grazie.

A proposito, che fine ha fatto Gugo? È ancora in ferie? A quando il prossimo contest?

[banryu79]

Originariamente inviato da Vincenzo1968

Ciao Banryu,
grazie.

A proposito, che fine ha fatto Gugo? È ancora in ferie? A quando il prossimo contest?

Non ne ho idea, è da un po' che non lo leggo più sul Forum, in effetti

[marco.r]

Originariamente inviato da cionci

Ma mi immagino che lo debba inserire in un'applicazione già fatta in C++. Quindi queste altre scelte non sono possibili.

Bello il tuo codice marco.r, un po' troppo "insensibile" agli errori di formato, ma bello

Hai, ragione, ma non ci vuole molto a gestirli, basta abilitare le eccezioni, e decidere come gestirle. Se lo stream trova qualcosa che non e' un float viene lanciata un'eccezione. Quel che manca e' "solo" decidere dove raccoglierla. Trattandosi di una lettura di un laser probabilmente si tratta di una sequenza temporale, in tal caso basta raccogliere subito l'eccezione e morta li'.In caso contrario si puo' farlo nel loop piu' esterno.
Ad esempio si puo' fare qualcosa del tipo

void read_matrix( const string& filename, vector< vector<float> >& matrix )
{
    string s;
    ifstream input( filename.c_str() );
    while ( getline( input, s ) )
    {
        try 
        {
            matrix.push_back( vector<float>() );
            istringstream is(s);
            is.exceptions( ifstream::badbit | ifstream::failbit );
            copy( istream_iterator<float>( is ), 
                  istream_iterator<float>(), 
                  back_inserter( matrix.back() ) );
            if ( matrix.back().size() != 365 )
                matrix.pop_back();
        } catch( ifstream::failure e )
        { /* Ignore wrong line */ }
    }
}

In questo caso eliminiamo anche le righe che non hanno la lunghezza giusta e siamo a posto. Un po' meno chiaro di prima ma ancora abbastanza leggibile.

[Vincenzo1968]

Originariamente inviato da marco.r

Hai, ragione, ma non ci vuole molto a gestirli, basta abilitare le eccezioni, e decidere come gestirle. Se lo stream trova qualcosa che non e' un float viene lanciata un'eccezione. Quel che manca e' "solo" decidere dove raccoglierla. Trattandosi di una lettura di un laser probabilmente si tratta di una sequenza temporale, in tal caso basta raccogliere subito l'eccezione e morta li'.In caso contrario si puo' farlo nel loop piu' esterno.
Ad esempio si puo' fare qualcosa del tipo

void read_matrix( const string& filename, vector< vector<float> >& matrix )
{
    string s;
    ifstream input( filename.c_str() );
    while ( getline( input, s ) )
    {
        try 
        {
            matrix.push_back( vector<float>() );
            istringstream is(s);
            is.exceptions( ifstream::badbit | ifstream::failbit );
            copy( istream_iterator<float>( is ), 
                  istream_iterator<float>(), 
                  back_inserter( matrix.back() ) );
            if ( matrix.back().size() != 365 )
                matrix.pop_back();
        } catch( ifstream::failure e )
        { /* Ignore wrong line */ }
    }
}

In questo caso eliminiamo anche le righe che non hanno la lunghezza giusta e siamo a posto. Un po' meno chiaro di prima ma ancora abbastanza leggibile.

E la gestione delle eccezioni, con i blocchi try-catch è, tu m'insegni, pesante dal punto di vista delle prestazioni. Giusto?

[Vincenzo1968]

Originariamente inviato da Vincenzo1968

E la gestione delle eccezioni, con i blocchi try-catch è, tu m'insegni, pesante dal punto di vista delle prestazioni. Giusto?

Sbagliato!
Ho provato le due versioni(con e senza gestione delle eccezioni) e impiegano lo stesso tempo(circa 98 secondi).
Ma guarda cosa succede con il seguente file:

2.025e+12  3.125e-15   2.125e-5
1.0125e-10	2.ciao     5.12548e-12

Nota nella seconda riga, seconda colonna, il 'numero' 2.ciao

Il tuo programma non segnala l'errore e la seguente riga di codice:

    cout << "v[1][1] -> " << matrix[1][1] << endl;

da questo output:

v[1][1] -> 2

[cionci]

E' normale per come gestisce la conversione lo stream, ma l'errore dovrebbe appare sicuramente sull'elemento successivo.

[Vincenzo1968]

Originariamente inviato da cionci

E' normale per come gestisce la conversione lo stream, ma l'errore dovrebbe appare sicuramente sull'elemento successivo.

No, non segnala nessunissimo errore.

Con quest'altro file:

2.025e+12  3.125e-15   2.125e-5
1.0125e-10	ciao     5.12548e-12

il programma va, semplicemente, in crash.

[Vincenzo1968]

#include <iostream>
#include <fstream>
#include <sstream>
#include <vector>
#include <ctime>

using namespace std;

void read_matrix1( const string& filename, vector< vector<float> >& matrix )
{
    string s;
    ifstream input( filename.c_str() );
    while ( getline( input, s ) )
    {
        matrix.push_back( vector<float>() );
        istringstream is(s);
        copy( istream_iterator<float>( is ), 
              istream_iterator<float>(), 
              back_inserter( matrix.back() ) );
    }
}

void read_matrix2( const string& filename, vector< vector<float> >& matrix )
{
    string s;
    ifstream input( filename.c_str() );
    while ( getline( input, s ) )
    {
        try 
        {
            matrix.push_back( vector<float>() );
            istringstream is(s);
            is.exceptions( ifstream::badbit | ifstream::failbit );
            copy( istream_iterator<float>( is ), 
                  istream_iterator<float>(), 
                  back_inserter( matrix.back() ) );
            if ( matrix.back().size() != 365 )
                matrix.pop_back();
        } catch( ifstream::failure e )
        { /* Ignore wrong line */ }
    }
}


int main()
{
    clock_t c_start, c_end;

    c_start = clock();

	vector< vector<float> > matrix;
	read_matrix2("C:\\Temp\\test1.txt", matrix);

    cout << endl;
    cout << "v[0][0] -> " << matrix[0][0] << endl;
    cout << "v[1][1] -> " << matrix[1][1] << endl;

    c_end = clock();

    printf("\nTempo impiegato -> %5.5f secondi\n", (double)(c_end - c_start) / CLOCKS_PER_SEC);

    return 0;
}

[marco.r]

eh, dovrei provare il codice prima di postarlo , soprattutto sulle cose che e' un po' che non guardo .
C'e' un errore, anzi due.
Il primo e' che quando raccolgo l'eccezione dovrei eliminare l'array parzialmente letto:

catch( ifstream::failure e )
        { matrix.pop_back(); }

L'altro errore e' che mi ero dimenticato che comunque istringstream quando si "ferma" segnala un failbit e non un eofbit ( ), per cui lancia ogni volta un'eccezione.
Purtroppo l'unica e cambiare un po' il codice e passare ad una lettura "normale"

void read_matrix( const string& filename, vector< vector<float> >& matrix, int line_size )
{
    string s;
    ifstream input( filename.c_str() );
    while ( getline( input, s ) )
    {
        istringstream is(s);
        try 
        {
            matrix.push_back( vector<float>(line_size) );
            is.exceptions( ios::badbit | ios::failbit );
            for ( int i=0 ; i<line_size ; ++i )
            {
                is >> matrix.back()[i];
            }
            is.exceptions( ios::goodbit );
            // Be sure that there isn't anything left on the line...
            string s;
            if ( is >> s )
            {
                matrix.pop_back();
            }
        } catch( const ifstream::failure& e )
        { 
            matrix.pop_back(); 
        }
    }
}