R vs. SAS

Interessantes ohne bestimmtes Thema!

Moderator: student

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

Re: R vs. SAS

Beitrag von EDi »

Und zwar ist der nächste Schritt Analytics-Software zu testen, welche eine gute Integration von R bieten, wie bspw. RapidMiner oder Knime.
Das verstehe ich jetzt nicht (hab aber mit professionell betriebenen data analytics bisher nur wenig Erfahrung):
Wieso RapidMiner oder Knime, wenn man die Power von R hat?
Was bringen diese an 'Mehr'? - Beim drüberfliegen ist mir nur das einfachere Interface (=kein Programmieren) aufgefallen.
Bitte immer ein reproduzierbares Minimalbeispiel angeben. Meinungen gehören mir und geben nicht die meines Brötchengebers wieder.

Dieser Beitrag ist lizensiert unter einer CC BY 4.0 Lizenz
Bild.
Benutzeravatar
student
Beiträge: 674
Registriert: Fr Okt 07, 2016 9:52 am

Re: R vs. SAS

Beitrag von student »

Vor einiger Zeit habe ich ein paar Gehversuche in Knime unternommen. Diese hatte ich sehr schnell wieder aufgegeben, weil

a) [R] aus meiner Sicht zu schlecht zu parametrisieren war und
b) schlicht zu langsam!

Das grafische Zusammenstecken der Datenbearbeitungs- und Analyseschritte fand ich interessant, sehe ich aber nur als Oberfläche für Anwender die sich nicht tiefer mit Datenanalyse beschäftigen wollen/müssen!
Viele Grüße,
Student
-----------------------------------------------------------------------------------------------------------------------
faes.de, Datenanalyse mit R & das Ad-Oculos-Projekt
Das Ad-Oculos-Projekt auf YouTube

Habe Mut, dich deines eigenen Verstandes zu bedienen! (Kant)
R007

Re: R vs. SAS

Beitrag von R007 »

In meinem Beitrag von gestern habe ich vergessen zu erwähnen, dass wir ebenfalls RStudio-Server testen werden!

Aber der Vorteil von RapidMiner oder Knime, sind wie student auch schon gesagt hat, dass man hier einen Workflows definieren kann und durch die bereits enthaltenen Nodes viele Arbeitsschritte ohne Programmier-Aufwand erledigen kann. Das heißt aber nicht, dass man sich als Analyst nicht mit der Datenanalyse im Detail nicht beschäftigen muss.
consuli
Beiträge: 479
Registriert: Mo Okt 10, 2016 8:18 pm

Re: R vs. SAS

Beitrag von consuli »

Aber der Vorteil von RapidMiner oder Knime, sind wie student auch schon gesagt hat, dass man hier einen Workflows definieren kann und durch die bereits enthaltenen Nodes viele Arbeitsschritte ohne Programmier-Aufwand erledigen kann.
Das sehe ich aber nicht nur als Vorteil. Beim SAS Enterprise Miner / SAS Enterprise Guide z.B. laufen die alten grafischen Prozesse bei einem vollen Versionssprung z.B. von 3.x auf 4.0 nicht mehr. Code kriegt man immer zum laufen.

Wie wäre es mit Revolution Analytics/ Microsoft?
Irmgard.
bigben
Beiträge: 2771
Registriert: Mi Okt 12, 2016 9:09 am

Re: R vs. SAS

Beitrag von bigben »

Hi!

Bin ich eigentlich der einzige hier, der von diesem Knime vorher noch nie was gehört hat?

LG,
Bernhard
---
Programmiere stets so, dass die Maxime Deines Programmierstils Grundlage allgemeiner Gesetzgebung sein könnte
R007

Re: R vs. SAS

Beitrag von R007 »

bigben hat geschrieben:Hi!

Bin ich eigentlich der einzige hier, der von diesem Knime vorher noch nie was gehört hat?

LG,
Bernhard
Das weiss ich nicht.:)

Hier ein paar Beispiele, wenn auch nicht mehr ganz aktuell, wie Knime und R interagieren:
https://www.knime.org/files/kos-13/inte ... ration.pdf

In R sind "Nodes" ja sozusagen eigene Skripte, die jeweils als Input das Ergebnis eines anderen Skripts haben und Ergebnisse als Output speichern. Gibt es irgendwo Beispiele zu solch ausführlichen Skripte? Diese werden dann doch in Rstudio als Projekte umgesetzt, oder?
Benutzeravatar
EDi
Beiträge: 1599
Registriert: Sa Okt 08, 2016 3:39 pm

Re: R vs. SAS

Beitrag von EDi »

dass wir ebenfalls RStudio-Server testen werden!
Das ich auch von Firmen die ein validiertes System für ihre Berechnungen benötigen.
In R sind "Nodes" ja sozusagen eigene Skripte, die jeweils als Input das Ergebnis eines anderen Skripts haben und Ergebnisse als Output speichern.
Sehe das anderes.
In R sind die "Nodes" Funktionen die ein Objekt aufnehmen, etwas damit anstellen und dann etwas ausspucken.
Funktionen kann man dann in einem Skript hintereinander anwenden um einen workflow zu erhalten.
Diese sollten auch so programmiert sein, dass sie nur einen Sachen machen um möglichst vielseitig einsetzbar zu sein.
Eine Reihe von Funktionen können dann in einem package geordnet, dokumentiert und verbreitet werden.
Eigentlich kein Hexenwerk.

Muss man halt abwägen, wie viel einem die grafische Oberfläche Wert ist (im Sinne von Geschwindigkeiteinbusen und Flexibilität).
Bitte immer ein reproduzierbares Minimalbeispiel angeben. Meinungen gehören mir und geben nicht die meines Brötchengebers wieder.

Dieser Beitrag ist lizensiert unter einer CC BY 4.0 Lizenz
Bild.
R007

Re: R vs. SAS

Beitrag von R007 »

In R sind die "Nodes" Funktionen die ein Objekt aufnehmen, etwas damit anstellen und dann etwas ausspucken.
Funktionen kann man dann in einem Skript hintereinander anwenden um einen workflow zu erhalten.
Diese sollten auch so programmiert sein, dass sie nur einen Sachen machen um möglichst vielseitig einsetzbar zu sein.
Eine Reihe von Funktionen können dann in einem package geordnet, dokumentiert und verbreitet werden.
Eigentlich kein Hexenwerk.

Muss man halt abwägen, wie viel einem die grafische Oberfläche Wert ist (im Sinne von Geschwindigkeiteinbusen und Flexibilität).
Aber wenn ich Nodes bzw. die Logik dahinter nur einmal brauche, würde ich keine Funktion schreiben. Und dann hätte ich den kompletten Code in einer Datei, was ich lieber in einzelne Dateien unterteilen würde.

Habt ihr bei euch immer eine eigene Datei pro Funktion die er schreibt? Und wie ruft ihr dann die Datei innerhalb einer naderen auf? Hab bisher immer Skripte in einer Datei geschrieben. :?

Und waa meinst du mit "eine Reihe von Funktionen können in einem package geordnet werden"?
bigben
Beiträge: 2771
Registriert: Mi Okt 12, 2016 9:09 am

Re: R vs. SAS

Beitrag von bigben »

Hallo,

eine Datei pro Funktion ist heftig, kommt aber auf die Größe Deiner Funktionen und Projekte an. Das Verteilen auf mehrere Dateien kann die Sache übersichtlicher machen und erlaubt es einem, kleinere Einheiten aus dem GIT repository zu holen. Dateien rufen sich gegenseitig per source() Kommando auf.

Ein Package ist das, was man mit dem Befehl library() oder require() geöffnet wird. Ein schicker Weg, um mehrere zusammenhängende Funktionen und die Anleitung dazu zu sortieren und weiter zu geben. Mit Hilfe von RStudio inzwischen für Normalsterbliche mit vernünftigem Aufwand erstellbar.

LG,
Bernhard
---
Programmiere stets so, dass die Maxime Deines Programmierstils Grundlage allgemeiner Gesetzgebung sein könnte
Benutzeravatar
EDi
Beiträge: 1599
Registriert: Sa Okt 08, 2016 3:39 pm

Re: R vs. SAS

Beitrag von EDi »

Aber wenn ich Nodes bzw. die Logik dahinter nur einmal brauche, würde ich keine Funktion schreiben.
You never know... Auch das umwandeln von einem Stück Skript in eine Funktion ist ja relativ einfach und schnell gemacht.
Habt ihr bei euch immer eine eigene Datei pro Funktion die er schreibt?
Kommt drauf an. Bei meinen Paketen umfasst einen Datei eine Funktion plus eventuell verwandte funktionen dazu (z.b. Methoden).
Und wie ruft ihr dann die Datei innerhalb einer naderen auf?
Entweder via source(), wenn es nur einen Datei ist in der nur Funktionen definiert sind.
Wenn es schon in einem Paket ist, einfach das Paket laden.
In beiden Fällen kann man danach die Funktion nutzen.
Bitte immer ein reproduzierbares Minimalbeispiel angeben. Meinungen gehören mir und geben nicht die meines Brötchengebers wieder.

Dieser Beitrag ist lizensiert unter einer CC BY 4.0 Lizenz
Bild.
Antworten