Sortie de R version 3.0.0

Posté par arnaudus le 04 avril 2013 à 21:26. Édité par alpentux, Nÿco, claudex et Sylvestre Ledru. Modéré par Pierre Jarillon. Licence CC By‑SA.

Étiquettes :

avr.

2013

Le projet R annonce la sortie de la version 3.0.0 du logiciel statistique du même nom (pre-release le 7 mars 2013, sortie officielle le 3 avril).

R désigne à la fois un langage de programmation et son interpréteur. Historiquement, R est un dialecte dérivé du langage S, implémenté dans le logiciel propriétaire S-PLUS. L'aventure R a débuté en 1993, mais c'est à partir des années 2000 qu'il a pris une importance majeure dans le paysage des langages destinés aux applications statistiques. R rivalise aujourd'hui avec ses concurrents SAS (Statistical Analysis System), SPSS (Statistical Package for the Social Sciences), ou STATA ; il est devenu incontournable dans certaines disciplines, notamment la biologie.

Le changement de version majeur (2.15.3 vers 3.0) ne signale pas une transition importante (voir le changelog), mais marque une évolution progressive (la version 2.0 date de 2004). La mise à jour requiert cependant une réinstallation complète.

R fonctionne de manière modulaire, avec un cœur relativement réduit, sur lequel peuvent se greffer des bibliothèques de fonctions fournies sous forme de « paquets ». R doit certainement une partie de son succès à l'activité de sa communauté, puisque plus de 4700 paquets activement maintenus sont disponibles au téléchargement sur le site officiel, sans compter les projets indépendants, comme bioconductor.

R est avant tout destiné au traitement et à l'analyse des données : tests statistiques, data mining, et production de graphiques de qualité (destinés à la publication). Le langage est de plus en plus utilisé pour produire des scripts portables, ou pour réaliser des simulations numériques (MCMC, typiquement). Réputé inefficace en tant que langage interprété, la possibilité de coder les fonctions critiques en C tout en utilisant la syntaxe « haut-niveau » de R ouvre une niche écologique significative pour le développement d'applications statistiques.

Au cours des dernières années, R s'est en effet enrichi pour fournir des fonctionnalités destinées au développement d'applications complexes : les classes de type S4 pour la programmation objet (typage, héritage, etc.) ; la bibliothèque « compiler » qui permet de compiler à la volée, et ainsi d'obtenir une accélération significative de l'exécution des scripts ; et la bibliothèque « parallel » qui, comme son nom l'indique, implémente un embryon de programmation multi-threads (seulement sous les systèmes permettant fork()).

Il est évidemment impossible de faire une liste exhaustive des avantages réels ou supposés de R ; on peut citer :

La portabilité (GNU/Linux, BSD, Mac OS X et Windows) ;
La profusion de paquets contribués ;
Sa large diffusion (savoir coder en R est une condition souvent requise pour un job de bio-informaticien) ;
La richesse du langage de base (plusieurs milliers de fonctions disponibles sans installation de paquets) ;
La concision du code ;
La qualité de la documentation (un système automatique vérifie que chaque fonction est correctement documentée lors de la compilation des paquets).

Évidemment, on peut jouer l'avocat du diable et lister les écueils :

Un manque d'homogénéité du fait du mode de développement modulaire (pas de conventions officielles sur le nommage, les indentations, etc.) ;
Illisible si mal codé (en particulier du fait de l'imbrication des parenthèses, crochets courbes et carrés) ;
Courbe d'apprentissage assez abrupte ;
Idiomes différents de ceux du C (par exemple, les boucles for() sont à proscrire la plupart du temps).

Un exemple valant toujours mieux qu'une longue explication :

# Rien que du classique
print("Hello world!")

# Import-export
data <- read.csv("mySpreadsheet.csv")
write.table(data, "textfile.txt", sep="\t")

# Manipulation de données: 
#  on ne garde que les lignes du tableau dont la deuxième colonne 
#  est supérieure à la moyenne
data2 <- data[data[,2]>mean(data[,2]),]

#  on ajoute une colonne avec la médiane de chaque ligne
data3 <- cbind(data, apply(data, MARGIN=1, FUN=median))

# Production de graphiques et statistiques: 
#  régression x: première colonne, y:dernière colonne
pdf("myplot.pdf")
plot(data[,1], data[,ncol(data)], xlab="x", ylab="y")
abline(lm(data[,ncol(data)] ~ data[,1]))
dev.off()

Aller plus loin

Page officielle du projet R (366 clics)
Liste des paquets disponibles (74 clics)
R graph gallery : illustration des possibilités graphiques de R (418 clics)

# Avocat du Diable ?

Posté par Le Pnume le 04 avril 2013 à 23:24. Évalué à 10.

Idiomes différents de ceux du C (par exemple, les boucles for() sont à proscrire la plupart du temps)

La vectorisation dans R est un vrai régale et permet très souvent d'écrire du code concis et facile à lire (vive by, apply et consort) mais il y a beaucoup de situations ou le "for" est incontournable.

De plus, tu indiques que la courbe de progression est abrupt et je suis plutôt d'accord mais justement pour quelqu'un qui débute et qui a des bases dans des langage plus conventionnels, elles permettent de faire ces 1ere armes, puis de les remplacer progressivement quand elles ne sont pas nécessaire.

J'ajouterais un petit lien vers le forum francophone de utilisateurs de R qui est une mine d'information et d'aide : Forum des utilisateurs de R

amicalement
- [^] # Re: Avocat du Diable ?
  
  Posté par arnaudus le 05 avril 2013 à 09:12. Évalué à 3.
  mais il y a beaucoup de situations ou le "for" est incontournable.
  
  Mouais, en fait, le "for" de R est un "foreach", c'est dans ce contexte qu'il peut être pratique (je conviens que "proscrire" était trop fort). Mais dans les faits, il est quand même difficile de trouver des cas où il est incontournable. Personnellement, je m'en sers souvent quand il n'y a pas de problème de performance, car ça reste très lisible. Il n'y a qu'une situation où je n'arrive pas à m'en passer (et où je ne pense pas qu'on puisse optimiser), c'est quelque chose comme:
```
x <- 0
for(i in 1:100)
    x <- do.something(i,x)
```
  pour quelqu'un qui débute et qui a des bases dans des langage plus conventionnels, elles permettent de faire ces 1ere armes, puis de les remplacer progressivement quand elles ne sont pas nécessaires.
  
  Ah oui, clairement. On peut coder à la C en R, puis progressivement progresser dans les idiomes propres au langage. Ceci dit, je trouve qu'on manque beaucoup de ressources sur "comment faire ci ou ça proprement en R". Comme il n'y a pas de style conventionnel en R et que la plupart des utilisateurs sont des bricoleurs (pas péjoratif), il est très difficile de savoir si on fait les choses correctement ou pas, et ça ralentit pas mal la progression. Sans compter que l'interpréteur est peut-être un peu trop sympa.
  - [^] # Re: Avocat du Diable ?
    
    Posté par lolop (site web personnel) le 05 avril 2013 à 10:24. Évalué à 3.
    
    Y'a pas un équivalent du reduce de Python en R ?
    
    Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
    - [^] # Re: Avocat du Diable ?
      
      Posté par arnaudus le 05 avril 2013 à 10:46. Évalué à 2.
      Apparemment, R a quelques fonctions "fonctionnelles" dans la syntaxe de base :
      
      Reduce(f, x, init, right = FALSE, accumulate = FALSE) Filter(f, x) Find(f, x, right = FALSE, nomatch = NULL) Map(f, ...) Negate(f) Position(f, x, right = FALSE, nomatch = NA_integer_)
      
      J'avoue que je ne sais pas m'en servir et qu'elles pourraient très bien correspondre au besoin exprimé plus haut.
    - [^] # Re: Avocat du Diable ?
      
      Posté par Le Pnume le 05 avril 2013 à 11:04. Évalué à 1.
      
      oui c'est la fonction Reduce
  - [^] # Re: Avocat du Diable ?
    
    Posté par Maclag le 05 avril 2013 à 19:42. Évalué à 5.
    
    Comme il n'y a pas de style conventionnel en R et que la plupart des utilisateurs sont des bricoleurs (pas péjoratif), il est très difficile de savoir si on fait les choses correctement ou pas,
    
    Je confirme! Je ne suis pas développeur et j'ai eu besoin d'une chiadée de scripts pour faire de l'analyse statistique de données en volume.
    C'est fou ce qu'on découvre à quel point son code est mauvais le jour où on doit changer "juste une petite bricole" et que… on peut pas! Réécriture complète!
# Utilisation

Posté par gnumdk (site web personnel) le 05 avril 2013 à 08:01. Évalué à 5.

Il est très utilisé dans les formations d'ingénieurs, en agronomie par exemple.
- [^] # Re: Utilisation
  
  Posté par Thierry Thomas (site web personnel, Mastodon) le 05 avril 2013 à 12:02. Évalué à 2.
  
  Et même en psychologie !
- [^] # Re: Utilisation
  
  Posté par scls19fr (site web personnel) le 05 avril 2013 à 12:13. Évalué à 3.
  
  Quels sont les avantage de R par rapport à Python + Numpy + Scipy + Pandas ?
  
  PS: c'est une vraie question… pas un troll !
  - [^] # Re: Utilisation
    
    Posté par lolop (site web personnel) le 05 avril 2013 à 13:02. Évalué à 4.
    
    De discussions avec certains chercheurs autour de moi qui ont parfois à utiliser R, le gros avantage est l'utilisation par la communauté de statisticiens, et donc le nombre de programme R déjà écrits dans ce domaine.
    
    Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
  - [^] # Re: Utilisation
    
    Posté par arnaudus le 05 avril 2013 à 13:21. Évalué à 3.
    Bah, si c'est une vraie question, je dirais 1) les milliers de paquets contribués, et 2) R c'est R tout court, pas R + machin + truc + bidule. Dans le cœur de R, tu as les fonctions graphiques, les analyses statistiques courantes (régressions linéaires, ACP, anova…), les nombres aléatoires, etc.
    
    Après, c'est évident qu'avec des bibliothèques, on peut faire de l'algèbre linéaire en C ou créer des PDF en perl. L'avantage d'utiliser un outil conçu pour une tâche principale est la simplicité de prise en main, et l'efficacité. Si je veux savoir à quoi ressemble la courbe y=x log(x+1), j'ouvre un terminal, je tape "R", puis :
```
curve(x*log(x+1), xlim=c(-2,2))
```
    Après, je connais plus R que python, et j'imagine qu'il y a beaucoup de situations où il n'est pas nécessaire d'apprendre un nouveau langage quand on sait déja faire avec ce qu'on a.
    
    En tout cas, R est à mon avis un excellent outil pédagogique pour débuter la programmation.
  - [^] # Re: Utilisation
    
    Posté par ckyl le 05 avril 2013 à 13:37. Évalué à 8. Dernière modification le 05 avril 2013 à 13:39.
    
    Quels sont les avantage de R par rapport à Python + Numpy + Scipy + Pandas ?
    
    Empêcher les statisticiens de bricoler des trucs qui vont finir en production ou que quelqu'un va avoir à maintenir ? ;)
    - [^] # Re: Utilisation
      
      Posté par jben le 08 avril 2013 à 23:23. Évalué à 2.
      
      Tout de suite…
      
      Bon c'est vrai que quand on regarde ce qui traine sur les dépots, des fois on a peur. Par contre l'avantage c'est que c'est devenu de facto un standard parmis les statisticiens qui développent de nouvelles méthodes. Le fait qu'un standard soit basé sur un logiciel quasi-libre, avec la majorité des codes publiés sous licence quasi-libre ou vraiment libre, c'est quand même un très bon point pour le logiciel libre.
      
      Warning : Troll inside.
      - [^] # Re: Utilisation
        
        Posté par ckyl le 09 avril 2013 à 00:20. Évalué à 2. Dernière modification le 09 avril 2013 à 00:22.
        
        Tout de suite…
        
        En dehors du trait d'humour il n'y a rien de méchant dans mes paroles.
        
        Informaticien et statisticien sont deux métiers différents qui se rencontrent de plus en plus au sein des projets. Les profils techniques et les outils utlisés par les statisticiens sont assez diverses.
        
        La où ca devient dangereux c'est quand les statisticiens commencent à pousser des trucs que la partie technique n'a pas le temps de valider ou de refaire. Là ca court rapidement à la cata car on ne fait pas du tout la même chose et pas de la même facon. Par exemple la semaine dernière j'ai rattrapé un job Hadoop streaming avant qu'il ne soit poussé en prod: le mapper faisait 80 lignes de awk bidouillées sans connaitre les préconditions sur les données, sans tests, sans remonté de métriques. L'écrire proprement et le valider ca nous demande une semaine mais on sait ce qu'il fait, ce qu'il fera, comment il réagira en cas d'erreur dans la chaîne etc.
        
        En ca les gens qui font du R sont moins tentés de jouer à la pieuvre. Ceux qui font du python ont plus tendence à laisser trainer des scripts écrit à la va vite (et c'est normal) partout (moins normal). La séparation prospection / prod est moins nette.
  - [^] # Re: Utilisation
    
    Posté par Alex G. le 05 avril 2013 à 14:52. Évalué à 2.
    
    Y a aussi R depuis python :-)
    
    http://ipython.org/ipython-doc/rel-0.13.1/config/extensions/rmagic.html?highlight=rmagic#IPython.extensions.rmagic
    
    ou http://rpy.sourceforge.net/
    - [^] # Re: Utilisation
      
      Posté par Michaël Malter (site web personnel) le 06 avril 2013 à 00:42. Évalué à -2.
      
      R est très lent en comparaison avec à peu près tout ses concurrents…
      - [^] # Re: Utilisation
        
        Posté par jben le 08 avril 2013 à 23:17. Évalué à 3.
        
        Ah ? Tu as infos à faire partager ?
        
        Parce qu'en vrai pour le calcul vectorier/matriciel, GNU R, comme GNU Octave, Scilab, Numpy/Scipy, MATLAB, etc. utilise des appels à lapack et à blas. Même si tu implémentes dans un laguage compilé genre C++, tu fera appel au même libs (je pense à IT++, armadillo qui font appel à blas et lapack). Après il y a quelques recopies qu'on pourrait éviter avec des usages futés, mais très peu si on ne code pas comme un porc.
        
        Après si tu fais des boucles, quelque soit le language interprété c'est lent. Il est clair que GNU R ne s'en sort pas très bien mais c'est pas la catastrophe complète non plus. De toutes façon quand on fait des boucles avec GNU R, GNU Octave… ben… voila.
      - [^] # Re: Utilisation
        
        Posté par arnaudus le 19 avril 2013 à 12:42. Évalué à 2.
        
        R est très lent en comparaison avec à peu près tout ses concurrents…
        
        Seulement si on ne sait pas coder en R. C'est sûr que si ton code est truffé de boucles for et de fonctions récursives, tu peux aller te faire un café avant d'avoir tes résultats, mais il faut un minimum connaitre les paradigmes de chaque langage pour être efficace.
  - [^] # Re: Utilisation
    
    Posté par Thom (site web personnel) le 06 avril 2013 à 15:05. Évalué à 9. Dernière modification le 06 avril 2013 à 15:08.
    Un des gros avantages de R pour les personnes n'ayant que très peu de connaissance en programmation à la base est que R reste un outils simple. On est à la limite du framework et pour peu que l'on travail sur Windows, l'IDE est même pas mal du tout. Sur Linux, on s'en sert plus comme de python, sans ide et tout à l'éditeur de texte et au lancé de script.
    
    R est bien souvent utilisé de cette manière.
    - On récupère les données très simplement à partir d'un txt, cvs en une ligne de code en spécifiant, les espaces entre les données, les données manquantes, les titres des colonnes avec read.table …
    - On fait son opération en quelques lignes : anova, corrélation, chi2, shapiro, krustal wallis, wilcoxon… la plupart des fonctions utiles sont là de base, sinon on trouve le package qui faut…
    - Et ensuite on sort un graph en 2/2 et les données en autant de temps et on export ça dans le bon format sachant que faire des graphs avec R, c'est vraiment simple et puissant.
    Bref, c'est commode. Et en plus les personnes utilisant R souvent commencent par aimer ce langage, et d'une manière générale commencent à apprécié la programmation (sans pour autant être informaticien à la base) or pour faire du python, à la base, il faut aimer l'informatique. Dans R tu peux faire des fonctions et des trucs un peu plus "top moumoute" quand tu commences à gérer, mais le plus rapide, c'est de faire du petit script perso et limite sale. Comme ce n'est pas utilisé que par des informaticiens, c'est un peu plus souple sur la tolérance au code moche. Typiquement, tu ne peux pas écrire du R comme du c++.
    
    Aller hop un exemple (sans les données) et un peu dans le désordre :
    
    Importation - Deux lignes :
```
# DISTANCE ENTRE LES NOYAUX
dist_noy_foe <- read.table("dist_noy_foe.txt", header = FALSE, sep = ";", dec=",")
colnames(dist_noy_foe) = c("p1.a", "p1.b", "p2.a", "p2.b", "c1.a", "c1.b")
```
    Test - une ligne + une ligne pour tout sortir bien au propre dans un fichier texte :
```
#Pour tout sortir dans un fichier
sink(file = "sink-ad.txt")

# Test sur les ensembles de 10
kruskal.test(c(dist_noy_ad$p1.a, dist_noy_ad$p2.a, dist_noy_ad$p3.a, dist_noy_ad$p4.a, dist_noy_ad$p5.a, dist_noy_ad$p6.a, dist_noy_ad$p7.a, dist_noy_ad$p8.a, dist_noy_ad$c1.a, dist_noy_ad$c2.a)~gp_ad_10)
```
    Affichage - rapide pour du Quick and Dirty - et toujours pas trop compliqué si on veut avoir un graph un peu plus sympa :
```
#Nouvelle fenêtre graphique
x11()

# On crée une liste comportant tous les éléments qu'on souhaite affiché pour la distance
l_foe_dist_a_2 = c(foe_dist$p1.a, foe_dist$c1.a)
# pour la volume
l_foe_vol_a_2 = c(foe_vol$p1.a, foe_vol$c1.a)

# Paramètres couleurs - voir colors() ou ? colors()
# On liste les couleurs souhaitées pour le nombre d'éléments de la liste.
# Dans notre cas les 60 premiers seront violet et les 60 prochains seront gris
l_long_foe_col_2 = c(rep("purple", long_foe), rep("darkgrey", long_foe))
# Paramètres formes - voir - ?pch
# On liste les formes des points souhaitées pour le nombre d'éléments de la liste.
# Dans notre cas les 60 premiers seront carrés et les 60 prochains seront en losange
l_long_foe_pch_2 = c(rep(15, long_foe), rep(18, long_foe))

#Graphe

# On crée une grille 2 par 2
mat = matrix(data = c(1,2,3,4), nrow = 2, ncol = 2)
# Avec le nuage de point 2 fois plus haut et plus large
layout(mat, widths = c(2,1), heights = c(2,1))

#Jitter permet de rajouter un bruit (uniquement pour le graphe)
# pour éviter d'avoir les données que sur une même ligne
# On ne met du bruit que pour les distances en abscisse
plot(jitter(l_foe_dist_a_2), l_foe_vol_a_2, pch = l_long_foe_pch_2, col = l_long_foe_col_2, xlab="Distance", ylab="Volume", main="Foetus - A") 

#On rajoute une grille rouge de 7 lignes pointillées pour mieux encadrer
grid(nx = 7, ny = 7, col = "red", lty = "dotted")

#On ajoute un barplot en bas pour les distances
boxplot(foe_dist$p1.a, foe_dist$c1.a, horizontal=TRUE, col=c("purple", "darkgrey"), legend.text=TRUE, main="DIST")
#On ajoute un barplot à droite pour les volumes
boxplot(foe_vol$p1.a, foe_vol$c1.a, horizontal=FALSE, col=c("purple", "darkgrey"),legend.text=TRUE, main="VOL")
#On crée un graph vide pour ajouter la légende
plot(1, type="n", axes=F, xlab="", ylab="")
legend("topright", legend = c("p1", "c1"), col = c("purple", "darkgrey"), 
pch = c(15, 18), bty = "n", pt.cex = 2, cex = 0.8, text.col = "black", horiz = TRUE, inset = c(0.1, 0.1))
```
    Et paf le résultat :
    
    La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
# grammar nazi

Posté par ariasuni le 05 avril 2013 à 08:35. Évalué à 9.

«crochets courbes et carrés»

Cela semble une traduction maladroite de l'anglais «curly and square brackets», c'est à dire «accolades et crochets».

(phrase-qui-meuble-pour-ne-pas-passe-pour-un-grammar-nazi:) Sinon c'est pas mal de voir un langage qui sort un peu de l'ordinaire (par rapport aux C, C++, Java et autres Python).

Écrit en Bépo selon l’orthographe de 1990
- [^] # Re: grammar nazi
  
  Posté par arnaudus le 05 avril 2013 à 09:18. Évalué à -1.
  
  Bah, je ne suis pas sûr qu'il existe une traduction satisfaisante. Pour moi, { et } sont des crochets ou des parenthèses en forme d'accolades, mais ce ne sont pas des accolades à proprement parler (une accolade sert à accoler des trucs sur plusieurs lignes).
  
  En plus, en maths classiques, les crochets ont souvent une sémantique de parenthèses, comme dans x(x+y[x+2]), par exemple, du coup, je n'ai pas de problème à les appeler "parenthèses carrées", ou quelque chose comme ça.
  - [^] # Re: grammar nazi
    
    Posté par Tit le 05 avril 2013 à 10:11. Évalué à 10. Dernière modification le 05 avril 2013 à 10:16.
    
    Pour moi { } [ ] ( ) sont des signes de ponctuation qui ont en français un nom bien déterminés (accolade, parenthèse, crochet) et c'est vachement plus simple et compréhensible d'utiliser ces termes là que d'aller chercher des périphrases qui changent à chaque fois (si j'ai bien compris les accolades tu les appelles soit "crochets courbes", soit "parenthèses en forme d'accolades" et les crochets tu les appelles soit "crochets carrés" soit "parenthèses carrés"…
    
    Sinon, je ne connais pas R, est-ce qu'on peut faire une comparaison avec scilab dans la production de graphiques, par exemple plusieurs nuages de points avec de coubes de régression, des variances etc ?
    - [^] # Re: grammar nazi
      
      Posté par arnaudus le 05 avril 2013 à 10:38. Évalué à 6.
      
      Je ne connais pas scilab, donc c'est difficile de faire une comparaison :-) Apparemment, scilab est dans l'esprit proche de matlab, qui est un concurrent "officiel" de R. J'ai l'impression que matlab/scilab sont un peu plus orientés "calcul numérique", mais j'imagine qu'on peut faire avec l'un ce qu'on fait avec l'autre.
      
      Par exemple, R n'est probablement pas le meilleur choix pour du calcul numérique intensif. Par contre, il existe de nombreuses bibliothèques qui permettent d'interfacer R avec des outils adaptés, comme ADMB, ou Jags (pour des trucs Bayesiens). Personnellement, je me sers de R comme d'une boite à outils multifonctions : calculatrice scientifique, shell, manipulation de données, manipulation de fichiers, production de graphiques, production de tables en Latex, simulations stochastiques, et outil de scriptage générique. Évidemment, on peut toujours trouver plus adapté ; par exemple, pour convertir un format de fichier dans un autre format, mieux vaudrait utiliser perl, pour appeler une série d'exécutables externes, mieux vaut utiliser bash, etc. Mais l'utilisation d'un seul langage est quand même pratique.
      
      En tout cas, je trouve R magique pour la production scientifique. Avec un seul script, je lis les données brutes, les analyse, produit les figures et les tables. Un coup de Latex, et l'article entier est recompilé. Si on veut à la dernière minute changer quelque chose dans l'analyse, ça prend 2 minutes de tout refaire, y compris les figures (évidemment, si ça change les résultats, il faut réécrire l'article, ce que R ne sait pas encore faire :-) ).
      - [^] # Re: grammar nazi
        
        Posté par Tit le 05 avril 2013 à 11:43. Évalué à 2.
        
        Merci, ça a l'air intéressant. est-ce que tu as des docs/tutoriels en français à conseiller?
        
        [^] # Re: grammar nazi
        
        Posté par arnaudus le 05 avril 2013 à 13:23. Évalué à 2.
        
        Il y a un lien quelques milliers de pixels plus haut dans la discussion : http://linuxfr.org/nodes/97618/comments/1442509 .
        
        [^] # Re: grammar nazi
        
        Posté par marquis le 05 avril 2013 à 15:56. Évalué à 2.
        
        Je confirme que la génération de document Latex incluant du code R est d'une puissance "miraculeuse".
        Si mes souvenirs sont bons, le nom de code magique est : Sweave
        
        http://www.stat.uni-muenchen.de/~leisch/Sweave/
        http://en.wikipedia.org/wiki/Sweave
        
        très, très utile pour générer des rapports stats automatisés …
# R: langage statistique puissant et performant

Posté par NanoTech le 05 avril 2013 à 11:32. Évalué à 5.

J'essaie de convaincre les professionnels de santé de mon labo d'utiliser R plutôt que SAS ou STATA qui ont des licences restrictives et onéreuses.

R n'est pas un langage généraliste, mais adapté à l'analyse statistique et au calcul vectoriel sur des bases de données.
Les vecteurs étant typés, il a une petite empreinte mémoire et des bonnes performances pour calculer sur des millions d'enregistrements.

La courbe d'apprentissage m'a paru correcte puisque j'ai pris en main le langage en quelques heures. Les nombreux paramètres optionnels permettent de se concentrer sur l'essentiel.

J'ai trouvé le module RODBC très commode pour mélanger SQL et R, l'alternative étant d'utiliser des grosses data.frame.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.