Clojure versus R: avantages et inconvénients pour l'analyse de données


39

J'avais un plan d'apprentissage de R dans un proche avenir. En lisant une autre question, j'ai découvert Clojure. Maintenant je ne sais pas quoi faire.

Je pense que l’un des grands avantages de R , c’est que certaines personnes en économie l’utilisent, y compris l’un de mes supérieurs hiérarchiques (bien que l’autre ait dit: restez loin de R!). Un des avantages de Clojure est qu’il est basé sur Lisp, et comme je commence à apprendre Emacs et que j’ai envie d’écrire mes propres personnalisations, cela me serait utile (oui, je sais que Clojure et Elisp sont différents dialectes de Lisp, mais ils Lisp et donc similaire j'imagine).

Je ne peux pas demander lequel est le meilleur, car je sais que c'est très personnel, mais quelqu'un pourrait-il me donner les avantages (ou les avantages) de Clojure x R, en particulier sur le plan pratique? Par exemple, lequel devrait être plus facile à apprendre, lequel est le plus flexible ou le plus puissant, lequel a le plus de bibliothèques, plus de support, plus d'utilisateurs, etc.?

Utilisation prévue : La majeure partie de mon estimation doit être effectuée à l'aide de Matlab. Par conséquent, je ne cherche rien de trop approfondi en termes d'analyse statistique, mais plutôt un logiciel permettant de remplacer Excel par la manipulation et la visualisation initiales des données, les statistiques récapitulatives et les graphiques, mais aussi quelques analyses statistiques de base ou les tentatives initiales de mon estimation.


10
Si vous goûtez à R, il est fort probable que vous démissionniez de MATLAB (comme dans mon cas).

OMI, cela devrait être un wiki de la communauté (les questions de type "versus" sont assez subjectives).
Shane

Ceci est certainement une question concernant les langages de programmation et devrait être posée sur Stack Overflow.
Sharpie

Je suis d'accord avec Sharpie. @Vivi: vous devriez changer le titre de la question en "avantages et inconvénients pour la compilation de données" ou quelque chose du genre, de sorte que le sujet soit plus à la une.
Shane

5
@Sharpie, @Shane IMO en ce sens que c'est une question d'outils, alors c'est acceptable.

Réponses:


27

Permettez-moi de commencer par dire que j'aime les deux langages: vous ne pouvez pas vous tromper, et ils sont certainement meilleurs que quelque chose comme C ++ ou Java pour l'analyse de données.

Pour l'analyse des données de base, je suggérerais R (surtout avec plyr). IMO, R est un peu plus facile à apprendre que Clojure, bien que cela ne soit pas tout à fait évident puisque Clojure est basé sur Lisp et que de nombreuses ressources Lisp fantastiques sont disponibles (telles que SICP ). Clojure contient moins de mots-clés, mais les bibliothèques sont beaucoup plus difficiles à installer et à utiliser. De plus, gardez à l'esprit que R (ou S) est en grande partie dérivé de Scheme, vous bénéficierez donc de la connaissance de Lisp lorsque vous l'utilisez.

En général:

Le principal avantage de R est la communauté sur CRAN (plus de 2461 paquets disponibles). Rien ne sera comparable à cela dans un avenir proche, pas même une application commerciale comme matlab.

Clojure a le gros avantage de fonctionner sur la machine virtuelle, ce qui signifie qu’elle peut utiliser immédiatement n’importe quelle bibliothèque basée sur Java.

J'ajouterais que j'ai déjà parlé il y a quelque temps de Clojure / Incanter à R , ce qui peut vous intéresser. D'après mon expérience, Clojure était généralement plus lent que R pour des opérations simples.


11

Je suis un gros utilisateur de R depuis 6 ou 7 ans. En tant que langage, il a plusieurs limitations de conception. Pourtant, pour les travaux en économétrie et en analyse de données, je le recommande toujours de tout coeur. Il contient un grand nombre de packages qui vous intéresseraient pour l'économétrie, les séries chronologiques, la modélisation du choix du consommateur, etc., et bien sûr une excellente visualisation, de bonnes bibliothèques d'algèbre et numériques, etc. Bien que R n’ait pas été conçu pour le "big data" (contrairement à, par exemple, SAS), il existe des solutions. La disponibilité des forfaits est ce qui fait vraiment la différence.

J'ai seulement lu les spécifications linguistiques de Clojure, et c'est beau et propre. Il aborde de manière naturelle les problèmes de parallélisation et d'échelle. Et si vous avez des connaissances de base en Java ou en POO, vous pouvez bénéficier du grand nombre de bibliothèques Java de haute qualité.

Le problème que j’ai avec Clojure est qu’il s’agit d’une opération récente menée par un seul homme (R.Hickey), donc 1) très risquée 2) très immature 3) avec adoption de niche. Idéal pour les amateurs, les utilisateurs précoces, les personnes CS / ML qui veulent essayer de nouvelles choses. Pour un utilisateur qui considère une langue comme un moyen de parvenir à une fin et qui a besoin d'un code très robuste pouvant être partagé avec d'autres, les langues établies semblent un choix plus sûr. Sache juste qui tu es.


+1 excellente réponse. J'ai eu un débat similaire il y a quelque temps parce que j'étais intrigué par Incanter (et que j'ai fait du codage Java). Il était clair que R était le langage à utiliser pour faire le travail statistique rapidement tandis que Clojure était le langage à utiliser pour penser plus comme un informaticien. Évidemment, il y a un chevauchement, mais comme vous le dites, "savez qui vous êtes".
Josh Hemann

SAS est si vieux qu’il fonctionnait à l’origine sur des cartes perforées, d’où sa syntaxe maladroite et archaïque. Une partie de sa «conception de données volumineuses» n’est tout simplement pas une chance si elle a été conçue à l’origine pour fonctionner sur des «ordinateurs centraux» qui ont moins de mémoire que votre téléphone et qui utilisent des cartes perforées pour saisir des données. Je ne dirais pas qu'il est "conçu" pour le Big Data, même s'il se comporte bien.
Wayne

J'ai eu des préoccupations similaires à propos de Clojure en 2011 lorsque j'en ai entendu parler pour la première fois. Je ne le fais pas maintenant, en 2014. Clojure et sa communauté sont assez matures et étonnamment populaires (après tout, c'est un non-OO, fonctionnel, Lisp). Cependant, je ne pense pas qu'Incanter rattrapera jamais R en nombre de paquets (généralement, si vous pouvez y penser, c'est déjà fait). Il existe une bibliothèque Clojure Rincanter basée sur l'interface JRI Java-R, mais je ne suis pas sûr de la facilité d'utilisation.
Mars

5

Mise à jour (août 2014): comme @gappy commente ci-dessous, à partir de R version 3.0.0, les limites sont plus élevées et signifie que R est capable de gérer des ensembles de données plus volumineux.

Voici un point de données: R a un «plafond de données volumineuses» , utile pour savoir si vous prévoyez de travailler avec d’énormes jeux de données.

Je ne sais pas si les mêmes limitations s'appliquent à Clojure / Incanter, s'il surpasse R ou s'il est pire. J'imagine que la machine virtuelle Java peut probablement gérer de grands ensembles de données, en particulier si vous parvenez à exploiter la puissance des fonctionnalités paresseuses de Clojure.


1
R est également évalué paresseux.

3
@mbq: Votre commentaire est trompeur. R évalue paresseusement les variables dans une définition de fonction mais "la paresse" n'est pas un comportement normal. La fonction delayAssign () existe pour indiquer à l'interprète qu'il est paresseux avec l'affectation d'une variable, mais ce dernier effectuera l'évaluation une fois que la structure de données pointe sur cette variable, qu'elle ait besoin d'être évaluée ou non. De plus, la société commerciale Revolution Analytics devait créer un objet itérateur pour prendre en charge son marketing pour utiliser R dans l'analyse "Big Data".
Josh Hemann

Je pense que cette réponse devrait être mise à jour. Depuis R 3.0.0, R n’a plus une limite de 2 ^ 31-1 éléments. La limite n'est pas 2 ^ 63-1 (je crois) et 2 ^ 31-1 sur chaque dimension d'un tableau. Cela le rend adapté aux gros objets en mémoire.
Gappy
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.