Seite 1 von 2

Der paradoxe R Performance Pfad

Verfasst: Di Apr 18, 2017 6:17 pm
von consuli
[edit] Aufgrund von Einwänden gegen den Titel, nachträgliche Umbenennung des Freds von "Das R Performance Paradoxon" in "Der paradoxe R Performance Pfad"
[/edit]

Schritt 1
Du lernst R um statistische Analysen zu machen.

Schritt 2
Du entdeckst, das R viel mehr ist, als eine Statistik Sprache und beginnst es für alle möglichen datennahen Probleme zu benutzen.

Schritt 3
Deine R Programme ereichen den Umfang mehrerer Schreibmaschinenseiten.

Schritt 4
Du wirst mit der Performance von R unzufrieden und lernst eine andere Programmiersprache.

Schritt 5
Mit den Kenntnissen der anderen Programiersprache verstehst Du, dass Deine R Programme programmiertechnisch suboptimal waren. Du beginnst die R Programme programmiertechnisch/ performancemässig zu optimieren.

Schritt 6
In Performance-Vergleichen zu anderen Interpreter Sprachen (z.B. Python) stellst Du fest, dass die neue R Performance doch recht kompetitiv ist. Oder aber Du müsstest die Daten(typen)- und Statistikfunktionen-Infrastruktur zu einem großen Teil selbst entwickeln (z.B. C, Julia).

Schritt 7
In Abwägung des Mehr-Programmieraufwands in anderen Sprachen gegen Performance kommst Du dann zu der zielstrebigen :lol: Entscheidung, dass R für die Analyse/ das Prototyping von quantitativen Problemen aktuell die beste Sprache ist.

Re: Das R Performance Paradoxon

Verfasst: Mi Apr 19, 2017 10:56 am
von bigben
Hi consuli,

ich habe noch nicht ganz verstanden, was an der Beobachtung Deiner Lernkurve jetzt ein Paradoxon darstellt. Ich kann aber ganz unbedingt unterstreichen, dass das Erlernen verschiedener Programmiersprachen, wenn Sie denn gut gewählt sind, lehrreich auch für das Verwenden anderer, schon bekannter, Sprachen ist (Schritt 5). Vor vielen Jahren, als ich in Python erstmals mit Funktionen höhrer Ordnung konfrontiert wurde, habe ich mir daran die Zähne ausgebissen. Weil schlaue Leute im Python-Forum immer mal wieder spaßeshalber Lösungen in Haskell vorgestellt haben, habe ich ein wenig Haskell gelernt. Nicht nur, dass ich Haskell-Lernen sehr spannend fand, mir gefiel auch die Sprache gut und seither sind rekursive Funktionen keine schwarze Magie mehr für mich und als ich R gelernt habe, gab es sofort einen unkomplizierten Zugang zur apply-Familie und was noch dazu gehört.

Ich glaube, Haskell wäre heute sogar meine Lieblingssprache, wenn ich nicht zu dumm dafür wäre. Wahrscheinlich sollte man ganz gezielt je eine funktionale Sprache, eine extrem objektorientierte, eine stackorientierte, eine prozedurale und eine maschinennahe Sprache lernen (gibt es noch weitere Kategorien, die ich vergessen habe?). Nicht so, dass man sie produktiv nutzen könnte, aber doch so, dass man deren Konzepte wirklich verinnerlicht und dann in mixed-paradigm-Sprachen wie R oder Python auch richtig nutzt. Aber wer hat dafür schon die Zeit?



In Schritt 6 schreibst Du, dass man sich in Julia seine Daten(typen)- und Statistikfunktionen-Infrastruktur selbst bauen müsste. Mit Julia habe ich mich noch nicht wirklich beschäftigt. Ich dachte, die bauen da gerade für Statistikdaten eine Infrastruktur auf. Kann jemand beschreiben, wie weit die sind?

LG,
Bernhard

Re: Das R Performance Paradoxon

Verfasst: Mi Apr 19, 2017 3:15 pm
von consuli
ich habe noch nicht ganz verstanden, was an der Beobachtung Deiner Lernkurve jetzt ein Paradoxon darstellt
Das Paradoxon besteht darin, dass R häufig mangelnde Performance unterstellt wird, die beste Lösung häufig aber nicht in anderen Sprachen besteht und die Erkenntnis häufig nicht aus R kommt. Ich gebe zu, dass dies nicht die mathematische Defintion eines Paradox ist. Aber das allgemeine Performance Paradox auch nicht.

Ich wollte den R Neulingen nur eine Einordnung des R Performance Problems nahebringen und ihnen eine gleichzeitig einen typischen iterativen Lernpfad für R Performance aufzeigen.

Re: Das R Performance Paradoxon

Verfasst: Mi Apr 19, 2017 3:28 pm
von consuli
bigben hat geschrieben: Mi Apr 19, 2017 10:56 am Ich glaube, Haskell wäre heute sogar meine Lieblingssprache, wenn ich nicht zu dumm dafür wäre.
Was hast Du es auf einmal nur mit den funktionalen Sprachen (vorher LISP). Das sind doch eher theoretische Programmierkonzepte als praktische Programmiersprachen, oder nicht?

Re: Das R Performance Paradoxon

Verfasst: Do Apr 20, 2017 3:25 pm
von bigben
Hi!

Zunächst einmal stecke ich in einer anderen Situation als Du. Für mich ich das hier alles Hobby. Ich verdiene mein Geld nicht mit Datenauswertung oder Statistik. Es ist ein nettes Plus für meinen Arbeitgeber, aber wenn ich R nicht kennen würde und keinen t-Test rechnen könnte, hätte ich am Ende des Monats das gleiche Geld und auch meinen Karriereverlauf wird es nicht beeinflussen. Vielleicht ändert das meinen Blick auf die Dinge.


Das sind doch eher theoretische Programmierkonzepte als praktische Programmiersprachen, oder nicht?
Das kann man sehen, wie man will. Probieren wir es auf einem datenanalytischen Weg zu beantworten: Der folgende Link führt zum aktuellen Redmonk-Ranking der Programmiersprachen: http://sogrady-media.redmonk.com/sograd ... 17.wm_.png

Auf der x-Achse ist die GitHub-Aktivität je Sprache dargestellt. R ist auf dieser Achse gleichauf mit Clojure und Clojure ist LISP für die JVM. Damit steht LISP deutlich vor Klassikern wie Visual Basic oder Matlab oder Assembler, denen keiner absprechen wird, dass sie praktische Programmiersprachen sind. Außerdem ist LISP in diesem Diagramm auch noch unter den Namen EmacsLisp, Common Lisp, Racket und Scheme versteckt. Wenn man alle diese Dialekte derselben Sprache zusammen gezählt hätte, hätte LISP wohl einen Platz deutlich rechts von R erhalten.
Haskell ist ebenfall auf der x-Achse gleichauf mit R. Ich würde also argumentieren, dass es praktische Programmiersprachen sind, weil Leute sie praktisch (auf GitHub) benutzen. (Auch: https://clojure.org/community/success_stories )




Die Frage hier war aber ja nicht, ob die Sprachen praktisch genutzt werden, sondern wie man von anderen Sprachen und von welchen anderen Sprachen man für R lernt.

Ich habe mal von folgendem Muster gelesen: Ein Informatiker hat eine interessante Idee für ein neues Konzept in der Programmiersprache und erfindet dann eine Programmiersprache, die das konsequent umsetzt. Diese verlässt nie die akademischen Grenzen. Später greift dann eine andere Sprache dieses Konzept auf, die damit groß und berühmt wird. Objektorientierung ist mit SmallTalk etabliert worden, den ganz großen Durchbruch hatte sie mit Java.

Ich habe erstmals in Python verzückt gesehen, dass man eine Funktion als Argument einer anderen Funktion übergeben kann. Oder in einem Vektor mehrere Funktionen ablegen kann, um dann mit einer Schleife darüber zu laufen. In R kann man das auch. Die Idee dahinter ist aber viel älter: Sie war in LISP schon etabliert. Überhaupt, wenn Du mal in der R Sprachdefinition die Suchfunktion nach "LISP" suchen lässt, siehst Du, wie das R Core Team sich auf die Abstammung Rs von LISP beruft.
Ich finde es einfach toll, wie Python ohne geschweifte Klammern und BEGIN-/END-Anweisungen, einfach durch Einrückung Codeblöcke markiert. Es spart das Tippen und damit Tippfehler, den visuellen Ablenker und zwingt zu leserlichem Einrücken. Die Idee ist nicht originell, sondern aus Haskell übernommen. Wäre eine schöne Idee, R besser zu machen.

Will sagen, es gibt viele Konzepte, die man in "akademischen" Sprachen am besten findet, und die dann in Mainstreamsprachen überführt werden. Wie Du oben geschrieben hast: Wenn man von einer Sprache mit einem anderen Ansatz zurück zu R kommt, dann nutzt man R anders.


Stellt sich die Frage, ob man das nicht alles in einer Multiparadigmenssprache lernen kann. Irgendwie ja, irgendwie nein.

Code: Alles auswählen

i = i +1 
kann in einer prozeduralen Programmiersprache (C) heißen: Ersetze den Inhalt von i mit dem Ergebnis von i+1.
kann in einer objektorientieren Sprache heißen: Schicke dem Objekt i eine Nachricht, dass es seinen Wert um 1 erhöhen soll.
kann in einer objektorientierten Sprache heißen: Rufe die get-Methode von i auf, addiere den Wert 1 und übergib das an die set-Methode von i.
kann in einer funktionalen Sprache heißen: Der Wert von i ist der Rückgabewert der Plusfunktion, wenn man sie mit i und 1 aufruft.

In Python wird einem das aber nicht unbedingt bewusst, weil man halt nie

Code: Alles auswählen

i.set(i.get() + 1) 
und auch nie

Code: Alles auswählen

i <- `+`(1, 1) # ist übrigens gültiges R
schreibt. Und weil man es nie anders schreibt, macht man sich vielleicht auch keine Gedanken drum.

Wie kompliziert kann es in höheren Sprachen sein, den Unterschied zwischen Call-by-Value und Call-by-Reference zu erklären. Wie einfach ist es hingegen in C zu erklären, dass man halt entweder den Wert auf den Stack schmeißt oder den Pointer auf die Speicherzelle mit dem Wert... In C ist es einfach zu kapieren und wer es in C kapiert hat, hat auch in keiner höheren Sprache mehr Probleme damit.

Wie undurchsichtig sind die Typumwandlungen in R?

Code: Alles auswählen

> dataframe <- data.frame(1:5, 1:5)
str(dataframe[1,])
str(dataframe[,1])
Na, welches davon gibt jetzt einen Dataframe und welches einen Vektor zurück? Wie herrlich dagegen das Typendeklarationssystem in Haskell, in dem man vor dem Deklarieren der Funktion definiert, welche Werte sie nimmt und welche sie zurück gibt. Wer diese Klarheit in Haskell gelernt hat, der schreibt nicht mehr solche dämlichen Funktionen wie '['. Oder er ist selbst Schuld.


Das war jetzt ziemlich viel Text zu Schritt 5, aber Schritt 5 ist wichtig und richtig!

Viele Grüße,
Bernhard

Re: Das R Performance Paradoxon

Verfasst: Fr Apr 21, 2017 12:05 am
von EDi
Das Buch 'Advanced R' ist auch definitiv horizonterweiternd und greift einige der erwähnten Sachen auf.

Re: Das R Performance Paradoxon

Verfasst: Do Apr 27, 2017 7:41 pm
von consuli
bigben hat geschrieben: Do Apr 20, 2017 3:25 pm
Das sind doch eher theoretische Programmierkonzepte als praktische Programmiersprachen, oder nicht?
Das kann man sehen, wie man will. Probieren wir es auf einem datenanalytischen Weg zu beantworten: Der folgende Link führt zum aktuellen Redmonk-Ranking der Programmiersprachen: http://sogrady-media.redmonk.com/sograd ... 17.wm_.png
Und wie würde das Ranking aussehen, wenn man es um den universitären Anteil von Vorlesungen, Seminaren, Programmieraufgaben usw. bereinigen würde? ;)

EDi hat geschrieben: Fr Apr 21, 2017 12:05 am Das Buch 'Advanced R' ist auch definitiv horizonterweiternd und greift einige der erwähnten Sachen auf.
bigben hat geschrieben: Do Apr 20, 2017 3:25 pm Wie kompliziert kann es in höheren Sprachen sein, den Unterschied zwischen Call-by-Value und Call-by-Reference zu erklären.
Obwohl ich in vielen von bigbens Ausführungen (vielleicht mangels Unwissen) die Relevanz für Datenprobleme nicht sehe, kann ich der Relevanz von Call-by-Value und Call-by-Reference nur beipflichten. Obwohl ich das 'Advanced R' Buch vorher schon gelesen hatte, habe ich den "Performance-Trick" anderer Programmiersprachen durch Call-by-Reference erst richtig verstanden, als ich mal in ein Python Buch reingeschnuppert habe.

Und wenn ich für die Erstmodellierung eines mathematisch anspruchsvollen Problems nun die Auswahl hätte, ceteris paribus (aka all else equal) zwischen einer etwas schnelleren Sprache mit Seiteneffekten durch Call-by-Reference und einer etwas langsameren Sporache ohne Seiteneffekte (z.B. R) , dann würde ich immer zweiteres wählen, weil ich mit der Mathematik schon genug beschäftigt bin. Und wenn jemand behauptet, dass er noch Lust hätte sich nebenbei mit unnötigen Seiteneffekten zu beschäftigen, dann ist das Problem einfach mathematisch nicht anspruchsvoll genug! :D

Was ich an R Büchern eben äußerst unschön finde (abgesehen von "Advanced R"), dass man an die Speicherreservierungsprobleme usw. nicht herangeführt wird, und dann erst mal da steht wie der Ochs vorm Berg, wenn ein Performance Problem auftritt.

Python ist zwar nicht schneller als R (meines testweisen Ausprobierens nach z.T. sogar deutlich langsamer als R), dafür eröffnet es aber viel mehr Möglichkeiten für Performance Analysen. Und mit Cython steht ein einiger Maßen einfacher Ausweg bereit, um Performance Probleme zu lösen, was ich von Glue-it-all Dörks RCPP wirklich nicht behaupten kann (, was natürlich nur an meiner mittelmässigen Programmierbegabung liegt. :lol: )

Re: Der paradoxe R Performance Pfad

Verfasst: Fr Apr 28, 2017 3:45 pm
von bigben
consuli hat geschrieben:Ich hoffe, Günther hat inzwischen angefangen Backups zu machen. Weil ich habe nämlich versehentlich Dein Posting gelöscht, bigben! Ich hatte Dich zitiert und dann wollte ich meine Antwort nochmal ändern und naja, es ist dann irgendwie in Deinem Posting Kästle gelandet. Kann es mir immer noch nicht so recht erklären. Tut mir wirklich sehr sehr leid. Ich hatte ja schon mal eine separate Moderatoren Rolle beantragt, aber bisher ... Nun ist es passiert. :oops: :cry:

Re: Der paradoxe R Performance Pfad

Verfasst: Mi Mai 03, 2017 6:37 pm
von consuli
bigben hat geschrieben: Das ist ein schönes Beispiel für Deinen obigen Punkt, dass man von einer anderen Sprache anders denkend zurück kommt.
(...)
Aber dem Konzept (...) kann ich als Freund funktionaler Programmiersprachen natürlich nur zustimmen.
Copy that. Wann dürfen dann wir dann Dein erstes functional data analysis proof of concept in R erwarten? 8-)

Consuli

Re: Der paradoxe R Performance Pfad

Verfasst: Do Mai 04, 2017 4:14 pm
von bigben
Du meinst, wann ich zum ersten Mal eine Funktion aus der apply-Familie verwende? Oder reicht Dir schon eine Funktion ohne Verwendung von'<<-' ?