Outils pour utilisateurs

Outils du site


public:interactive_graphs_rendering_component

Recherches sur les choix technologiques pour les visualisations graphiques

Objectif

  • Offrir une interface interactive d'exploration des graphiques générés depuis les résultats de calculs statistiques de R.
  • Ajouter de la sémantique aux graphiques afin de les exploiter au mieux dans le composant de rendu
  • Créer des communications bidirectionnelles entre la représentation du graphique, les composants annexes SWT (ex. pour les AFC : liste des points-colonnes, masses) et les données du résultat
  • Produire un composant pour TXM RCP prenant en compte une compatibilité avec TXM Portal (ce point risque d'être très complexe, les deux technologies utilisées étant radicalement différentes)

Les objectifs se découpent en deux grands axes :

  • ajouter de la sémantique aux résultats statistiques produits par R
  • créer le composant de rendu de graphiques interactifs intégrable à TXM RCP en favorisant au mieux une compatibilité avec TXM Portal (si une compatibilité complète n'est pas possible)

La sémantique à ajouter reste à définir mais dans un premier temps nous avons besoin de connaître dans le composant de rendu de graphiques interactifs de TXM :

  • le type d'élément graphique, ex. ce carré est un point-ligne d'une AFC ; ce label est le label de tel point-colonne
  • de lier ces éléments graphiques aux valeurs dans les composants annexes, ex. ce carré représentant un point-ligne est lié avec cette ligne du tableau de la liste des points-lignes
  • d'ajouter des données supplémentaires aux éléments du graphique, ex. ce point-ligne a une fréquence de xx dans le corpus

Voir : Ticket #269 au sujet de la définition des fonctionnalités et des besoins du composant de rendu.

Note

Après premières discussions :

  • pour le moment le composant ne nécessite pas d'accélération matérielle complète (JOGL, OpenGL), le nombre de points maximum affichés en conservant des performances correctes a été fixé a 1000 pour le composant de rendu de carte factorielle

Existant et sémantique

Actuellement, dans TXM RCP, les graphiques sont calculés par les packages de stats utilisés (ex. FactoMineR), puis construits par le package 'graphics' de R et enfin, rendus dans TXM RCP par Java (Batik pour le SVG et SWT pour les images raster) à partir du ficher généré par R (fichier SVG, fichier PNG, etc.). Les fonctions du package 'graphics' sont des fonctions orientées tracé, ex. plot(), lines(), text(), legend(). L'appel à ces fonctions appelle l'implémentation de ces fonctions dans le device graphique R courant. Par défaut le device courant produit une fenêtre native à l'OS (exécutée par le binaire R). Les implémentations de ces fonctions SVG ou PNG du device par défaut (Cairo), génèrent des fichiers contenant les graphiques.

Les packages de calculs statistiques par défaut ou complémentaires (ex. FactoMineR ou CA) appellent les fonctions de tracé du package 'graphics' qui appellent donc les fonctions du device graphique R courant.

Le problème de ce schéma est qu'il n'est donc pas possible d'ajouter de la sémantique aux graphiques depuis R avec la chaîne actuelle (package de stats ⇒ package 'graphics' ⇒ device graphique R), c'est-à-dire en passant par l'interface et la signature des fonctions des packages 'graphics' et des devices graphiques R.

A noter que la Toolbox permet de récupérer des valeurs de résultats produits par R via le couple Rserve/REngine. La Toolbox définit différentes structures de données Java pour manipuler des structures de données R (ex. Vector, Matrix, etc.) et des structures 'étendues' liées à la textométrie (ex. ContingencyTable, LexicalTable, etc.).

A noter également que toutes les fonctionnalités de R et des packages R de production de stats ne retournent pas forcément de données. Certaines fonctions appellent directement les fonctions de tracé pour produire le résultat. La communication ne peut donc être faite que dans un sens. Cela peut être problématique pour certaines solutions envisagées pour l'ajout et l'exploitation de la sémantique. [FIXME TODO: voir à quel point cela peut être problématique, sachant que les structures de données abstraites de la Toolbox (Vector, Matrix, etc.) dédiées au moteur de stats peuvent être passées directement à une lib Java de création de graphiques. On peut par exemple passer directement un vecteur récupéré depuis Rserve, pour créer un histogramme des valeurs propres, à la place d'utiliser la fonction R hist()]

Actuellement, dans TXM et si l'on prend l'exemple des AFC, une interface ICA est définie décrivant les spécificités d'une AFC telle que nous en avons besoin dans TXM. En plus de la création d'un fichier SVG, un objet Java est créé depuis les données produites par R et reçues via Rserve.

Les implémentations de l'interface ICA existantes et l'interface elle-même sont utiles à plusieurs choses :

  • à se détacher au mieux du package R utilisé pour générer l'AFC (ex. on peut switcher entre FactoMineR ou CA. Le point d'entrée dans TXM est donc ICA ce qui facilite par ailleurs la création et l'exploitation des ICA depuis un autre système que R)
  • à ajouter une sémantique propre à TXM ou lier les résultats entre eux (donner du sens aux résultats issus de R qui ne sont pas forcément identifiés/identifiables dans R)
  • à stocker ces données en mémoire évitant ainsi de faire de nouvelles requêtes à Rserve à chaque demande d'une valeur
  • à créer les composants SWT annexes des onglets de TXM et à communiquer entre les composants SWT et les données de manière directe, ex. pour l'AFC : liste des points-lignes, des fréquences, des masses, etc.

Solutions envisagées

La sémantique peut être ajoutée :

  • par R, directement à la production et passée à des objets Java lors de leur création
  • par la Toolbox, depuis le résultat produit par R et qui est récupéré via Rserve/REngine (on peut parler ici de post-processing)

1. Modifier le modèle fondamental de R

Se mettre en relation avec les développeurs de R afin de définir de nouvelles spécificités pour les packages 'graphics' et l'interface de devices graphiques R.

  • une solution pourrait être d'envoyer des données utilisateurs supplémentaires au device graphique R
  • tous les packages R voulant ajouter de la sémantique dans ce qu'ils produisent devront par la suite être adaptés en se pliant aux nouvelles spécificités définies
  • cela implique de fixer un système de passage de donnés 'sémantiques' compatible avec tout type de production de résultat, ce qui semble extrêmement complexe à faire (ex. comment savoir à quoi est associé telle donnée en fonction du package et donc comment savoir à quoi correspond telle donnée sans connaître le package qui a produit le résultat, dans certains cas cela pourrait être une fréquence, dans d'autre cas une masse, etc.)
  • en ajoutant des données supplémentaires il faut prendre en compte les notions de langue et de traduction
  • FIXME [TODO : se renseigner sur le sujet] des recherches ont déjà été faites à ce sujet par différentes personnes (S. Urbanek, W. Leland ?)

Pros

  • la sémantique est introduite par celui qui connaît le mieux ce qu'il produit, à savoir le package R lui-même

Cons

  • chaque package pourrait donc ajouter au mieux la sémantique de ce qu'il produit mais comment récupérer ces données et savoir à quoi elles correspondent sans connaître le package ?
  • la démarche générale semble extrêmement complexe (et longue)

2. Créer directement les composants graphiques Java depuis R via rJava

Ici l'idée est d'instancier les objets Java depuis R/rJava en leur passant des variables R.

C'est ce que fait iPlots lors d'un appel depuis R (ex. ibar(), iplot(), etc.). Avec cette méthode, nous ne créons pas d'objet Java de résultat mais créons directement le composant SWT/AWT/Swing de rendu de graphique interactif.

iPlots

Pour resituer le contexte :

iPlots n'est pas un Device Graphique R mais un framework Java et n'est donc pas une interface aux fonctions de tracé du package R 'graphics' (ex. plot(), lines(), etc). Pour rappel, ce sont ces fonctions de tracé (les fonctions du packages 'graphics') qui sont appelées par des packages comme FactoMineR.

iPlots est donc une lib à utiliser en tant que tout, elle n'est pas compatible avec d'autres packages R non prévus pour, ni n'utilise le mécanisme 'normal' de production des rendus graphiques.

iPlots peut être utilisée directement dans R, avec les fonctions ibar(), iplot(), ihist(), etc. mais également utilisée directement en Java, en créant directement les composants graphiques de type BarCanvas, ScatterCanvas, etc. ou en développant ses propres classes et/ou canvas. Comme expliqué précédemment, en utilisant iPlots dans R, les instances Java sont en fait créées via rJava en passant des variables R.

La sémantique dans iPlots est ajoutée via le code Java d'iPlots et non pas via le code R, on peut donc parler ici de post-processing si iPlots est exécutée depuis R. Un exemple pour le point d'entrée de la fonction ibar() en R :

.iplot.iBar  <- function (var, ...) {
  a<-.iplot.new(lastPlot<-.jcall(.iplots.fw,"Lorg/rosuda/ibase/plots/BarCanvas;","newBarchart",var@vid),"ibar")
  if (length(list(...))>0) iplot.opt(...,plot=a)
  a
}

c'est la classe Java BarCanvas qui va gérer la sémantique ajoutée aux composants Java, puis les événements Java AWT, etc.

La sémantique dans iPlots semble limitée. Elle ne dépasse par le niveau de l'objet 'graphique' au sens statistique du terme, ex. histogram, scatter plot.
FIXME [TODO : Est-ce que le framework nous permet par exemple, par simple héritage, de pouvoir différencier un histogramme des valeurs propres d'un histogramme de distribution par partie ? Dans le sens de modifier les événements, les labels, etc.]

iPlots définit des objets de type PlotComponent, PPrimPolygon, PPrimCircle, etc. Ces objets contiennent uniquement une sémantique liée à leur type graphique (au sens de tracé) et possède des méthodes de tracé.

Un appel à ibar(), ihist(), etc. dans R court-circuite le device graphique R et utilise directement rJava pour créer ou modifier des instances de classes Java.

Les packages utilisant eux normalement le device graphique courant de R, cela signifie que pour chaque package qu'on voudra utiliser autre que iPlots, il faudra le recoder en R pour l'adapter à iPlots mais vu que nous devrons ajouter notre propre sémantique, il faudra également coder notre propre classe Java via le framework d'iPlots. Si l'on prend FactoMineR par exemple, il va falloir recoder plot.CA()) en R pour créer des objets Java/iPlots via rJava mais également ensuite créer des classes Java pour ajouter la sémantique propre à la fonction. Alors que dans le cas de divers objets dans TXM on a déjà un objet Java représentant le type de résultat et contenant toute la sémantique dont nous avons besoin.

Dans le cas d'iPlots utilisé depuis R/rJava, on a donc R qui produit un jeu de données et le composant graphique Java est créé directement. Les données des résultats du côté Java sont stockées directement dans le composant graphique dans des variables de type SVar.

Production R => Composant graphique Java

Le principe fonctionne mais ce n'est pas très propre niveau séparation et cohérence des données. Par exemple, si on veut implémenter une fonction d'export des données, il faut soit repasser par R, soit récupérer les données depuis le composant graphique. Un autre exemple, si on veut faire de la sérialisation de résultats, en général sérialiser des composants graphiques est déconseillé, le mieux est de sérialiser les données puis de recréer les composants graphiques.

Pros

  • offre par défaut des fonctionnalités intéressantes pour l'exploration des graphiques :
  • sélection d'éléments
  • masquage/affichage des éléments, définition des couleurs, de la transparence, des dimensions, tris
  • zoom et recalcul des valeurs des axes après zoom/dezoom.
  • brushing entre les différents graphiques créés si le iSet est partagé (ex. la sélection d'un élément d'un histogramme sélectionne ce même élément dans un nuage de points)
  • permet de switcher de moteur de rendu AWT/Swing (et JOGL ?) [FIXME : TODO : non testé]

Cons

  • ne peut pas fonctionner tel quel, exécutée depuis R/rJava avec le modèle actuel de TXM qui passe par Rserve
  • iPlots étant une lib à part entière court-circuitant le device graphique courant de R, son utilisation nécessite soit :
    • de recoder tous les packages R que l'on veut utiliser en remplaçant les appels aux fonctions de tracé du package 'graphics'

soit :

  • pour les packages retournant des données R ⇒ créer un objet Java que nous passerons ensuite à iPlots Java
  • pour les packages ne retournant aucune données R ⇒ recoder tous les packages R que l'on veut utiliser en remplaçant les appels aux fonctions de tracé par des retours de données R
  • redévelopper les packages R sera très lourd/long, d'autre part, chaque modification du code source d'un package R par les auteurs entraînera un recodage par nos soins pour regénérer les composants iPlots Java (par opposition à la solution 3, voir plus bas, dans laquelle il s'agit d'adapter la structure de type de résultat au nouveau package, ce qui semble moins lourd)
  • dans tous les cas cités ci-dessus, cette solution nécessite de développer des classes et/ou étendre les classes existantes du framework iPlots pour y ajouter notre propre sémantique
  • la communication entre les composants annexes (ex. onglet de liste des points-lignes, etc.) doit repasser par R ou le composant graphique
  • la compatibilité avec TXP Portal/GWT risque d'être très complexe
  • au niveau des sources, beaucoup de choses sont en private ou codés en dur (événements, labels), par exemple impossible de traduire les items des canvas (ex. BarCanvas, HistCanvas) proposés sans modifier les sources ou redévelopper un grande partie de classe, [FIXME TODO:] l'approche par héritage semble très limitée
  • pas beaucoup de doc

Note

  • trouvé dans le code source R d'iPlots :
ipe$.issue.warning <- "Note: On Mac OS X we strongly recommend using iplots from within JGR.\nProceed at your own risk as iplots cannot resolve potential ev.loop deadlocks.\n'Yes' is assumed for all dialogs as they cannot be shown without a deadlock,\nalso ievent.wait() is disabled.\nMore recent OS X version do not allow signle-threaded GUIs and will fail.\n"

(Pour info JGR est un GUI/Frontend pour R développé en Java)

3. Définir nos propres interfaces pour chaque type de résultats que TXM va manipuler

Ici le principe est de stocker tout type de résultat dans un objet Java intermédiaire, séparé des composants graphiques Java.

Comme pour ce qui a été fait avec l'interface ICA (ou les interfaces ContingencyTable, LexicalTable, etc.), il s'agit ici d'ajouter la sémantique propre à TXM via la Toolbox Java lors de la récupération d'un résultat depuis R. On pourrait parler de post-processing sur les données produites par R.

TXM crée un nouvel objet Java et conserve donc une trace en mémoire du résultat qui va permettre :

  • d'ajouter la sémantique propre à TXM
  • de créer les composants SWT
  • d'effectuer différentes tâches sans repasser par R (notamment la récupération ou la modification de valeurs)

Dans le cas de TXM pour les AFC on passe donc par un objet Java intermédiaire, qui sert de cache entre autres choses. Les composants graphiques sont créés à partir de cet objet et peuvent communiquer directement avec le résultat produit dans les deux directions :

Production R => Données <=> Composant graphique Java

FIXME TODO: Vérifier si le framework R de la Toolbox permet de modifier directement une donnée dans R via REngine (uniquement lecture ou lecture/écriture ?)

Si c'est le cas on a aussi une communication bidirectionnelle vers R :

R <=> Données <=> Composant graphique Java

permettant d'avoir un état cohérent entre les données R et les données Java.

Pros

  • le résultat est stocké en mémoire évitant les nouvelles requêtes vers R, on peut voir cela comme un système de cache (txm.stat.engine.r.function.CA a d'ailleurs été codée comme ça dans TXM, si valeur vide alors requête vers R sinon retourner valeur existante)
  • facilite les communications entre les composants SWT annexes (ex. onglet de liste des points-lignes, etc.), le résultat en lui-même et le composant de rendu de graphiques interactifs
  • l'abstraction permet de changer plus facilement de package R mais pourrait aussi permettre de changer complètement de moteur de statistiques
  • l'abstraction et l'objet Java intermédiaires permettent à TXM de spécifier le type de résultat qu'il veut traiter et d'ajouter des calculs ou résultats qui ne sont pas dans les packages R, ainsi nous définissons comment TXM spécifie un résultat ce qui laisse une marge de manœuvre entre les données produites par R et ce que TXM veut proposer comme fonctionnalités à l'utilisateur
  • par opposition à la solution 2, voir plus haut, l'utilisation d'iPlots ou autre lib graphique Java (ex. JFreeChart) avec objet Java intermédiaire, et, dans le cas de la modification par les auteurs des packages R qu'on utilise, n'implique que de modifier une structure de données pour s'adapter à ce qu'on reçoit depuis R (et non pas de redévelopper les packages R utilisés)

Cons

  • nécessite le développement des interfaces/classes de chaque type de résultats que le composant de rendu de graphiques interactifs doit traiter (ex. ICA [déjà fait], Diagramme de distribution par partie, Histogramme des valeurs propres, etc.) bien que pas mal de code soit sans doute mutualisable

A partir de ces objets Java (ex. ICA, Diagramme de distribution par partie, Histogramme des valeurs propres, etc.), il faut ensuite rendre le graphique, donc créer le composant graphique SWT, tracer le graphique et mettre en place les interactions utilisateur et les liaisons avec les composants SWT annexes (ex. masses, contributions, etc.).

Plusieurs solutions sont envisagées pour le moment :

A. SVG en format pivot et post-processing sur le SVG

Continuer à utiliser le format SVG comme pivot via l'ancien device RSVGDEvice ou via le nouveau device Cairo-svg puis afficher ces SVG dans SWT via Batik ou autre. Le problème de cette méthode est que comme R n'ajoute pas de sémantique dans les fichiers SVG il est extrêmement difficile de dire quelle balise SVG correspond à quel élément du résultat, en particulier avec le nouveau device Cairo-svg qui n'utilise plus la balise 'text' mais un système de glyph/path rendant impossible de détecter un label ou une légende. Il s'agit donc ici de post-processing sur le fichier SVG et de déduction en fonction du type de balise et de la position de la balise dans le fichier (ex. les points-lignes sont tracés avant les points-colonnes par le device graphique R donc j'en déduis que ces x lignes sont des points-colonnes)

Cons

  • la méthode du post-processing sur le SVG est compliquée à mettre en oeuvre du fait des difficultés à faire la liaison entre une balise SVG et sa signification en terme de sémantique du résultat. Le SVG ne contient qu'une 'sémantique de dessin'
  • d'autre part cela ne serait a priori possible qu'avec l'ancien RSVGDevice et non plus avec le nouveau Cairo-svg


Deux solutions sont envisagées pour la gestion des événements :

A.1 Événements via l’interpréteur Javascript de Batik

Modifier l'arbre DOM dynamiquement et gérer les événements via les composant Java2D.

Cons

  • après les tests avec cette méthode, Java/Batik posent des problèmes de performances pour la modification dynamique de l'arbre DOM
  • NOTE : les mauvaises perfs de Batik dans TXM peuvent être liées au GC ou au bridge SWT utilisé, à tester/profiler, mais le chargement et la manipulation des mêmes SVG sous batik-squiggle semblent plus rapides que sous TXM
  • NOTE 2 : après tests, les perfs semblent similaires sous Batik Squiggle que sous TXM, mise à part le rafraîchissement du composant sous TXM qui semble buggé (si l'on redimensionne le composant, le rafraîchissement se fait ensuite bien)
A.2 Événements via l’interpréteur Javascript de Batik

Injecter les valeurs, la gestion des événements, etc. directement dans l'arbre DOM SVG Java.

Pros

  • cette solution pourrait potentiellement faciliter la compatibilité avec le portail

Cons

  • après les tests avec cette méthode, Java/Batik posent des problèmes de performances pour la modification dynamique de l'arbre DOM
  • les communications entre Javascript et SWT sont assez laborieuses à mettre en oeuvre

B. Java

Créer les graphiques via Java en utilisant une lib de création et de manipulation de graphiques (ex. JFreeChart, iPlots Java, etc.) ou directement en Java2D. Une fois qu'on a un objet de type ICA, Histogramme des valeurs propres, etc., à partir de ce dernier on crée le composant de rendu de graphiques interactifs.

Pros

  • le système de TXM actuel fonctionne déjà en partie comme cela pour faire la liaison entre R/CWB et les composants SWT autres que les composants de rendu de graphique existants, c'est-à-dire en passant par des objets Java intermédiaires pour la création des composants SWT (les tableaux, composants annexes, etc.)

Cons

  • la compatibilité avec TXP Portal/GWT risque d'être très complexe, à moins d'intégrer un applet Java

iPlots

Intégration des composants graphiques Java d'iPlots aux composants SWT de TXM

FIXME [TODO : à confirmer/infirmer, en attente réponse liste Rosuda et/ou recherches supplémentaires] Pour l'embed d'iPlots, plusieurs solutions semblent possibles :

1) Continuer à utiliser Rserve donc utiliser iPlots en tant que lib graphique Java

  • créer le jeu de données via Rserve, le passer à iPlots Java

Pros

  • on a un objet Java en mémoire représentant le résultat, ce qui devrait faciliter la compatibilité avec TXM Portal

Cons

  • on doit créer les objets Java intermédiaires pour tout type de résultat que TXM veut traiter dans le composant de rendu de graphiques interactifs
  • FIXME [TODO : à vérifier mais la détection du lien entre les plots via le iSet (la comparaison du vecteur passé aux fonctions iplot(), ihist(), etc.) est sans doute faite au niveau de R, la fonctionnalité n'est donc peut-être pas utilisable avec Rserve]

2) Lancer R via JRI, faire l'embed depuis R/rJava (FIXME : TODO: ou, à vérifier, lancer TXM RCP depuis R/rJava pour partager la même JVM)

Cons

  • on n'a pas d'objet Java en mémoire représentant le résultat, la liaison avec les composants SWT annexes (ex. liste des points-colonnes) et la compatibilité avec TXM Portal risque donc d'être plus difficile à mettre en oeuvre
  • pas beaucoup de doc

JFreeChart

Pros

  • offre par défaut des fonctionnalités intéressantes pour l'exploration des graphiques :
  • sélection d'éléments
  • masquage/affichage des éléments, définition des couleurs, de la transparence, des dimensions
  • zoom et recalcul des valeurs des axes après zoom/dezoom.
  • beaucoup de doc
  • facilité d'accès aux éléments des différents graphiques proposés par requête ou par héritage

Cons

  • TBD

Premières informations sur le développement

Le développement pour l'utilisation d'iPlots depuis R/rJava sera sans doute plus long que l'alternative de passer par un objet intermédiaire et d'ajouter la sémantique dans le jeu de données en Java. Une première 'analyse' sur les AFC :

Cas 1 : iPlots depuis R/rJava :

  • développement Java d'un graphique de type AFC avec les classes Java d'iPlots
  • modification des sources Java d'iPlots et/ou création de nouvelles classes ou extension de classes pour ajouter notre propre sémantique
  • mise en place des événements
  • re-développement du package FactoMineR en R

Cas 2 : R + post-processing dans un objet Java

  • développement Java de classes et/ou interfaces représentant les données de résultat statistique
  • initialisation d'un graphique via une lib Java de graphiques comme JFreeChart
  • mise en place des événements

Pour ce 2e cas, on pourra également utiliser iPlots en tant que lib graphique, en lui passant l'objet de résultat en Java mais dans ce cas il faudra ajouter cette étape :

  • développement Java d'un graphique de type AFC avec les classes Java d'iPlots (ce type de nuage de points existe déjà dans JFreeChart)

[FIXME TODO: Voir si le scatter plot de base d'iPlots peut être utilisé pour l'AFC. Mais comme expliqué précédemment les canvas Java proposés par iPlots sont trop encapsulés, cela nécessitera donc a priori soit d'hériter de la classe ScatterCanvas et de rédéfinir/redévelopper une grande partie de la classe, soit de modifier le code source, ne serait-ce que pour la traduction des items des widgets mais le problème semble aussi se poser pour la gestion des événements]

L'exemple de l'AFC ci-dessus n'est en plus pas très bon car les classes Java de 'données de résultat' sont déjà codées donc là c'est clair que le temps de développement sera extrêmement plus court dans le cas de la solution avec JFreeChart mais le schéma reste le même pour n'importe quel graphique. Le cas d'iPlots depuis R/rJava ajoute la phase du redéveloppement en R donc a priori le développement sera plus long. Notamment car il y a une phase d'analyse du code source des packages R qui peut être ardue mais même en terme de dév, ce que j'appelle post-processing consiste en fait à faire des liens entre différentes données reçues donc ça reste normalement très simple.

Questions primordiales pour la suite des recherches

FIXME [TODO:]

  • est-ce que l'abstraction définie au départ dans TXM et liée au moteur de statistiques est abandonnée ? C'est-à-dire que le lien à R est 'définitif' et que la possibilité de changer 'facilement' de moteur de stats est abandonnée. Serge avait parlé il y a quelques temps de la possibilité d'une version light de TXM, avec un moteur de stats développé en Java si je me souviens bien mais je crois qu'à la réunion tu m'avais dit que ce n'était plus d'actualité ?

(par curiosité, même question pour le moteur de corpus bien que dans le code source, l'abstraction ne semble plus vraiment respectée)

  • (SH&MD : 2013-10-03) : l'abstraction du moteur statistique est définie par une API (lancer moteur, arrêter moteur, lancer une commande statistique de TXM, récupérer des résultats d'une commande statistique de TXM, lancer une commande R, récupérer des objets R transcodés en Java). Le “lancer une commande R” est utilisé aujourd'hui au moins par la commande Progression. Cette façon de faire ne respecte pas l'abstraction parce que Matthieu voulait tester la possibilité de donner accès à des commandes en fonction de la disponibilité de composants ou moteurs (R dans ce cas). Normalement, Progression devrait être défini dans l'abstraction du moteur stats. Par ailleurs, l'UI de TXM a pas mal été développée pour aider à travailler avec R (Perspective R, Session R, Exécution, Vue variables R, etc.). Donc on a commencé à mettre le doigt dans une abstraction plus vraiment respectée. Pour répondre à la question, on peut analyser trois situations en cas d'indisponibilité de R : 1) cela rend TXM inopérant 2) cela rend TXM très différent 3) cela ne change pas TXM notamment parce qu'on a remplacé tous les services qu'il offre par des alternatives (un seul moteur de stats en Java par exemple ou plusieurs composants mixant stats et graphiques par exemple). Aujourd'hui on est dans la situation 2) donc pas de commandes statistiques et UI liée à R inopérante. C'est d'ailleurs une situation qui a été souhaitée par certains utilisateurs. Cela va dans le sens de garder l'abstraction et donc l'indépendance à R, et de développer TXM sous forme de composants qui entretiennent des dépendances.
  • (SH&MD : 2013-10-03) : pour le moteur de recherche il y a une abstraction définissant Corpus, Sous-corpus, Partition qui se manifeste au démarrage, à l'arrêt de TXM, création de sous-corpus et de partition, lancement de requête, lors d'un import, etc. Par contre, tous les modules d'import convergent vers le modèle de corpus de CQP (arborescences parallèles de structures étiquetées sur des mots étiquetés), donc pour utiliser un autre moteur rendant des services équivalents il y a pas mal de travail pour faire évoluer ce code ainsi que le modèle de données de corpus privilégié aujourd'hui. Donc actuellement cette abstraction est de type 1) → il faut faire beaucoup d'efforts pour mettre un moteur différent.
  • si l'abstraction est abandonnée, est-ce que la possibilité d'utiliser R sur une machine distante via socket et Rserve est conservée ?

(la réponse à la question impactera fortement le développement dans l'éventuelle utilisation de iPlots et/ou si la sémantique est ajoutée directement dans R. Pour infos si l'utilisation à distance est abandonnée, je crois que Rserve devient inutile, toutes les communications avec R auraient pu être faites via rJava ou sur le même principe que la lib native pour CWB a priori)

  • (SH&MD : 2013-10-03) : les questions d'abstraction et d'accès sont indépendantes. Pour l'instant l'accès distant à R n'a encore jamais été démontré comme utile ou pertinent, donc on peu aussi imaginer un accès direct (sous forme de librairie dynamique par exemple). D'ailleurs actuellement les retours de graphiques par R sont réalisés par fichiers et non par socket (contournement de Rserve).
  • Est-il intéressant de se lancer dans l'utilisation d'iPlots via R/rJava sachant qu'il faudra recoder les packages R qu'on utilise à chaque fois qu'ils feront l'objet d'une mise à jour ? D'autre part, cette solution semble nécessiter un changement au niveau du fonctionnement de TXM, sachant que cela n'est pas compatible avec Rserve
  • Si non et que nous partons sur l'idée de définir nos propres interfaces pour tout type de résultats que nous souhaitons traiter dans le composant de rendu et que nous recevons via Rserve, alors est-ce intéressant d'utiliser iPlots en tant que lib de création de graphique Java ? Sachant que la sémantique ajoutée par iPlots est très limitée et que le panel de graphiques proposé est très restreint, par opposition à JFreeChart ? D'autre part, JFreeChart implémente beaucoup de fonctionnalités supplémentaires pour la manipulation des graphiques générés.
  • (SH&MD : 2013-10-03) : si l'architecture d'iPlots n'est pas très convaincante, alors mettons nous d'accord sur une architecture qui permette de déléguer à R certains calculs de production de graphiques tout en permettant la gestion d'une sémantique de visualisation interactive avec des résultats, que R soit au bout d'une socket ou sous forme de librairie (à démontrer).
  • concrètement après les premières analyses, avec iPlots nous serons amenés à n'utiliser qu'une petite partie de l'existant alors qu'avec JFreeChart tout semble paramétrable et héritable.

Pour tester l'interface d'iPlots

  • lancer dans R install.packages('iplots',,'http://www.rforge.net/')
  • lancer des commandes du type ihist(10 : 30), iplot(2 : 15), ibar(8 : 48)
  • NOTE : dans le cadre du lien entre les plots, iPlots demande via une popup si l'on veut conserver le même iSet lorsque qu'on lui passe un vecteur différent de celui utilisé pour le plot précédent
  • exemples plus approfondis : http://stats.math.uni-augsburg.de/iplots/

Pour tester l'interface de JFreeChart

Autres ressources

Package R 'graphics'

Nouveau device R SVG-Cairo

iPlots

JavaGD

JGR

  • GUI/Frontend pour R développé en Java
  • exécute R via JRI permettant ainsi de partager la même JVM que les composants Java créés par la suite avec R/rJava (ex. iPlots)
  • les composants graphiques de la GUI sont accessibles depuis R via rJava

ggplot2

Lattice

Deducer

expplor

xGD

GWT Charts Tools Library

Draw SVG

R et SVG interactif

Autres libs intéressantes de création de graphiques en Java

Général, listes et comparaison de libs

GRAL

jChart2D

Openchart2

Jzy3d

GraphStream

Libs Java dédiées aux graphes

  • Gephi, FYI
  • Graphstream : Graphstream fonctionne par styles CSS pour la configuration graphique des visualisations ce qui peut être intéressant dans le cadre de TXM Web, ex. : partage de fichiers CSS, thèmes stockés dans des fichiers CSS, etc.
  • le projet GEF d'Eclipse intègre le plugin Zest de visualisation
    • Zest intègre notamment 3 composants intéressants liés à DOT (voir leur doc) :
      • un éditeur de descriptions de graphes DOT
      • un appel aux binaires de DOT de Graphviz (de placement automatique de nœuds et d'arcs de très grands graphes)
      • une visualisation des graphes DOT

Libs pas Java dédiées aux graphes

Librairies Javascript

Suppose l'utilisation d'un navigateur intégré ou bien d'un ScriptEngine Java Javascript (Nashorn, Rhino…) ayant au moins l'API SVG.

public/interactive_graphs_rendering_component.txt · Dernière modification: 2017/06/16 12:34 par sebastien.jacquot@univ-fcomte.fr