Outils pour utilisateurs

Outils du site


public:specs_specificites

Calcul des spécificités

Cette page regroupe actuellement plusieurs discussions, correspondant à différents ajouts ou corrections liés à la fonction spécificité :

  • correction du bug de la spécificité se mettant à zéro lorsque le calcul dépasse les capacités de la machine ;
  • développement d'une macro filtrant un tableau de spécificités (exemple de développement réalisé pour le stagiaire de 3e d'Alexei, et répondant à un besoin d'Yves)
  • (cf. les différentes sous-sections dans “Objectifs”).

Il ne s'agit pas à proprement parler d'une spécification des spécificités elles-mêmes.

Spécifications

Paramètres

  • indice maximum de spécificité ← préférences = 1000

Construction

À partir :

  • d'une table lexicale
  • d'une partition, avec :
    • une table lexicale
      • propriété des mots ← word
      • fmin ← 1
      • vmax ← 9999999
  • d'un sous-corpus, avec
    • un table lexicale constituée d'une colonne des fréquences du sous-corpus et d'une 2e avec les fréquence complémentaire du corpus parent

Indice de spécificité 0.0

Correction du bug de l'indice de spécificité à 0 et de la propagation de la convention +/- : #687

La fonction 'phyper' retourne des flottants de plus en plus proches de zéro suivant ses arguments (par exemple jusqu'à 1,0E-304 sur une machine Linux 64-bit standard) jusqu'au moment où elle retourne toujours le flottant 0.0 au delà. C'est la convention de 'phyper' de R qui dépend de l'architecture de la machine.

La convention du calcul des spécificités est de retourner le logarithme en base 10 du retour de phyper. Pour la valeur de phyper de 0.0, le log10 retourne bien -Inf mais le calcul R des spécificités retourne 0.0 alors qu'il devrait retourner soit -Inf, soit une valeur max conventionnelle notamment pour faciliter la lecture des graphiques (avoir des barres de spécificités de taille comparables) (retrouver le nom de la préférence TXM).

Par ailleurs, le passage par la valeur 0.0 provoque la perte de l'information de la convention +/- :
L'implémentation R du calcul des spécificités est décomposé en deux étapes :

  • étape 1 : specificities.lexicon.probabilities pour les sous-corpus et specificities.probabilities

pour les tables lexicales calculent la probabilité signée (le résultat de phyper + convention +/-)

  • étape 2 : specificities.lexicon pour les sous-corpus et specificities pour les tables lexicales calculent l'indice (en appliquant la convention du log et en maintenant la convention +/-)

Or, quand l'étape 1 produit la valeur 0.0, l'étape 2 n'a plus l'information du signe de la probabilité pour gérer la convention +/-.

solution

Dans l'étape 1 : quand phyper retourne 0.0, soit :

  • solution 1 : on retourne (+/-)convention 1.0E < -MAX EXPOSANT>
  • solution 2 : on retourne (+/-)convention 10.0
  • solution 3 : on retourne (+/-)convention d'une part et les retours bruts de phyper d'autre part

Dans l'étape 2 :

  • solution 1 : on applique le log10 habituel
  • solution 2 : si +/-10.0 on retourne +/-Inf ou +/-<INDICE SPECIF MAX> sinon applique le log10 habituel
  • solution 3 : on utilise les deux informations conventions+probabilités pour retourner le tableau de spécificités habituel

[MD] : Lors du passage au logarithme dans l'étape 2, ajouter un test pour vérifier si la probabilité vaut 0.0, si c'est le cas alors l'indice de spécificité vaut EXPOSANT_MAX, où EXPOSANT_MAX est l'exposant négatif maximum que la fonction phyper peut retourner (lié à l'architecture de la machine qui execute R).

[BP] La solution 2 me semble un bon compromis à condition de documenter très clairement ce “10.0” arbitraire dans le code. L'inconvénient de la solution 1 est de ne pas faire la différence entre une probabilité qui arriverait juste avant le seuil et une probabilité qui le dépasse. La solution 3 est plus propre mais beaucoup plus lourde ? Une 4e solution serait, lorsque la probabilité vaut 0, de calculer le signe (positif si f/t > F/T), mais sans doute est-ce plus lourd que de systématiquement passer un tableau avec toutes les conventions (solution 3).

Actuel code de specificities.R :

    spe <- specificities.lexicon.probabilities(lexicon, sublexicon);
    spelog <- matrix(0, nrow=nrow(spe), ncol=ncol(spe));
    spelog[spe < 0] <- log10(-spe[spe < 0]);
    spelog[spe > 0] <- abs(log10(spe[spe >=0])); # MD: why abs ?
    spelog[spe == 0] <- 0; # MD: why not +/-Inf ? We need to store negative and positive indexes instead of checking score sign
    spelog[is.infinite(spe)] <- 0; # MD: why not max/min specif score

Plusieurs questions :

  • pourquoi faire un abs du log des probabilités des lignes positives ?
    • BP : je pense que c'est simplement une manière de passer d'une valeur négative (un log d'un argument compris entre 0 et 1) à une valeur positive.
  • pourquoi log(proba=0) = 0 ? et ne pas mettre Inf +/- (ou la valeur max de spécif +/-)
    • BP : oui là je suis tout à fait d'accord pour dire que cela ne va pas
  • pourquoi log(proba=-Inf) = 0 ? et ne pas mettre Inf +/- (ou la valeur max de spécif +/-) (c'est possible un score de proba en Inf ?????? ça devrait rester compris entre 0 et 1)
    • BP : oui je suis étonnée comme Matthieu et je ne sais pas si je comprends bien, mais je ne vois pas pourquoi spe pourrait être infini vu qu'il doit être borné entre zéro et 1.

Actuellement, c'est le signe de la probabilité indique s'il s'agit d'un indice de spécificité positif ou négatif. Lorsque que le score vaut 0, on ne peut donc pas savoir le signe de l'indice. Une proposition est que les fonctions “specificities.lexicon.probabilities” et “specificities.probabilities” retournent un objet qui contient la matrice des probabilités ainsi que les listes d'index des indices positifs et négatifs

  • BP : oui effectivement il faut chercher une solution pour avoir le signe de la spécificité en cas de probabilité (quasi)nulle.

Sélection de mots (lignes) spécifiques

1. Usages visés :

  • avoir une AFC vue au travers des spécificités et plus lisible, par deux facteurs : moins de mots et plus sur les bords
  • avoir une forme synthétique de la table des spécifs focalisée sur les mots les plus spécifiques

Exemple de démarche :

  • construction d'une partition
  • construction d'un index sur cette partition
    • l'index est construit sur une seule propriété
  • transformation en table lexicale
  • calcul des spécificités
  • traitement par le script SelectSpecif (param x, param y, etc.)
  • contrôle du résultat à l'aide de B) et C) et éventuellement ajustements des paramètres x, y etc.(boucle)
  • utilisation du résultat
    • construire un nouvel index sur la partition pour lancer une AFC
    • etc.

2. Stratégie

Prend en entrée un résultat de spécificités

Produit A) un sous-ensemble de ses mots tel que :

  • je cherche à limiter le nombre de mots à N
  • je cherche à ce que chaque partie contribue à cette liste avec un nombre de mots à peu près équivalent
  • je cherche à ce que les mots aient un indice de spécificité pas inférieur à une valeur minimale

B) Visualisation complémentaire :

  • un diagramme en bâtons qui présente le nombre de mots retenus pour chaque partie, en ordonnant les parties par leur nombre de mots retenus.
  • Par chaque partie, afficher les mots sélectionnés
  • En mode plus simple : indiquer le nombre minimum de mots finalement retenus pour les parties.

C) moyen de mettre en évidence les lignes correspondantes dans le tableau des spécificités.

  • la mise en évidence peut être une sélection
    • grâce à une requête A|B|C de ctrl-F

Forme du résultat :

  • liste des mots réutilisable
    • moyen de reconstruire un index composé des mots correspondants

3. Implémentation

Paramètres :

  • seuil d'indice de spécificité (par défaut : 2)
  • nombre de mots les plus spécifiques à sélectionner dans une partie : par défaut 10
  • moins urgent : nombre de mots max à sélectionner en tout : par défaut 100
  • encore moins urgent : prise en compte combinée des spécificités positives et négatives (en utilisant leur magnitude) : oui/non, par défaut non

Affichage des résultats

Zone de paramétrage

Donner accès à certains paramètres dans la zone de résultats

  1. supprimer la popup (à faire)
  2. ajouter une zone des paramètres : specs_parametres_preferences_commands
    • Définir les paramètres principaux? : la propriété
    • Définir les paramètres secondaires?

Zone de résultats

Colonnes :

  • unité
  • fréquence
  • par partie :
    • sous-fréquence
    • score
  • Calculer le diagramme en bâtons des lignes sélectionnées
  • Copier : (à faire)
    • copie dans le clipboard les valeurs des TableItem des lignes sélectionnées de la Table SWT
    • affiche le clipboard dans la console
  • Chercher : ouvre l'interface de recherche dans les résultats (à faire)
  • Filtrer : ouvre l'interface de filtrage des résultats (à faire)
  • Trier : ouvre l'interface de tri des résultats (à faire)
  • Supprimer : (à faire)

Interface de tri (à faire)

Surtout pour les tri multiples

À la SmartGWT ? À la concordance TXM ? À la Calc ?

Interface de filtrage (à faire)

see also: #1570

  • BP (2020-06-05) : Pour les spécificités sur sous-corpus, je pense qu'il serait intéressant de prévoir d'autres formes de paramétrage et seuillages et défauts, plus proches de la cooccurrence (mais pas totalement identiques non plus) : par défaut n'afficher que les spécificités positives d'une part, et de score supérieure à 2 d'autre part (mais pouvoir revenir sur l'un ou l'autre de ces réglages si besoin dans certains cas). En effet, comme pour les cooccurrences, les spécificités faibles sont très encombrantes mais peu ou pas pertinentes, et les spécificités négatives sont généralement délicates à interpréter. Et pour l'export, le filtrage en limitant aux spécifs supérieures ou égales à 2 opère un allègement des résultats considérable.

Interface de recherche (à faire)

À la FF, à la toolbar Eclipse ?

  • Pattern
  • Chercher suivant
  • Chercher précédent

Accès aux données depuis l'éditeur de la spécificités

Voir les classes : Specificities et SpecificitiesEditor

  1. Retrouver l'éditeur de la spécificité
    • A) depuis l'éditeur actif et le binding Groovy : editor
    • B) depuis la sélection courante de la vue corpus : corpusViewSelection et en utilisant la méthode SWTEditorsUtils.getEditors(corpusViewSelection) (retourne une liste d'éditeurs ouverts avec le résultat, 1 seul normalement)
  2. Récupérer la sélection des lignes de spécificité :
    def selection = editor.getlineTableViewer().getSelection()
    		def names = table.getRowNames().asStringsArray()
    		println "Selection: "+selection.toList()
    		println "Names: "+names[selection.toList()]

Etat de la plateforme

0.7.5

Focus

Dans un premier temps, pour la release 0.7.5, le champ focus sera retiré.

Dans un 2e temps, il faudra convenir d'une éventuelle nouvelle interface.

0.8.0

Construction depuis une partition

Les préférences par défaut de la table lexicale ne sont pas bonnes car elles déforment F et T (les marges de la table sont dans la table). On utilise alors Fmin=1 et Vmax=9999999.

Recette

  1. Installer le nouveau package “textometry”
  2. Lancer TXM
  3. Construire la partition “types” sur DISCOURS
  4. Faire une table lexicale
  5. importer des valeurs fictives (clic droit, “importer une table”) et sélectionner un fichier à lire (contenu ci-dessous)
  6. faire une spécificité et constater les scores maximum négatif et positif
la valeur max de spécificité est défini dans la page de préférence de Spécificité

Contenu du fichier CSV (UTF-8) de la table lexicale :

"Allocution radiotélévisée" "Conférence de presse" "Entretien radiotélévisé"
"Saint-Laurent- du-Pont" 10000 0 0
"Saint-Pierre-Et-Miquelon" 10000 1000 0
"professionnellement" 10000 1 0
"Société Des Nations" 10000 3 0
public/specs_specificites.txt · Dernière modification : 07/07/2023 11:06 de matthieu.decorde@ens-lyon.fr