STATISTIK-FORUM.de

[Tobias Stump]

Danke euch Zwei.

Ich vermute, dass ich nicht um einen Vergleich kommen werde. Damit werde ich mich jetzt mal beschäftigen. Aber mit R und ein paar Schleifen, oder apply-Funktionen, sollte das nicht so aufwändig werden, wird eventuell ein wenig Zeit erfordern, dann läuft der PC eben über Nacht.

[mango]

Hi, hier mal ein (zugegebenerweise recht primitiver) Code, um so etwas zu realisieren:

Code: Alles auswählen

data_original <- c(1,2,4,1,2,3,1,4,5,4,5,7,4,2,4,6,4,2,5,3) #Deine Originalzeitreihe; ist hier nur ein Beispiel für den Test
n <- length(data_original) #Länge der Zeitreihe
d <- 4 #Maximales "Vergröberungsintervall"

index<-matrix(NA,nrow=n,ncol=d)


for (i in 1:d) {
   # i ist das aktuelle Vergröberungsintervall
   # n ist die Länge der Zeitreihe

   nullen <- rep(0,len=i-1)
   sequenz <- c(1,nullen)
   index[,i] <- rep(sequenz,len=n)

}
data_filter <- data.frame(index,data_original)
colnames(data_filter)<-c('Dummy1','Dummy2','Dummy3','Dummy4','Daten')

mittelwerte <- vector(length=d)
standardabweichungen <- vector(length=d)

for (i in 1:d) {
   Dummy <- paste("Dummy",i, sep="")
   data_aktuell <- data_filter[ which( data_filter[[Dummy]]==1 ),]
   print(Dummy)
   print(data_aktuell)
   mittelwerte[i] <- mean(data_aktuell[,"Daten"])
   standardabweichungen[i] <- sd(data_aktuell[,"Daten"])
}
mittelwerte
standardabweichungen


Das einzige, was noch fehlt, ist die Anwendung auf alle möglichen Varianten für ein bestimmtes "Vergröberungsintervall", sprich für jeden Startpunkt.

[bele]

@mango: nein, da fehlt noch viel mehr als nur die verschiedenen Startpunkte. Du machst vor, wie man es so machen könnte, wie Tobias "von Hand zu Fuß" versteht. Die Eingangsfrage, wie man da jetzt eine statistische Signifikanz herausziehen soll, bleibt damit unbeantwortet. Man könnte vielleicht die verschiedenen Startpunkte nehmen und die vorhandenen Jahre getrennt analysieren um so irgendwie auf eine Schätzung der Streuung zu kommen.

@Tobias: Siehst Du, wie leichtfertig mango vier Dummys anlegt, die alle genauso lang sind wie die Datenreihe? Er scheint auch nicht zu glauben, dass man hier programmiertechnisch besondere Rücksichten auf die Speicheranforderungen oder Rechenzeit nehmen muss. Auch wenn Deine Datenreihen zugegebenermaßen sehr lang sind und leicht einsichtig ist, dass Du sie für vieles wirst kürzen müssen. Ich glaube halt weiter, dass Du nicht für jede Auswertung das gleiche Maß an Kürzung verwenden kannst und solltest und die Frage nach der gewünschten Auswertung vor der nach dem erforderlichen und akzeptablen Maß der Kürzung beantworten solltest.

LG,
Bernhard

[mango]

@mango: nein, da fehlt noch viel mehr als nur die verschiedenen Startpunkte. Du machst vor, wie man es so machen könnte, wie Tobias "von Hand zu Fuß" versteht. Die Eingangsfrage, wie man da jetzt eine statistische Signifikanz herausziehen soll, bleibt damit unbeantwortet. Man könnte vielleicht die verschiedenen Startpunkte nehmen und die vorhandenen Jahre getrennt analysieren um so irgendwie auf eine Schätzung der Streuung zu kommen.

Stimmt, das war ja auch nur der Ansatz für eine Umsetzung, wie ich sie vorgeschlagen habe. Dass mein Vorschlag nicht vollständig oder die beste Option sein könnte, habe ich nie ausgeschlossen. Das ist allein aus programmiertechnischen Limitierungen heraus keine typische Big-Data-Lösung aber ich bezweifle einfach mal, dass die Daten vom Umfang her so enorm sind, dass die Laufzeit der Loops da den entscheidenden Unterschied macht. Wir reden hier ja wohlgemerkt von univariaten Zeitreihen, nicht von einer tatsächlichen großen Zahl einzelner Datensätze, die da verarbeitet werden muss.

Und die Frage der Signifikanz ist auf Basis meines Skriptes ja ganz einfach einzubauen, indem man auf die verschiedenen erzeugten Teil-Dataframes zusammen etwa eine Varianzanalyse anwendet.

[mango]

Aber mal ganz direkt gefragt: Wie könnte ich denn im vorliegenden Beispiel die Verwendung von Loops vermeiden und ressourcenschonender programmieren?

[bele]

Hallo mango,

hoffentlich hast Du das jetzt nicht falsch aufgefasst, das täte mir Leid. Wir hatten kurz das Thema "Big Data", weil das so im Thread-Titel steht und ich nachgefragt habe, ob wir da was beachten müssen. Big Data ist ja nirgends scharf definiert. Eine verbreitete Definition ist "wenn's nicht mehr in den RAM passt". Für mich ist Big Data, wenn man nach neuen und anderen Algorithmen suchen muss, als in der üblichen Datenverarbeitung.

Falls das missverstanden worden ist: Ich habe Dir keine schlechte Programmierung vorgeworfen und auch nicht behauptet, Dein Code wäre ineffizient. Im Gegenteil: ich habe Deinen Code zur Bekräftigung meiner Argumentation gemacht: Wenn Du jetzt Angst um RAM und Rechenzeit gehabt hättest, dann hättest Du bestimmt erstmal nur einen Dummy erstellt, damit die Statistik gerechnet, diesen Dummy dem Garbage Collector übergeben und dann einen neuen Dummy für die nächste Rechnung gemacht. Wenn Du von ganz großen Datenmengen ausgegangen wärest, dann hättest Du die Daten vielleicht nicht selbstverständlich in einem Vektor vermutet, sondern in einer Datenbank und hättest die Auswahl der Daten vielleicht über SQL geregelt und wenn Du richtig big big data vermutet hättest, dann hättest Du über verteiltes Rechnen oder MapReduce nachgedacht. Hast Du aber nicht, weil Du, wie ich auch, der Meinung bist, dass man diese Datenmengen für einfache Operationen wie Mittelwerte und Standardabweichungen mühelos im RAM handeln kann. Es war also nicht als Vorwurf gemeint sondern als Ausdruck unserer Einigkeit. Letztlich ist die Diskussion über den Begriff Big Data hier aber fruchtlos.

Natürlich ändert sich das mit der Handhabbarkeit der Daten ganz schnell, wenn man von den 10-sekündigen Daten aus mehreren Jahren nicht mehr den Mittelwert berechnen will, sondern für eine Clusteranalyse eine Distanzmatrix errechnen will. Dann lassen sich diese Datenmengen nicht mehr so einfach mit unseren Mitteln handhaben. Da reicht bestimmt auch Rechnen über Nacht nicht. Deshalb sage ich ja, dass erst geklärt werden muss, welche Art von Auswertung denn ansteht.

Nur auf Deine Nachfrage hin: Wenn man Deinen Code wirklich noch schneller machen müsste, wäre vielleicht data.table eine Idee. Ich bin da nicht firm drin, aber das ist in vielen Fällen wirklich viel schneller als klassische R-Datenstrukturen. Sonst müsste man entweder kleinteilig von Code-Abschnitten Alternativen suchen und prüfen, welche davon schneller sind oder nach Flaschenhälsen suchen, die man ggf. in C++ auslagert.

Code: Alles auswählen

which( data_filter[[Dummy]]==1 )

könnte man wahrscheinlich beispielsweise durch

Code: Alles auswählen

as.logical(data_filter[[Dummy]])

ersetzen und sich so den vielfachen Aufruf von '==' und von which() sparen und durch das hoffentlich sehr simple und schnelle as.logical() ersetzten, aber ob das jetzt wirklich viel bewegt oder Quatsch ist, müsste man messen. Deine Schreibweise ist in jedem Fall lesbarer.
Ansonsten hätte ich vorgeschlagen, mean() mit dem Argument na.rm=TRUE aufzurufen, denn in so einem großen Datensatz gibt es sehr wahrscheinlich NAs und mit Standardargumenten bringt mean() dann kein Ergebnis. Nochmal: Ich finde den Code gut so wie er ist

Viele liebe Grüße,
Bernhard