Discussion :

[grunt2000]

Bonjour,


Je débute sous R, j'ai écrit deux fonctions :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
# Quand on a une loi normale aux paramètres connus,
# Quelle est la probabilité qu'un échantillon ait une moyenne [inférieure | supérieure] à une moyenne de population ?
pnorm_mean_ech_infsup_mean_pop_ms_s <- function(moyenne, moyenne_echantillon, ecart_type_echantillon, inferieur) {
  if (class(moyenne) != "numeric") {
    stop("La moyenne de la loi normale (mu) doit contenir un nombre.")
  }
 
  if (class(ecart_type_echantillon) != "numeric") {
    stop("L'écart-type de l'échantillon doit contenir un nombre.")
  }
 
  if (class(moyenne_echantillon) != "numeric") {
    stop("La moyenne de l'échantillon doit contenir un nombre.")
  }
 
  if (class(inferieur) != "logical") {
    stop("Le paramètre inferieur doit contenir un booléen.");
  }
 
  # Centrer réduire.
  z <- (moyenne - moyenne_echantillon) / ecart_type_echantillon;
 
  if (inferieur) {
    return(pnorm(z));
  }
  else {
    return(1 - pnorm(z));
  }
}
 
# Quand on a une loi normale aux paramètres connus,
# Quelle est la probabilité qu'un échantillon ait une moyenne [inférieure | supérieure] à une moyenne de population ?
pnorm_mean_ech_infsup_mean_pop_sn <- function(moyenne, ecart_type, moyenne_echantillon, n, inferieur) {
  if (!check.integer(n)) {
    stop("Le nombre d'individus de l'échantillon doit être un entier.")
  }
 
  ecart_type_echantillon = ecart_type / sqrt(n);
  return(pnorm_mean_ech_infsup_mean_pop_ms_s(moyenne, moyenne_echantillon, ecart_type_echantillon, inferieur));
}

que je peux exécuter ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
pnorm_mean_ech_infsup_mean_pop_ms_s(12600, 13500, 452.5, inferieur=TRUE);
pnorm_mean_ech_infsup_mean_pop_sn(12600, 3200, moyenne_echantillon= 13500, n=50, inferieur=TRUE);

Le code doit sûrement paraître jeune, mais je débute avec R. Je n'ai pas acquis les bonnes pratiques encore.
J'ai trois questions :


1) R soutient le polymorphisme d'après sa documentation, mais ces deux fonctions je ne parviens pas à les rassembler sous le même nom : pnorm_mean_ech_infsup_mean_pop, par exemple, bien qu'elles aient des paramètres différents.
Ca ne fonctionne pas. En Java ou C++, je sais le faire, mais là en R, je n'y arrive pas.

2) Typage fort : je veux que les types de certains paramètres soient vérifiés dès la compilation.
Toujours, cela je sais le faire en Java ou C++.
Là, je n'y suis pas parvenu non plus et je dois passer par des expédients lourds dans mon code,
et ces contrôles de type n'ont lieu qu'à l'exécution. Ce n'est pas ce que je veux. Comment faire.


3) Je n'ai pas trouvé la documentation pour apprendre comment documenter une fonction.
Si. j'ai vu des annotations @param, etc.
Mais quand après je passe sur RStudio au dessus de ma fonction ou que je fais
?pnorm_mean_ech_infsup_mean_pop_sn
il ne trouve rien.

Comment documente t-on ses fonctions ?



Je vous remercie.

[Theta]

Bienvenu dans le monde foireux de R.

1) La POO existe en R mais est dans la pratique très peu utilisée, et quand elle l'est ce n'est généralement pas dans son plein potentiel comme on peut le faire en c++, java, C# etc. Perso j'ai abandonné la POO en R car j'avais l'impression que ça me posait plus de problèmes que ça en résolvait.

2) Il n'y a pas de compilation en R, qui est un langage interprété, donc pas moyen de vérifier quoi que ce soit avant l'exécution. Pas non plus de typage fort, ce qui est d'ailleurs un des plus gros problèmes du langage d'après moi, source de beaucoup d'erreurs.

3) Les fonctions d'un package doivent être documentées dans des fichiers .Rd séparés du code. Comme ce n'est pas pratique beaucoup de gens utilisent le package roxygen2 qui génère ces fichiers (entre autre) à partir de commentaires qu'on met dans le code. C'est ça les @params que tu as vu.

[faubry]

La POO est très utilisée dans R même de base mais comme tous ce qui est POO, ce n'est pas visible à tous les coups, voir par exemple les méthodes summary, plot ou anova et aussi dans de nombreux packages sophistiqués. Ce qui complique un peu les choses c'est qu'il existe deux protocoles, l'ancien dit S3 très simple à utiliser et le S4 plus complexe et proche de la manière dont c'est géré dans des langages comme Java. On trouve facilement sur la toile la documentation pour utiliser ces deux approches. Le polymorphisme existe aussi en R mais pas la notion d'héritage au sens de Java.

Le problème du typage est commun à tous les langages interprétés dont MATLAB (qui peut aussi géré des classes) et Javascript. Ce n'est pas un véritable problème, il faut simplement être attentif au lieu d'espérer que ce soit la langage qui le soit à sa place.

Enfin, il ne faut pas oublier que R est un outil pour les statistiques et le traitement des données et non pas un langage généraliste comme le peuvent être Java ou C++ et donc, il faut l'utiliser à bon escient.

Pour ce qui est ton exemple, il existe des fonctions qui teste la classe d'une variable de type is.xxx qui retourne TRUE ou FALSE (par exemple is.numeric). Pour ta question sur comment 'rassembler' la fonction en une seule, on peut facilement jouer avec l'existence ou non de certains arguments de la fonction (que l'on peut tester ou qui ne sont évalué que s'ils sont utilisés dans le corps de la fonction) et/ou les valeurs par défaut. Par exemple,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

pnorm_mean_ech_infsup_mean_pop_sn <- function(moyenne, ecart_type, moyenne_echantillon, n=1, inferieur)

fait que n vaut 1 si aucune valeur n'est donnée dans l'appel. Ce peut donc aussi être un argument supplémentaire à ta fonction pnorm_mean_ech_infsup_mean_pop_s.

A mon avis, ces trois points : valeur par défaut, évaluation tardive des arguments contrairement aux langages 'classiques' et appel possible des arguments par nom et non simplement par position sont les points forts de R mais, surtout le second point, demande un peu de pratique.

[Theta]

La POO est très utilisée dans R même de base mais comme tous ce qui est POO, ce n'est pas visible à tous les coups, voir par exemple les méthodes summary, plot ou anova et aussi dans de nombreux packages sophistiqués.

Quand je voulais parler de la "POO pas utilisée à son plein potentiel", c'est de ses fonctions summary, plot, print etc. dont je voulais parler. Dans les packages dont j'ai lu le code source, à part ces quelques fonctions et quelques autres, il n'y avais pas de POO. Ça reste très éloigné de la façon de programmer en java/C# par exemple.

Je crois ne jamais avoir vu de package utilisant intensivement le S4 (j'ai pas non plus trop cherché, ça doit bien exister, mais ça ne m'a pas l'air majoritaire).

Après ce n'est pas forcément un gros problème en soi. En statistiques, le fonctionel est bien adapté la plupart du temps.

[faubry]

En statistiques, le fonctionel est bien adapté la plupart du temps.

Je dirais plutôt qu'en statistiques, comme dans tous les langages orientés vers des applications purement mathématiques, c'est plutôt??car
l'approche fonctionnelle qui est la plus adaptée.
Je pense que ton erreur vient du fait que pour toi l'approche objet et son implantation comme en Java, SMALLTALK... sont synonymes. De plus, la majorité des utilisations de R ne nécessitent pas de se lancer dans une programmation objet à la Java ou C++ - il est inutile de faire de l'objet pour lui-même quand on a à résoudre des problèmes de statistiques ou d'analyse des données, mais de nombreux packages sont quand même basés sur ce type de programmation S3 ou S4, dont car, MASS, nlme, lmer, emmeans... En pratique tous les packages utilisent l'approche objet - il suffit d'appliquer d'appliquer la fonction class à chaque objet on s'aperçoit alors qu'il existe aussi des objets de classe fonction, expression, matrix, vector, list, data.frame... - simplement, elle ne se traduit pas obligatoirement par la manière qu'à Java pour déclarer les classes. Il ne faut pas oublier que R est un langage pour une application particulière et de nombreux utilisateurs ne se servent que des commandes en ligne te ne développe pas vraiment de procédures, soit de manière ponctuelle pour tester certaines hypothèses, soit systématiquement. Alors commencer pas créer des objets ou des classes d'objets s'avèrent superfétatoire. Personnellement, pour moi c'est une erreur de vouloir comparer R à Java ou C++, n'ayant pas du tout les mêmes objectifs. On peut plus le rapprocher de langages permettant de construire des maquettes comme MATLAB, tout en ayant certains avantages par rapport à MATLAB dont une meilleure gestion de l'approche fonctionnelle (cf. fonctions du type apply), la gestion des packages (qu'on peut rapprocher de la notion de namespace de C++), la gestion des données et de la gestion des arguments des fonctions.