1. #1
    Membre éclairé

    Homme Profil pro
    Enseignant Chercheur
    Inscrit en
    septembre 2007
    Messages
    200
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Enseignant Chercheur
    Secteur : Santé

    Informations forums :
    Inscription : septembre 2007
    Messages : 200
    Points : 714
    Points
    714

    Par défaut [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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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, ...)

  2. #2
    Membre à l'essai
    Homme Profil pro
    Statisticien
    Inscrit en
    juillet 2013
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Statisticien
    Secteur : Industrie

    Informations forums :
    Inscription : juillet 2013
    Messages : 6
    Points : 10
    Points
    10

    Par défaut 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

  3. #3
    Membre éclairé

    Homme Profil pro
    Enseignant Chercheur
    Inscrit en
    septembre 2007
    Messages
    200
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Enseignant Chercheur
    Secteur : Santé

    Informations forums :
    Inscription : septembre 2007
    Messages : 200
    Points : 714
    Points
    714

    Par défaut

    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 :
    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.

  4. #4
    Membre à l'essai
    Homme Profil pro
    IE collecte et analyse de données
    Inscrit en
    septembre 2013
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : IE collecte et analyse de données

    Informations forums :
    Inscription : septembre 2013
    Messages : 6
    Points : 14
    Points
    14

    Par défaut

    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 : 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
    ##
    ## 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 : 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
    ##
    ##
    ##
    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 : 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
    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 : 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
    ##
    ## 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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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.

Discussions similaires

  1. Opérateur de statistique
    Par Phil951 dans le forum Langage SQL
    Réponses: 6
    Dernier message: 26/01/2004, 16h12
  2. Analyseur de code (statistique)
    Par Boons dans le forum Choisir un environnement de développement
    Réponses: 9
    Dernier message: 13/08/2003, 13h22

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo