push suite à pbm merge Bertrand (jc)

This commit is contained in:
John Charron 2011-05-30 22:14:20 +02:00
parent e8833f3c69
commit 433beb39a4

View File

@ -336,7 +336,7 @@ Il existe plusieurs systèmes et algorithmes pour évaluer le rapport sémantiqu
Sans entrer dans les détails de l'algorithme de la LSA, qui est brevetée et payante, cette approche consiste à générer un graphe de relations entre mots à partir de textes écrits. Le résultat de l'algorithme donne un graphe de noeuds (mots) et d'arcs (estimation du degré de lien sémantique entre deux mots) comme suit~:
\begin{comment}
\begin{figure}
\pgfdeclarelayer{background}
\pgfdeclarelayer{foreground}
@ -380,7 +380,7 @@ Sans entrer dans les détails de l'algorithme de la LSA, qui est brevetée et pa
}
\end{tikzpicture}
\end{figure}
\end{comment}
La LSA est plus fiable lorsque les textes utilisés pour générer les poids de relations sémantiques sont des corpus spécialisés et donc relativement homogène. C'est une méthode rapide, facile à réaliser, efficace. Les données récoltées rélèvent en général de la langue écrite et donc d'un niveau de langue soutenue et riche. Un tel corpus contient une grande quantité de vocabulaire passif.
@ -401,7 +401,6 @@ L'inconvénient est que ces informations peuvent contenir des bruits et des sile
Un graphe du réseau lexical JeuxDeMots est de la forme qui suit, toutefois, il faut imaginer non pas cinq noeuds, mais plus de 200 000 noeuds~:
\begin{comment}
\begin{figure}
\pgfdeclarelayer{background}
\pgfdeclarelayer{foreground}
@ -450,7 +449,7 @@ Un graphe du réseau lexical JeuxDeMots est de la forme qui suit, toutefois, il
}
\end{tikzpicture}
\end{figure}
\end{comment}
Le réseau lexical JeuxDeMots permet aussi de générer un graphe donnant un seul arc entre deux mots similaire au graphe créer par la LSA. L'algorithme pour générer un graphe contenant des simples liens entre noeuds et qui donne des résultats très proche de la LSA est décrit dans Lafourcade et Zampa 2011.\footnote{PtiClic et PtiClic-kids~: Jeux avec les mots permettant une double acquisition. In proc TICE 2010, 7e coloque TICE, Nancy~: 6-8 décembre 2010}
@ -573,10 +572,7 @@ $n_1$ à «start», $n_2$ à «end», $t$ à «type» et $w$ à «weight» de la
\pagebreak
\subsection{Site Internet}
% TODO : Yoann
\subsubsection{Pourquoi un site Internet~?}
Lorsqu'une nouvelle application ou jeu est développé, il est essentiel de faire connaître l'application.
La communication est une étape fondamentale dans la chaîne de création d'une application et la création d'un jeu n'en fait pas exception.
Internet est devenu un support de communication très important et très influant qui permet de faire découvrir aux
@ -645,9 +641,8 @@ La partie création de partie a été développé en JavaScript au lieu de PHP,
il ne sais pas forcément combien de mots va composer sa partie. Il devra par conséquent être en mesure d'augmenter au besoin le nombre de mots composants la partie.
\subsubsection{Jouez en ligne~!}
La seconde évolution majeure qui est liée à une nouvelle version de l'interface de jeu est qu'il est possible de jouer directement depuis
le site Internet sans forcéement disposer de téléphone sous \android{}. Cette option permettra de toucher un public bien plus large tout en
ne pénalisant pas ceux qui disposent d'un smartphone \android{}
La seconde évolution majeure concernant le deuxième prototype du jeu est qu'il est possible de jouer directement depuis
le site Internet sans forcément disposer de téléphone sous \android{}. Cette option permet de toucher un public bien plus large sans pénaliser ceux qui disposent d'un smartphone \android{}
\subsection{Version html5 du jeu}
@ -669,24 +664,25 @@ L'application comporte 6 écrans~:
\end{itemize}
Chaque écran est contenu dans un élément HTML (\verb!<div/>!) qui est affiché uniquement lorsque l'utilisateur est sur cet écran.
La navigation entre les écrans, et entre chaque mot du nuage lorsqu'on joue à la partie, s'effectue en modifiant l'identifiant de fragment
La navigation entre les écrans et entre chaque mot du nuage lorsqu'on joue à la partie s'effectue en modifiant l'identifiant de fragment
de l'URL (la partie après le \verb!#!). De cette manière, chaque état est stocké dans l'historique du navigateur, et on peut revenir à
l'écran précédent en utilisant les botons «Précédent» et «Suivant» classiques. De plus, cela permet d'annuler le choix d'une relation pour
l'écran précédant à l'aide des boutons «Précédent» et «Suivant» classiques. De plus, cela permet d'annuler le choix d'une relation pour
un mot donné simplement en cliquant sur «Précédent».
L'état du programme (écran en cours, thème de couleurs, structure de données représentant la partie en cours lorsqu'elle a été récupérée,
même chose pour les scores) est stocké dans une variable nommée \verb!runstate!. Cependant, si l'on considère l'enchaînement d'actions
suivantes, on se rend compte qu'il doit y avoir une décorrélation entre l'état du programme tel que dicté par l'URL, et l'état réel du
L'état du programme -- écran en cours, thème de couleurs, structure de données représentant la partie en cours lorsqu'elle a été récupérée et de même pour les scores -- est stocké dans une variable nommée \verb!runstate!. Cependant, si l'on considère l'enchaînement d'actions
suivantes, on se rend compte qu'il doit y avoir une décorrelation entre l'état du programme tel que dictée par l'URL et l'état réel du
programme~:
\begin{itemize}
\item L'utilisateur clique sur «Jouer», ce qui l'amène à l'URL \verb!#game!;
\item L'écran de connexion est affiché pour que l'utilisateur s'identifie, sans modifier l'URL (pour ne pas enregistrer cette étape
\item L'écran de connexion est affiché pour que l'utilisateur s'identifie sans modifier l'URL (pour ne pas enregistrer cette étape
transitoire dans l'historique).
\item Une fois que l'utilisateur est connecté, la partie commence.
\item Une fois l'utilisateur connecté, la partie commence.
\end{itemize}
Cette décorrélation apporte une certaine complexité au code de transition entre les états du programme, d'autant plus que l'application
effectue des requêtes réseau asynchrones, par exemple pour récupérer la partie, durant lesquelles n'importe quelle séquence de «Précédent» /
«Suivant» ou de modifications arbitraire peut avoir lieu. Ainsi, entre le moment où on effectue une requête pour récupérer une nouvelle
Cette décorrelation apporte une certaine complexité au code de transition entre les états du programme, d'autant plus que l'application
effectue des requêtes réseau asynchrones, par exemple pour récupérer la partie, durant lesquelles n'importe quelle séquence «précédent» /
«Suivant» ou de modification arbitraire peut avoir lieu. Ainsi, entre le moment où on effectue une requête pour récupérer une nouvelle
partie, et le moment où cette requête aboutit, l'utilisateur peut avoir cliqué sur «Précédent», ce qui le ramène à l'écran d'accueil (auquel
cas il ne faut pas afficher la partie lors de la réception), mais il peut aussi après ce «Précédent» faire «Suivant», auquel cas on se
retrouve de nouveau sur l'écran du jeu, et il faut donc afficher la partie lors de sa réception (et ne pas faire une deuxième requête