Über Funktionsschleife Werte erzeugen für Referenztabelle

[EDi]

Hallo EDi,

es steht ja nirgends geschrieben, dass eine Statistiksprache im 21. Jahrhundert nicht besser werden kann als im 20. Jahrhundert. Was mich an der ganzen Tidyverse-Entwicklung stört ist die Sprachverwirrung die entsteht, wenn man für jede Basisfunktion von R ein neues Verb erfindet und die dann solchermaßen einmal komplett ausgetauschte Sprache dann weiterhin R nennt. Es entstehen am Ende zwei Gruppen: die eine schaut ihre data.frames mit str an und rechnet einen t.test, die andere schaut Ihr tibble mit glimpse an und rechnet einen t_test. Wenn man die neue Sprache R++ nennen würde, dann wäre vieles einfacher.

Ich sehe das nicht als neue Sprache. Vielleicht als "Dialekt"...
Pakete gehören seit Anfang an zu R und erlauben neue Funktionen. Für mich ist alles R.
Man sollte base-R kennen, aber wenn man einen nutzen draus hat auch Pakete nutzen.
WIe es einem passt.

Ich nutze z.B. immer str und nie glimpse. t_test brauche ich nicht, hab ja lm()

Was ich hier sehe, ist dass teilweise wohl unterschiedlich gelehrt wird. Teilweise erkennt man auch, dass Grundlagen nicht gelehrt werden.
Base-R ist essentiell, ohne das wird man das tidyverse auch nicht verstehen...
Auch beim tidyverse sieht an viele Leute hier, welche die funktionsweise einer pipe nicht verstanden haben.

Kürzlich hatte hier jemand ein Buch auf dem Schreibtisch liegen, das ich nicht kannte: R für Dummies. Ich musste es aufschlagen und herumblättern um zu erfahren, ob es Klassisch-R oder Neu-R lehrt. Vom Cover war nicht zu erkennen, welche Sprache Gegenstand des Buches ist!

Für mich ist das egal. Macht keinen Unterschied, eventuell muss ich bisschen nachlesen, aber aus dem Kontext versteht man das.
Das ist wie unterschiedliche Code-Stile. Jeder hat einen unterschiedlichen und man wird nie das standardisiert bekommen (selbst mit den besten lintern nicht). Ich habe schon viel code von vielen unterschiedlichen Menschen gelesen. Jeder Code war anders, trotzdem konnte ich verstehen was da geschieht.

Ich denke alle Lösungen valide und man sollte auch die vielfalt zeigen. Dadruch kann man nur lernen, seinen Horizont erweitern um dann für neune Probleme mehr Lösungsansätze zu haben. Man kann ja dann selbst entscheiden, was für einen funktioniert.
Beim Gruppenmaximum habe ich 2014 schon 10 verschiedene Arten gezeigt: https://stackoverflow.com/questions/253 ... 5#25314565
Ist halt open source....

Sprachverwirrung

Ich mag viele Sachen von tidyverse nicht. Die absichtlichen name-clashes mit base-R finde ich sch***. Das hat mich auch schon nerven gekostet bei debuggen. Ebenso, breaking changes in dplyr.

Aber genauso ist base-R sehr verwirrend [strigsAsFactor ist ja jetzt endlich Geschichte...], vorallem beim funktionellen programmieren:
sapply() ist nicht typ-stabil. Das hat mich auch schon nerven beim debuggen gekostet. Das habe ich aus meinem repertoire gestrichen!
vapply() ist die alternative - aber wer nutzt die hier? Außerdem muss ich da mehr tippen...
Wenn ich lapply() nutze brauche ich auch mehr code-Zeilen.
Die syntax von lapply und mapply ist nicht gleich (Reihenfolge der Argument, MoreArgs und ...) - warum? Das verwirrt...

purrr standardisiert das und das ist für mich ein Vorteil.
Wie gesagt: Jeder wie er will und was er mag. Interessanter find ich hier wenn Leute sagen, sie möchten aber eine Lösung mit Paket xxx.

[EDi]

tabelle05 <- reshape(subset05, v.names = "n", timevar = "d",
idvar = "power", direction = "wide")

reshape ist z.B. eine Funktion aus base-R, die ich nie verinnerlichen konnte!
Warum timevar? Ich habe doch gar keine Zeit?

reshape2 mit dcast() war da schon zugänglicher für mich, tidyr::spread und pivot_wider warum dann nochmal ein wenig zugänglicher.

Zum Beispiel von oben:

mapply wäre auch eine passende Funktion, finde ich fast lesbarer als apply (da hat man das MARGIN nicht).

Code: Alles auswählen

mapply(pwr, scen$alpha, scen$d, scen$power)

vapply, sapply() & lapply() gingen auch

Code: Alles auswählen

sapply(1:nrow(scen), function(row) pwr(scen[row, "alpha"], scen[row, "d"], scen[row, "power"]))
lapply(1:nrow(scen), function(row) pwr(scen[row, "alpha"], scen[row, "d"], scen[row, "power"]))
vapply(1:nrow(scen), function(row) pwr(scen[row, "alpha"], scen[row, "d"], scen[row, "power"]), FUN.VALUE = numeric(1))

[bigben]

Hallo EDi,

Du hast geschrieben:

Ich denke alle Lösungen valide und man sollte auch die vielfalt zeigen. Dadruch kann man nur lernen, seinen Horizont erweitern um dann für neune Probleme mehr Lösungsansätze zu haben. Man kann ja dann selbst entscheiden, was für einen funktioniert.

Vorneweg hoffe ich es ist klar, dass meine Antwort mit Nicht-purr und nicht Nicht-dplyr genau so gemeint war. Nicht als Richtigstellung, sondern als Ergänzung.

Wenn das aus dem Weg ist, hier mein Senf als Diskussionsbeitrag:

... Wenn man die neue Sprache R++ nennen würde, dann wäre vieles einfacher.

Ich sehe das nicht als neue Sprache. Vielleicht als "Dialekt"...

Da müsste man jetzt vielleicht ins Detail gehen, wo die Grenzen verlaufen. Deutsch ist meine Muttersprache und ich verstehe viele Deutsche Dialekte nicht. Insofern verändert das meine Argumentation nicht: Wenn man einem Ausländer ein Wort beibringt sollte man dazu sagen, ob das Schwäbisch, Niederbayrisch oder Blattdeutsch ist. Auf R übertragen bist Du in diesem Bild der Linguist, der die Details verschiedener Dialekte studiert und einzuordnen weiß.

Pakete gehören seit Anfang an zu R und erlauben neue Funktionen.

Das ist unbestritten und die Qualität von CRAN sucht sicher in anderen Sprachen ihresgleichen. R ohne Importe zu fordern wäre dämlich. Für den Anfänger wird es dann aber sehr schnell sehr unübersichtlich und es wäre nicht verkehrt wenn es so etwas wie einen gemeinsamen Kanon von essentiellen Paketen für alle, empfehlenswerten Paketen für spezielle Aufgaben und persönlichen Geschmackspaketen gäbe.

Für mich ist alles R.

Für mich nicht. Wen man mit sqldf SELECT-Statements produziert ist das für mich SQL. Aber das ist Haarspalterei. Interessant finde ich die Entwicklung mit der Pipe. Die hätte ich anfangs für genauso wesenfremd für R gehalten wie das Erstellen eines SELECT-Statements in einem String, aber inzwischen muss wohl jeder zugeben, dass die Pipe ein Teil von R geworden ist und nicht wieder weggehen wird. Sprachen sind lebendig.

Man sollte base-R kennen, aber wenn man einen nutzen draus hat auch Pakete nutzen.
WIe es einem passt.

Mindestens der zweite Teil wird wohl nicht bestritten. Ob man base-R kennenlernen muss, ich glaube da besteht keine Einigkeit.

Ich nutze z.B. immer str und nie glimpse.

Du bist eben kein rein Gläubiger. Ich bin dann wieder zu doof, mich jedes Mal zwischen glimpse und glance richtig zu entscheiden, bei der Vielzahl der Verben.

t_test brauche ich nicht, hab ja lm()

Da profitierst Du dann aber nicht von der Welch-Korrektur für ungleiche Varianzen.

Was ich hier sehe, ist dass teilweise wohl unterschiedlich gelehrt wird. Teilweise erkennt man auch, dass Grundlagen nicht gelehrt werden.

Du hast natürlich Recht, dass man schlechten Unterricht nicht dem tidyverse anlasten darf, auch dann nicht, wenn schlechte Lehrer vielleicht gerne auf diesen Zug aufspringen.

Base-R ist essentiell, ohne das wird man das tidyverse auch nicht verstehen...
Auch beim tidyverse sieht an viele Leute hier, welche die funktionsweise einer pipe nicht verstanden haben.

Ist vielleicht ein wenig ähnlich wie bei Word und Excel. Beides an sich sehr gute Programme, aber ein Großteil der User bastelt halt ohne Grundvorstellung von den Basics damit herum, als ob das eine eine Schreibmaschine und das andere Kästchenpapier sei.

Kürzlich hatte hier jemand ein Buch auf dem Schreibtisch liegen, das ich nicht kannte: R für Dummies. Ich musste es aufschlagen und herumblättern um zu erfahren, ob es Klassisch-R oder Neu-R lehrt. Vom Cover war nicht zu erkennen, welche Sprache Gegenstand des Buches ist!

Für mich ist das egal. Macht keinen Unterschied, eventuell muss ich bisschen nachlesen, aber aus dem Kontext versteht man das.

Für Dich ist das egal, aber Du bist auch nicht die Zielgruppe von "R für Dummies".

Aber genauso ist base-R sehr verwirrend [strigsAsFactor ist ja jetzt endlich Geschichte...]

Mir würde da jetzt schlimmere Beispiele als stringsAsFActor einfallen, aber da gibt es keinen Mangel an Beispielen und in R mal richtig aufzuräumen bzw. neu anzufangen ist ein ehrenwertes und berechtigtes Anliegen. Persönlich finde den Ansatz von z. B. mosaic schöner, die die eingeführten Funktionen von R erhalten und sinnvoll abwandeln/ergänzen, z. B. dem mean-Befehl ein formula-Interface geben, damit man gleich aggregieren kann:

Code: Alles auswählen

library(mosaic)
with(mtcars, mean(disp ~ gear))
with(mtcars, sd(disp ~ gear))

Da wird respektvoll mit der Sprache umgegangen, niemand muss hunderte neuer Verben lernen und dann darf man in meinen Augen auch schonmal Standardfunktionen überschreiben. Das wär dann für mich auch ein Dialekt und keine neue Sprache. Aber gut, solchen Anliegen sind Grenzen gesetzt und vielleicht ist es nötig, reinmal tabula rasa zu machen.

purrr standardisiert das und das ist für mich ein Vorteil.

Ich werde das zum Anlass nehmen, mir purrr nochmal in Ruhe anzuschauen. Das habe ich bisher nicht getan. Funktionsnamen die einen Datentyp im Namen tragen, wie etwa pmap_dbl oder pmap_int haben mich vielleicht übereilt zurückschrecken lassen. Es gibt stark und schwach typisierte Sprachen und R gehört zu den schwach typisierten Sprachen. In R haben wir generische Funktionen, die sich dem jeweils übergebenen Datentyp anpassen etc. Solche generischen Funktionen gibt es auch in stark typisierten Sprachen. Sah für mich aus wie ein Schritt in eine lower level language.

reshape ist z.B. eine Funktion aus base-R, die ich nie verinnerlichen konnte!
Warum timevar? Ich habe doch gar keine Zeit?

Ja, das ist dämlich und es ist komisch, dass Base-R für eine so zentrale Aufgabe nicht besser ausgestattet ist. Als ich das geschrieben hab habe ich mich am Hilfetext der Funktion entlang gehangelt und gefunden, dass das für die Richtung lang nach weit ziemlich gut beschrieben war. Für die andere Richtung habe ich das früher auch schon mal anders empfunden. Ich glaube, mit ein bisschen besseren Argumentnamen und einer vernünftigen Dokumentation wäre die Funktion gar nicht so schlecht wir ihr Ruf. Mal sehen, vielleicht Student irgendwann mal ein AdOculos-Video über den richtigen Gebrauch von reshape?

So, ist jetzt sehr lang geworden. Ich wünsche allen ein schönes Wochenende!
LG,
Bernhard

[EDi]

Da profitierst Du dann aber nicht von der Welch-Korrektur für ungleiche Varianzen.

Dann wird's eben ein gls() mit 2 Varianzparametern [Wobei ich da nicht mehr sagen kann ob das identisch mit dem Welch ist - muss ich mal anschauen...]

Wen man mit sqldf SELECT-Statements produziert ist das für mich SQL. Aber das ist Haarspalterei.

Das ist auch so eine Geschichte, wo ich noch unschlüssig bin...
Ich nutze beides SQL und dbplyr. dbplyr hat den Vorteil dass man R-Syntax schreiben kann , welche in SQL umgewandelt wird. Das ist schnell runtergeschrieben, hat aber den Nachteil dass man es nicht soo gut versteht, falls man kein R/dplyr Nutzer ist. Dafür muss man aber praktisch kein SQL verstehen.

Plain-SQL geht auch mit dem DBI Paket. Man schreibt schöne SQL Syntax und ist flexibler. Allerdings muss man mehr Code schreiben (um z.b. sqm injektion zu verhindern) und muss SQL kennen.

Ich nutze beides derzeit gemischt SQL für die schweren Fälle (UPSERTS, PostGIS, ...) und dbplyr für die einfachen...
Was besser lesbar & wartbar ist? Vermutlich SQL weil expliziter, aber dbplyr kann auch von nicht SQL-Könnern gelesen werden...


Ähnliches Dilemma hab ich bei data.table. Wenn ich data.table nutze, schränke ich die Zahl der R Programmierer ein die das lesen können...

Gleiches Argument könnte man auch für das tidyverse aufführen. Aber da ist gefühlt die Einschränkung geringer, weil es mehr Nutzer gibt ?

Ist vermutlich ein generelles Programmierungsproblem... Keine Ahnung was beste Praktiken da wären...

[bigben]

Dann wird's eben ein gls() mit 2 Varianzparametern

Na toll, wie so oft, wenn ich mit Dir was über Statistik schreibe, verlängert sich meine Liste von Modellen über die ich "bei Gelegenheit mal was in Erfahrung bringen" muss, mal wieder um ein weiteres Modell.