Non posso sottolineare più la differenza di efficienza tra i due! Sebbene sia vero che i DF sono più convenienti in alcuni casi di analisi dei dati in particolare, consentono anche dati eterogenei e alcune librerie li accettano solo, questi sono tutti secondari a meno che non si scriva un codice unico per un'attività specifica.
Lasciate che vi faccia un esempio. C'era una funzione che calcolava il percorso 2D del metodo MCMC. Fondamentalmente, questo significa che prendiamo un punto iniziale (x, y) e ripetiamo un certo algoritmo per trovare un nuovo punto (x, y) ad ogni passo, costruendo in questo modo l'intero percorso. L'algoritmo prevede il calcolo di una funzione abbastanza complessa e la generazione di alcune variabili casuali ad ogni iterazione, quindi quando viene eseguito per 12 secondi ho pensato che andasse bene dato quanto roba fa ad ogni passaggio. Detto questo, la funzione ha raccolto tutti i punti nel percorso costruito insieme al valore di una funzione obiettivo in un data.frame a 3 colonne. Quindi, 3 colonne non sono così grandi e anche il numero di passaggi era più che ragionevole di 10.000 (in questo tipo di problemi i percorsi di lunghezza 1.000.000 sono tipici, quindi 10.000 non è nulla). Quindi, ho pensato a un DF 10, 000x3 non è sicuramente un problema. Il motivo per cui è stato utilizzato un DF è semplice. Dopo aver chiamato la funzione, è stato chiamato ggplot () per disegnare il percorso (x, y) risultante. E ggplot () non accetta una matrice.
Poi, ad un certo punto per curiosità, ho deciso di cambiare la funzione per raccogliere il percorso in una matrice. Volentieri la sintassi di DF e matrici è simile, tutto ciò che ho fatto è stato cambiare la riga specificando df come data.frame in uno inizializzandolo come matrice. Qui devo anche menzionare che nel codice iniziale il DF è stato inizializzato per avere la dimensione finale, quindi più tardi nel codice della funzione sono stati registrati solo nuovi valori in spazi già allocati e non vi era alcun sovraccarico di aggiungere nuove righe al DF. Ciò rende il confronto ancora più equo, e ha anche semplificato il mio lavoro in quanto non avevo bisogno di riscrivere nulla di più nella funzione. Solo una riga cambia dall'allocazione iniziale di un data.frame della dimensione richiesta a una matrice della stessa dimensione. Per adattare la nuova versione della funzione a ggplot (), ho convertito la matrice ora restituita in dati.
Dopo aver rieseguito il codice non riuscivo a credere al risultato. Il codice viene eseguito in una frazione di secondo! Invece di circa 12 secondi. E ancora una volta, la funzione durante le 10.000 iterazioni legge e scrive solo valori su spazi già allocati in un DF (e ora in una matrice). E questa differenza è anche per la dimensione ragionevole (o piuttosto piccola) 10000x3.
Quindi, se la tua unica ragione per usare un DF è renderlo compatibile con una funzione di libreria come ggplot (), puoi sempre convertirlo in un DF all'ultimo momento - lavora con le matrici per quanto ti senti conveniente. Se d'altra parte c'è un motivo più sostanziale per usare un DF, come ad esempio usare un pacchetto di analisi dei dati che richiederebbe una trasformazione altrimenti costante da matrici a DF e viceversa, o se non si eseguono calcoli intensivi da soli e si usa solo standard pacchetti (molti di loro in realtà trasformano internamente un DF in una matrice, fanno il loro lavoro e poi trasformano il risultato indietro - quindi fanno tutto il lavoro di efficienza per te) o fanno un lavoro una tantum in modo da non preoccuparti e sentirti più a tuo agio con i DF, quindi non dovresti preoccuparti dell'efficienza.
O una diversa regola più pratica: se hai una domanda come nel PO, usa le matrici, quindi utilizzeresti DF solo quando non hai una domanda del genere (perché sai già che devi usare DF, o perché lo fai non importa davvero perché il codice è una tantum ecc.).
Ma in generale, tenere presente questo punto di efficienza sempre come priorità.