Newsgroup: it.comp.lang.c++
Titolo: problema con array troppo lungo

ciao a tutti
ho un problema con un array...
ho un array in un ciclo for ma le iterazioni che mi servono sono piů
di quelle massimme ammesse per un array che nel mio computer sono
circa 23000. Quello che vi chiedo č:
1)Come faccio a far continuare i calcoli oltre questo limite di
iterazioni?
2)Posso usare un altro array che mi riparti da dove si č fermato il
primo?Ma come faccio?
Spero di trovare quelcuno che mi risolva il problema....comunque
Grazie.
Ciao


Ma 23000 č l'allocazione massima di un array nello stack?!?
O le iterazioni sono piů degli elemnti dell'array?!?
Penso che sia il primo caso...beh se cosě, sappi che č normale perchč lo
stack dedicato al prog č piccolo, se vuoi fare una cosa in grande devi usare
la heap, che potenzialmente č limitata alla dimensione della RAM e del tuo
hard disk!
--------------------------------
Inviato via 
http://usenet.libero.it

 2)Posso usare un altro array che mi riparti da dove si è fermato il


 ho un problema con un array...
Perché non ci posti la parte di codice dove dichiari l'array e poi anche il
loop, poi ci dici che computer+S.O. stai usando e che compilatore, cosě
forse abbiamo piů elementi per aiutarti.
Pensa che con questo stupido programma su un x86 ho appena allocato un
milione di numeri interi in un std::vector, qualsiasi computer dal 386 in
poi (a patto d'avere memoria a sufficienza) č in grado di farlo.
#include <iostream>
#include <vector>
using namespace std;
int main(int argc, char* argv[])
{
        vector<int> prova;
        unsigned int i;
        cout << "max size = " << prova.max_size() << endl;
        cout << "sto allocando un milione di interi...";
        for (i=0;i<1000000;++i) prova.push_back(i);
        cout << "fatto!\n";
        cout << "Allocati " << prova.size() << " numeri.\n";
        return 0;
}
Se al posto d'usare un vettore usi un array, definendolo con
int* prova=new int[1000000];
il programma va un pň cambiato...
#include <iostream>
#include <vector>
#define MAX 1000000
using namespace std;
int main(int argc, char* argv[])
{
        int* prova=new int[MAX];
        unsigned int i;
        for (i=0;i<MAX;++i) prova[i]=i;
        cout << "fatto!\n";
        cout << "Allocati " << MAX*sizeof(prova) << " bytes.\n";
        delete [] prova;
        char c;
        cin.get(c);
        return 0;
}
comunque per un milione di interi sono meno di 4Mb di memoria, oggi
praticamente tutti abbiamo sistemi con piů di 64Mb di memoria RAM, a meno
chie il tuo... perň dacci piů coordinate, computer, S.O. compilatore...
CIAO!
Ciao.

circa 23000. Quello che vi chiedo è:
Se ti riferisci al codice di cui parte hai inserito nel tuo mess precedente,
lo devi solo ottimizzare meglio. Nel tuo thread precedente almeno su un
aspetto ti ho indicato come.
-- 
Saluti,
Andrea (uno dei tanti)
mailto: 
acola...@bigfoot.com

...

ecco la parte di codice con le dichiarazione degli array
Non č un problema di memoria fisica...uso un PIII con 256MB di ram, il
compilatore č il dev-c++
.....
.......
const int i=23500;
double t[i];
double v[i];
double a[i];
double y[i];
double tTilde[i];
double aTilde[i];
double vTilde[i];
double yTilde[i];
double Tempo[i];
double va[i];
double ya[i];
........
........
for (int j=1; j<=i; j++)
        {
                double tempo=j*dt;
                t[j]=t[j]+1;
 
                Tempo[j]=j*dt;                
                a[j]=g-(k1*v[j-1])/m;
                v[j]=v[j-1]+a[j-1]*dt;
                y[j]=y[j-1]+v[j-1]*dt+a[j-1]*(dt*dt)/2;              
                tTilde[j]=Tempo[j]/tStar;               
                vTilde[j]=(tStar*v[j-1])/yStar;
 
                yTilde[j]=y[j-1]/yStar;
                aTilde[j]=1-vTilde[j];
 
                va[j]=Vlim*(1-exp(-tempo/Thao));
                ya[j]=Thao*Vlim*(exp(-tempo/Thao)-1)+tempo*Vlim;
                erroreY=(ya[j-1])/yStar-yTilde[j];//(y[j-1];
                erroreV=((tStar*va[j-1])/yStar)-((tStar*v[j-1])/yStar);
                 myOutputFile << setprecision(8);
                myOutputFile<<setw(8)<<"tTilde["<<j<<"] "<<setw(10)<<"
   vTilde["<<j<<"] "<<setw(10)<<"  yTilde["<<j<<"] "<<setw(10)<<"   
aTilde["<<j<<"] "<<
                setw(15)<<"va["<<j<<"] "<<setw(15)<<"ya["<<j<<"]
"<<setw(15)<<"a["<<j<<"] "<<setw(15)<<"va-vn
"<<setw(15)<<"ya-yn"<<endl;
                myOutputFile<<setw(10)<< (tTilde[j]-(dt/tStar))*tStar
<<setw(14)<< vTilde[j] <<setw(15)<< (yTilde[j])*yStar <<setw(18)<<
aTilde[j] <<setw(20)<< va[j-1] <<
                setw(18)<< (ya[j-1])/*/yStar*/ <<setw(18)<<
aTilde[j]*g <<setw(18)<< ((tStar*va[j-1])/yStar)-vTilde[j-1]
<<setw(18)<< erroreY <<endl;
 
         }
la massima dimensione che riesco a dare all'array con indice i č
quella circa 23500 forse qualcosa di piů, se do una dimensione
maggiore mi da errore e il nemmeno viene compilato il programma. A me
servono piů di 23500 iterazioni, servirebbe un array di dimensione
50000 ma non ci riesco con uno solo, potrei spezzarlo in due ma come
si fa?
grazie per le risposte che mi avete  dato fino ad ora..spero di essere
stato piů chiaro anche con il listato del programma...grazie

 stato piů chiaro anche con il listato del programma...grazie
Io con un computer simile al tuo ho appena calcolato il tuo algoritmo con
500000 iterazioni!!
E avrei potuto fare anche di piů!
Per la cronaca il tuo listato con il Borland mi chiedeva se ero impazzito a
saturare lo stack con tutta quella roba e si rifiutava (come il povero
Dev-C++) di farlo!!
Tutto quel popň di roba lo devi allocare nello heap e non nello stack,
adatta il tuo listato come segue e verifica tu stesso la potenza del tuo
computer!!
P.S. Stai attento a una cosa... Il tuo programma non avrebbe funzionato, un
array di n elementi, es int a[n] riserva memoria da a[0] ad a[n-1], quindi
avresti ottenuto un'errore di violazione d'accesso o un fault segmentation.
Ecco perché se vuoi allocare 23500 elementi o 500000 devi usare int a[23501]
o int a[500001] ammesso che sia possibile, oppure int* a=new int[500001], e
poi delete [] a;
Buona computazione!
Paolo Ferraresi.
        const int i=500000,pi=i+1;
        double erroreY,erroreV;
        double* t=new double[pi];
        double* v=new double[pi];
        double* a=new double[pi];
        double* y=new double[pi];
        double* tTilde=new double[pi];
        double* aTilde=new double[pi];
        double* vTilde=new double[pi];
        double* yTilde=new double[pi];
        double* Tempo=new double[pi];
        double* va=new double[pi];
        double* ya=new double[pi];
        ofstream myOutputFile("out.txt");




         }
        delete [] t;
        delete [] v;
        delete [] a;
        delete [] y;
        delete [] tTilde;
        delete [] aTilde;
        delete [] vTilde;
        delete [] yTilde;
        delete [] Tempo;
        delete [] va;
        delete [] ya;

 Per la cronaca il tuo listato con il Borland mi chiedeva se ero impazzito
a
Ehm... il Borland col tuo listato... ho troppi bit per la testa e l'italiano
"somatizza" !!
Un'altra soluzione poteva essere benissimo l'utilizzo di std:vector<double>
!!
Sicuramente con vector non avresti avuto nessun problema in quanto delegavi
a lui l'allocazione e la gestione della memoria!! Forse a scapito di un pò
d'efficienza però... QUASI sempre ci sono buoni motivi per usare i
contenitori standard... I vantaggi sono un codice più robusto e flessibile,
e minor costo tuo nello scrivere codice!
Per questo motivo non posso che incoraggiarti al loro uso! Anche se poi
ciascuno scrive il proprio software come crede, e ci mancherebbe!
F.P.

 computer!!
Sono d'accordo con te, anche se dopo aver suggerito di riporre grossi
oggetti nell'heap piuttosto che nello stack qualcuno si e' lamentato del
fatto che new e' complesso da usare e il programma aveva difficolta' ad
allocarlo in memoria (ci metteva piu' tempo). Adesso arrivi tu e mi dici il
contrario (con qualche sfumatura diversa). Mi confondete le idee.
Ciao
Emanuele

 Emanuele
Ciao!
P.S. (è un consiglio)
Preoccupati meno della velocità del tuo codice, considera più importante la
potenza, la robustezza del codice e la flessibilità. Poi se ti trovi davanti
a un problema reale di performances puoi analizzarlo... tante volte limi un
microsecondo dove non serve e incasini il tuo codice, poi perdi un sacco di
tempo in passaggi come input da tastiera e letture file...