Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 16
  1. #1
    Utente di HTML.it
    Registrato dal
    Jul 2002
    Messaggi
    655

    [pascal]Differenza array di array e matrici

    Che differenza c'è tra array di array e matrici?

  2. #2
    nessuna xkè sia array di array e matrice sono entrambi bidimensionali!!!!

  3. #3
    Utente di HTML.it
    Registrato dal
    Jul 2002
    Messaggi
    655
    quindi scrivere : array[1..4] of array[1..4] of integer o array[1..4,1..4] of integer è la stessa cosa?

  4. #4
    Sai nel primo modo in cui dici te nn ho mai provato, il secondo è giusto, ma forse anke il primo, cmq se vuoi essere sicuro fai una cosa tipo questa:

    codice:
    program esempio;
    Type
       vettore=array[1..4] of integer;
       matrice=array[1..4] of vettore;
    
    Var mat:matrice;
    begin
    ....
    ....
    end.
    Ciao

  5. #5
    Moderatore di Programmazione L'avatar di alka
    Registrato dal
    Oct 2001
    residenza
    Reggio Emilia
    Messaggi
    24,310

    Re: [pascal]Differenza array di array e matrici

    Originariamente inviato da kadorit
    Che differenza c'è tra array di array e matrici?
    A livello logico, direi che non vi è alcuna differenza, ma non sono certo che i compilatori trattino i tipi allo stesso modo.

    Ciao!
    MARCO BREVEGLIERI
    Software and Web Developer, Teacher and Consultant

    Home | Blog | Delphi Podcast | Twitch | Altro...

  6. #6
    teoricamente il compilatore potrebbe memorizzare le due cose in modo diverso. infatti se il compilatore normalmente memorizza le matrici in base alle righe, nel caso in cui si faccia un array di array credo che vengano memorizzate in colonne. A livello logico nn c'è nessun problema ma il problema arriva dal sistema operativo. per farla breve cmq il problema sta ne fatto che se la matrice viene memorizzata in un modo ma si fa accesso ai dati nel modo opposto, il sistema operativo genera un "errore" chiamato page fault che obbliga il sistema operativo a caricare una nuova pagina di memoria, nel caso in cui la memoria nn sia piena, o prendere una pagina in memoria e metterla su disco fisso per fare spazio a quella contenente i valori della matrice nel caso in cui la memoria sia piena.
    forse nn mi sono spiegato molto bene ma il concetto è che se si memorizzano i dati nello stesso modo in cui vengono trattati dal compilatore ci dovrebbe essere un aumento delle prestazioni del programma perchè la cpu viene usata solo per operazioni che sono affini al programma stesso.

  7. #7
    Utente di HTML.it
    Registrato dal
    Jul 2002
    Messaggi
    655
    Non riesco a capire perchè la matrice occupi più spazio e cosa centra la memoria virtuale

  8. #8
    Moderatore di Programmazione L'avatar di alka
    Registrato dal
    Oct 2001
    residenza
    Reggio Emilia
    Messaggi
    24,310
    Originariamente inviato da gogetassj4dp
    teoricamente il compilatore potrebbe memorizzare le due cose in modo diverso.
    E' possibile, ma non vedo perchè mai dovrebbe farlo.
    Originariamente inviato da gogetassj4dp
    infatti se il compilatore normalmente memorizza le matrici in base alle righe, nel caso in cui si faccia un array di array credo che vengano memorizzate in colonne.
    Il compilatore non memorizza matrici...al massimo genera un programma in grado di farlo, ed in ogni caso non esiste un "in base alle righe" o "in base alle colonne", poichè si tratta appunto di una matrice e quindi sono necessarie sempre due dimensioni per localizzare un elemento. Se intendi l'ordine con cui si specificano gli indici di riga e colonna, il discorso è lo stesso: il primo vettore rappresenta le colonne, il secondo le righe, o viceversa, fatto sta che lo spazio occupato è lo stesso.

    Con "differenza a livello di compilatore" non mi riferivo all'occupazione di memoria che ovviamente è uguale, ma piuttosto alla diversa generazione del file eseguibile che utilizza istruzioni differenti per accedere ai dati, magari meno ottimizzate nel caso di "array di array" rispetto alla matrice.

    Originariamente inviato da gogetassj4dp
    A livello logico nn c'è nessun problema ma il problema arriva dal sistema operativo.
    Il problema non sussiste ne a livello di compilatore ne a livello di sistema operativo; l'unico sospetto - che potrebbe essere magari falso comunque - è che il compilatore generi un eseguibile "meno ottimizzato" nell'accesso utilizzando l'array di array al posto della matrice. In ogni caso, sceglierei comunque una matrice visto che in Pascal esistono gli array multidimensionali...quindi perchè non utilizzarli?

    Originariamente inviato da gogetassj4dp
    per farla breve cmq il problema sta ne fatto che se la matrice viene memorizzata in un modo ma si fa accesso ai dati nel modo opposto, il sistema operativo genera un "errore" chiamato page fault che obbliga il sistema operativo a caricare una nuova pagina di memoria, nel caso in cui la memoria nn sia piena, o prendere una pagina in memoria e metterla su disco fisso per fare spazio a quella contenente i valori della matrice nel caso in cui la memoria sia piena.
    Credo che tu abbia fatto un bel po' di confusione; se gli indici vengono scambiati e si eccedono i valori massimi previsti dalla dimensione della matrice (o dell'array di array), l'unica cosa che ottieni - se la ottieni - è un errore di runtime poichè hai cercato di indirizzare un valore che non era incluso nell'area di memoria allocata per tale vettore.
    Si tratta di un fenomeno ben diverso dal page fault a cui ti riferisci che fa semplicemente parte del meccanismo di "swap" del sistema operativo il quale si occupa di scaricare su disco parte della memoria inutilizzata e ricaricarla all'occorrenza...ma tale meccanismo è trasparente dal punto di vista delle applicazioni e non coincide comunque con il problema di indirizzare un elemento di un vettore o di una matrice specificando un indice superiore ai limiti consentiti.

    Originariamente inviato da gogetassj4dp
    forse nn mi sono spiegato molto bene ma il concetto è che se si memorizzano i dati nello stesso modo in cui vengono trattati dal compilatore ci dovrebbe essere un aumento delle prestazioni del programma perchè la cpu viene usata solo per operazioni che sono affini al programma stesso.
    La frase non è molto chiaro...cosa significa "memorizzare i dati nello stesso modo in cui vengono trattati dal compilatore"? Si utilizzano i dati così come forniti a disposizione dal linguaggio utilizzato; successivamente, il compilatore si occupa di tradurre semplicemente il codice sorgente in codice eseguibile dalla macchina. Gli "aumenti di prestazioni" a cui ti riferisci probabilmente riguardano la scelta di tipi scalari (numeri interi o virgola mobile) direttamente mappabili a tipi interni della CPU per ottenere maggiore velocità di esecuzione, ma questo cosa ha a che vedere con l'argomento? :master:
    MARCO BREVEGLIERI
    Software and Web Developer, Teacher and Consultant

    Home | Blog | Delphi Podcast | Twitch | Altro...

  9. #9
    se il compilatore gestisce le matrici in un modo e io chiedo di memorizzarle in un altro, a livello di eseguibile nn accade niente. E cmq il page fault di cui ho parlato nn è visibile dall'utente ma crea cmq problema al sistema operativo se si chiede di accedere in una sequenza diversa ai dati della matrice.
    quello ke intendevo è questo: se la matrice è memorizzata per righe questo codice


    int mat[1024][1024];
    max=mat[0][0];
    for(i=0; i<1024; i++)
    for(j=0; j<1024; j++)
    if(max<mat[i][j])
    max = mat[i][j];

    nn genera page fault.
    Questo codice invece, accedendo alla matrice per colonne genera page fault.

    int mat[1024][1024];
    max=mat[0][0];
    for(i=0; i<1024; i++)
    for(j=0; j<1024; j++)
    if(max<mat[j][i])
    max = mat[j][i];

    quindi può darsi che in pascal memorizzando le matrici in un modo o nell'altro ci sia un calo delle prestazioni dovuto a questo fatto.

  10. #10
    Moderatore di Programmazione L'avatar di alka
    Registrato dal
    Oct 2001
    residenza
    Reggio Emilia
    Messaggi
    24,310
    Originariamente inviato da gogetassj4dp

    ...
    Questo codice invece, accedendo alla matrice per colonne genera page fault.
    ...
    Ho paura che tu debba ripassare la definizione di page fault.

    Si tratta di un meccanismo inerente alla gestione della memoria virtuale da parte del sistema operativo; si genera un "page fault" quando si tenta di accedere ad una locazione di memoria "virtuale" (che è quella vista dall'applicazione) che il sistema operativo ha scaricato su disco per esigenze di spazio sulla memoria fisica vera e propria. Rientra nel meccanismo di swapping sul quale il programmatore non ha generalmente alcun tipo di controllo.
    Lo swap viene eseguito dal sistema operativo quando la memoria si esaurisce, ammesso che sia abilitato (è possibile disattivare la memoria virtuale).
    Pertanto, il programmatore non ha genericamente controllo sulla memoria virtuale: si limita semplicemente a dichiarare le strutture dati di cui ha bisogno, poi se il sistema è "saturo" e si deve riporre parte della memoria fisica su disco, questo è un altro discorso, dipende dalle condizioni del sistema stesso (memoria già utilizzata, quantità di memoria, applicazioni già aperte e così via) e di certo *non* è una scelta del programmatore.

    Alla luce di questo, non si può assolutamente conoscere in anticipo se una struttura dati genererà un page fault oppure no basandosi semplicemente sulla struttura dati stessa, come quella definita nel codice che hai postato.

    Il massimo che un programmatore può fare è limitare e ottimizzare al massimo la memoria utilizzata, affinchè non venga sprecato dello spazio. Nel caso specifico, avere una matrice bidimensionale di 10x10 byte oppure avere un array di 10 array di 10 byte occupa lo stesso identico spazio.
    MARCO BREVEGLIERI
    Software and Web Developer, Teacher and Consultant

    Home | Blog | Delphi Podcast | Twitch | Altro...

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.