[En vrac] 6. Statistiques

6 Statistiques

6.1 Arrondis

Pas de truc genre « floor ». Pas non plus de conversion automatique d’un numeric 2.5 en integer 2 en lui coupant les ailes (cela déclencherait une erreur) . Par contre, round() peut renvoyer un numeric ou un integer, selon le besoin.
Code:

1 2 3 4 5 > a.round(3) // au plus proche, avec 3 décimales > a.roundUp() // au supérieur, avec 0 décimales > a.roundUp(typeOut<-integer) // au supérieur, avec 0 décimales > a.roundDown(2) // à l’inférieur, avec 2 décimales > a.roundTowardsZero(2) // vers zéro, avec 2 décimales
6.2 Bad

Permettre des choses "déconseillées" en statistique, mais avec l’instruction « bad » devant. Par exemple, pour faire un camembert, « pie » n’existe pas, mais « bad_pie » existe.
Code:

1 2 3 > barplot(ufr) > bad_pie(ufr) > badbad_pie3d(ufr)
6.3 Intercept

Y~X NE doit PAS être Y~1+X. Si on veut un intercept, on doit le demander.

6.4 Par sous groupe

Toutes les stats doivent être également disponible « par groupe ». Par exemple :
Code:

1 2 > mean(age) // Donne la moyenne des ages > mean(age~sexe) // Donne la moyenne des ages de chaque sexe
6.5 Statistiques descriptives

Il faut deux fonctions :

summary donnera l'essentiel (moyenne, écart type, quartile)
analyse sera beaucoup plus exhaustive (moyenne, écart type, variance, écart moyen, quartiles, déciles, ...)

Sous-groupes

Dans la proc Summary, SAS permet des choses assez utiles et fines, dont je me demande s'il faut les récupérer.
Quand il y a D variables pour conditionner la statistique, SAS calcule par défaut les 2^D groupes de statistiques conditionnelles : celui où les modalités des D variables sont croisées, ..., et celui où on fait juste le calcul global. Et en plus on peut raffiner encore un peu.
Pour plus de détails :
http://support.sas.com/documentation...a000146737.htm

Oui, c'est une remarque que des utilisateurs de SAS m'ont faite : le summary de R est moins complet. C'est pour cela que je propose deux fonctions différentes, summary et analyse.

Mais c'est clair qu'on pourra aller encore plus loin.

Personnellement, j'avais dans l'idée de faire un summaryBiv qui présenterait tout un tas de résultat "relativement" à une variable. Ainsi :

Code:

summaryBiv(dn~sexe)

donnerait un résumé de dn pour homme, un résumé pour femme, éventuellement testerait l’existence de lien entre sexe et les variables de dn, and so on...

Par contre, il faudra qu'il y ait une vraie discussion du groupe "statistique" (R++ V0.4a) pour voir ce dont on a vraiment besoin, et ce qui viendrait juste encombrer le langage.

Effectivement, il me semble qu'il y aurait des choses à reprendre de proc summary. De proc freq aussi.

Mais je ne pense pas qu'il faille ajouter une fonction spécifique pour faire les calcul conditionnellement à d'autres variables. Pour cela, il suffit d'utiliser le polymorphisme avec une formule y ~ x . Ce qui pourrait avoir pour effet d'ajouter d'autres statistiques comme le test de différence de moyennes (en prenant en compte les différences de variance :-)).
Le principe pourrait d'ailleurs être généralisé à d'autres fonction comme corr(y ~ x) pour calculer le coefficient de corrélation partiel.

Néanmoins, les sorties de proc summary et proc freq peuvent être très verbeuses. Pour faciliter leur utilisation, il serait utile de proposer une interface permettant de les paramètrer à volonté. De plus, on devrait pouvoir rajouter des méthodes facilement.

J'en ai profité pour réfléchir à la systématisation des méthodes d'introspection en essayant d'appliquer le principe du "changer juste ce qu'il faut".

Note :
- "::" désigne un namespace
- "@" désigne un appel de méthode|fonction (cf. les slots des méthodes s4)
- "self" : comme en python (ou this en java)

De plus, "fonction" et "méthode" sont utilisé ici de façon quasi interchangeable. Il me semble néanmoins qu'il serait nécessaire de clairement les distinguer, cette distinction pouvant se révéler utile dans le cadre du langage.
Code:

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 ## ## Méthode d'introspection permettant d'obtenir la liste des statistiques disponibles ## ## Retourne la liste des symboles définit dans le namespace "stat" de la classe "summary" ## ## Groupes : ## "base" : stats disponibles dans le package de base ## "user" : stats ajoutées par l'utilisateur dans le cadre de sa session ## "default" : stats calculées par défaut ## "all" : toutes les stats couramment disponibles ## ## Ces groupes ne sont pas exclusifs. Une partie (ou la totalité) des membres de "base"et de "user" peuvent appartenir à "default" ## ## Il faudrait peut-être distinguer les méthodes univariées das méthodes bivariées (cf. y ~ x) ## summary::stat@list( group = "all" ## "default", "base", "user" ) ## "mean", "std.err", "t", "Kolmogorov" [...] ## ## Applique la fonction summary() à la variable y de src conditionnellement à x en listant les stats à retourner ## ## summary::* est optionnel ## summary( y ~ x, data = src, env = summary::stat@include <- (...) ) ## Exclusion de méthodes summary( y ~ x, src, env = stat@exclude <- (...) ) ## Ou bien redéfinition globale summary::stat@include() <- (...) ## Réstauration de l'environnement par défaut summary::stat::default@restore()
Il me semble que les deux arguments include et exclude devraient être exlusifs.

Manipulation :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 ## ## ## x.summary <- summary(x, src) ## Appel des méthodes génériques pour représenter les différents objets contenus dans x.summary ## ## Méthode et fonction ## ## Sélection d'n subset de l'objet (méthode) : modification de l'objet x.summary ## À ce niveau-là, un méchanisme de copy-on-write pourrait s'avérer judicieux x.summary::stat@include <- ( ... ) ## Copie d'un subset (fonction) : x.summary est seulement lu x.subsummary <- x.summary::stat@include( ... ) ## plot( x.summary ## , env = stat@include <- (...) ## Sélection )
La même chose pour les tables
Code:

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 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 ## ## ## table::stat@list( group = "default" ## "all", "base", "user" ) ## "freq" "pct", "row.pct", "col.pct", "chi" [...] ## table( y ~ x, data = src, env = stat@include <- ("freq", "row.pct", "chi") ) ## ## Ajout d'une fonction descriptive : le coefficient de corrélation polychorique ## ## Cette stat est calculée par défaut (-ie : sauf stat@exclude() <- "polychor") ## table::stat@add(default=TRUE ) <- polychor( <option:arguments-par-défaut> ) ## Ou bien ajout au moyen d'une fonction anonyme : table::stat@add("polychor", replace=TRUE) <- compile( function(...){} ) ## Passe une référence à la fonction polychor ## (-ie: toute modification de fonction dans l'environnement courant sera prise en compte lors l'appel de cette fonction par summary() ## Dans le cas de figure précédent, l'intégralité de la fonction est copié à la condition qu'elle ait déjà été compilée, sinon, erreur ## table::stat@add(default=TRUE ) <- polychor::object@ref() ## table::stat@list( group = "user" ) ## "polychor" ## table( "y" , data = src ## les arguments des méthodes sont transmis au moyen de named vectors , env = stat::( @include <- ("chi", "polychor") , chi::args@set <- (p.val = .01) , polychor::args@set <- (iter.max= 100) ## estimation par le maximum de vraissemblance ) ) ## Suppression de la méthode du namespace stat de summary : table::stat@rm("polychor") ## ## La même chose mais sans ajouter la méthode globalement ## table( "y" , data = src ## , env = stat@( add <- polychor(method="MAP") ## ajoute polychor estimé par la méthode bayesienne du maximum a posteriori , include <- ("chi") ## polychor est inclue par défaut (quel intérêt sinon ?) ) )
Et puis tant qu'on y est...
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ## ## Création d'un environnement spécifique pour table ## table.env <- table::stat@( include(...) <- ... , add(...) <- ... ) ## ## R utilise souvent le symbole "rho" dans ce cas. Mais il faut être familier de la littérature pour savoir que la lettre grecque "rho" désigne un environnement ## table( x, src , env = table.env ## modifie le slot "table" dans l'environnement d'exécution )
La syntaxe "env =" devrait être suffisante du fait du polymorphisme : le compilateur devrait pouvoir être en mesure de comprendre tout seul qu'il ne s'agit pas d'un environnement complet mais seulement un élément de celui-ci et ne modifier que ce qui est nécessaire dans l'environnement généré pour l'exécution. Et cette ramarque vaut pour les utilisation de env dans les appel de fonction précédents.

En somme, l'idée est de combiner les praradigmes fonctionnels et OO : les fonctions peuvent prendre des fonctions en arguments et leur évaluation est retardée pour mettre à jour les objets dans un contexte d'exécution donné.

Par exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 ## table( "y" , data = src ## , env = stat@( add <- polychor(method="MAP") ## ajoute polychor estimé par la méthode bayesienne du maximum a posteriori , include <- ("chi") ## polychor est inclue par défaut (quel intérêt sinon ?) ) )
Dans ce cas, les appels de méthodes ont lieu dans la fonction pour modifier une image (et non une copie) de l'env de l'appel de fonction, l'environnement parent n'étant, lui, pas modifié.
Ce genre de manipulations est déjà possible dans R mais cela demande une bonne connaissance du langage. Procéder de la sorte permet de fournir une interface plus abstraite tout en donnant un contrôle plus fin.