Das R Performance Paradoxon

Wie rufe ich R-Funktionen auf, wie selektiere ich Daten, ich weiß nicht genau ....

Moderatoren: EDi, jogo

Antworten
consuli
Beiträge: 99
Registriert: Mo Okt 10, 2016 8:18 pm

Das R Performance Paradoxon

Beitrag von consuli » Di Apr 18, 2017 6:17 pm

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.
Consuli
_______________________________
It's not that I am that smart, it's just that I stay with the problems longer. A. Einstein

bigben
Beiträge: 161
Registriert: Mi Okt 12, 2016 9:09 am

Re: Das R Performance Paradoxon

Beitrag von bigben » Mi Apr 19, 2017 10:56 am

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
---
Programmiere stets so, dass die Maxime Deines Programmierstils Grundlage allgemeiner Gesetzgebung sein könnte

consuli
Beiträge: 99
Registriert: Mo Okt 10, 2016 8:18 pm

Re: Das R Performance Paradoxon

Beitrag von consuli » Mi Apr 19, 2017 3:15 pm

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 eine typische R Karriere aufzeigen.
Consuli
_______________________________
It's not that I am that smart, it's just that I stay with the problems longer. A. Einstein

consuli
Beiträge: 99
Registriert: Mo Okt 10, 2016 8:18 pm

Re: Das R Performance Paradoxon

Beitrag von consuli » Mi Apr 19, 2017 3:28 pm

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?
Consuli
_______________________________
It's not that I am that smart, it's just that I stay with the problems longer. A. Einstein

bigben
Beiträge: 161
Registriert: Mi Okt 12, 2016 9:09 am

Re: Das R Performance Paradoxon

Beitrag von bigben » Do Apr 20, 2017 3:25 pm

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
---
Programmiere stets so, dass die Maxime Deines Programmierstils Grundlage allgemeiner Gesetzgebung sein könnte

Benutzeravatar
EDi
Beiträge: 156
Registriert: Sa Okt 08, 2016 3:39 pm

Re: Das R Performance Paradoxon

Beitrag von EDi » Fr Apr 21, 2017 12:05 am

Das Buch 'Advanced R' ist auch definitiv horizonterweiternd und greift einige der erwähnten Sachen auf.
Website
github

Dieser Beitrag ist lizensiert unter einer CC BY 4.0 Lizenz
Bild

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste