Catherine Letondal

Une approche pragmatique de la programmation pour des biologistes qui programment presque

INTRODUCTION

La biologie moléculaire fait maintenant largement appel à l'informatique, notamment pour l'analyse des séquences d'ADN et de protéines. Les chercheurs en biologie ne peuvent pas toujours se contenter d'utiliser les logiciels existants, ils doivent aussi pouvoir les adapter ou en développer de nouveaux. Certains d'entre eux écrivent déjà leurs propres programmes, et parfois les distribuent. Mais pour ceux qui ne peuvent pas passer trop de temps à la programmation et aux concepts informatiques, il faut un environnement qui leur permette de tester quelques algorithmes simples et traiter leurs données par eux-mêmes. Mon propos dans cet article n'est pas de décrire un nouvel environnement de programmation pour ce type d'utilisateurs, mais d'expliquer pourquoi, selon mes observations, cela constitue un problème difficile. L'Institut Pasteur enseigne régulièrement un cours de programmation de 3 mois, à l'issue duquel les biologistes sont capables de concevoir des algorithmes et de définir des structures de données en Scheme. Cependant, l'application par la suite de ces connaissances dans le contexte de leur travail s'avère souvent difficile. J'observe également depuis deux ans l'utilisation d'interfaces Web que j'ai développées pour faciliter l'accès à des logiciels d'analyses biologiques. Ces interfaces proposent une fonction d'enchaînement de programmes équivalente aux pipelines Unix. L'utilisation régulière de cette fonction suggère que si les biologistes avaient un moyen aussi simple et à leur portée pour faire la même chose sous Unix, ils seraient probablement capables de programmer des scripts.

Que faut-il faire alors pour mettre la programmation à leur portée ? Mon hypothèse est qu'une partie du problème est du côté des idées que les informaticiens peuvent avoir a priori concernant ce qui est facile ou difficile dans la programmation : à titre d'exemple, ce n'est pas nécessairement l'algorithmique qui bloque les biologistes -qui sont pour la plupart des scientifiques de haut-niveau, mais plutôt les innombrables détails qui entourent l'algorithme et qui n'ont aucun intérêt pour eux : les entréessorties, les formats des fichiers ou les problèmes d'interfaces.

LES TECHNIQUES ACTUELLES

Parmi les techniques qui tentent de faciliter la pratique de la programmation pour les non-informaticiens, citons : la programmation visuelle où les concepts de programmation sont manipulés graphiquement, les environnements de composition visuelle et la programmation par démonstration.

Il est utile de distinguer parmi les langages visuels ceux qui sont bi-modaux (modes édition et exécution), comme LabView [START_REF] Baroth | Visual Programming in the Real Wold[END_REF], de ceux qui permettent une programmation directement dans l'interface : Self [START_REF] Smith | Programming as an Experience: The inspiration for Self[END_REF], Forms/3 [START_REF] Burnett | Visual Object-Oriented Programming, Concepts and Environments[END_REF], et les tableurs. L'idée sous-jacente des outils de la première catégorie est que la difficulté de la programmation est d'ordre syntaxique : en permettant la manipulation directe des concepts de programmation sous une forme graphique, comme les boucles, les tests, les classes ou les composants, on pense faciliter l'accès à la programmation. Mais Nardi [START_REF] Nardi | A small matter of programming: perspectives on end user computing[END_REF] a montré que cette distinction entre visuel et textuel ne discrimine pas réellement les langages professionnels des langages non-professionnels. Nardi donne ainsi des exemples de langages textuels utilisés sans problèmes par des non-informaticiens, comme un langage d'instructions pour une machine à tricoter ou comme un langage de codage du base-ball. En revanche, l'approche «programmation dans l'interface» semble prometteuse : en supprimant la

Conception Participative

Du point de vue du biologiste, la question la plus importante à poser est : « Qu'est-ce que les biologistes programmeraient, et comment ? » Pour répondre à cette question, j'ai choisi de m'inspirer des méthodes et des techniques de conception participative [START_REF] Schuler | Participatory Design: Principles and Practices[END_REF]. Un certain nombre d'actions ont été menées jusqu'à présent :

• plusieurs scénarios d'utilisation de logiciels existants ont été observés, et enregistrés (audio et video) ;

• de nombreux entretiens informels ont eu lieu (une vingtaine environ) : ces entretiens portent en général sur la problématique spécifique du chercheur, mais peuvent aussi porter sur un logiciel particulier ;

• une enquête à base d'un questionnaire ayant obtenu environ 600 réponses a essayé d'évaluer l'usage des logiciels scientifiques et l'impact de la formation sur cet usage ;

• trois ateliers de conception participative ont eu lieu depuis début 1998 :

-un atelier de prototypage papier avec un petit groupe de personnes (5 biologistes et 2 informaticiennes) pour démarrer la conception d'une nouvelle interface pour un algorithme de découverte de motifs [START_REF] Sagot | Multiple sequence comparison -A peptide matching approach[END_REF] (figure 1) ; -un atelier de brainstorming pour un projet d'environnement d'analyse de séquences ; -un atelier de prototypage papier sur deux des thèmes qui émergeaient du brainstorming (figure 2). La programmation c'est l'automatisation : sauvegarder des instructions dans un fichier pour leur exécution ultérieure, c'est programmer.

Cela signifie-t-il que taper des commandes complexes au niveau d'un interpréteur n'est pas de la programmation ?

Programmer, en sauvegardant des instructions pour leur exécution à une date donnée, c'est aussi planifier.

Cela veut-il dire que l'utilisation des commandes at ou cron sous Unix est de la programmation ?

La programmation c'est la traduction vers un niveau meta ou symbolique , comme par exemple lorsqu'on nomme un objet (c'est une référence à la dichotomie usage-mention [START_REF] Smith | The Use-Mention Perspective on Programming for the Interface[END_REF]).

Est-ce que définir un alias c'est programmer ?

Programmer c'est écrire du code.

Est-ce que l'édition d'un fichier de configuration c'est de la programmation ?

Programmer, c'est utiliser un compilateur ou un interpréteur.

Est-ce que soumettre un fichier à l'interpréteur LaTeX ou même utiliser Netscape c'est programmer ?

La programmation c'est la construction d'un logiciel ou de composants logiciels.

Les programmeurs professionnels construisent-ils si fréquemment des logiciels ou des composants ?

Un programme c'est la représentation statique de quelque chose de dynamique [START_REF] Lieberman | Bridging the Gulf Between Code and Behavior in Programming[END_REF].

La conception et l'implémentation d'une base de données n'est-elle pas de la programmation ? Et la réalisation des pages d'un serveur Web ?

Figure 1 :

 1 Figure 1 : Prototype papier pour Alice.

Figure 2 :

 2 Figure 2 : Prototypage papier de l'environnement d'analyse de séquences.

au fait, c'est quoi ? UNE APPROCHE EMPIRIQUE

  distinction entre programmer et utiliser, et en rendant les deux activités accessibles France dans le même contexte, elle fait de la programmation une activité cohérente et continue avec le travail en cours. L'idée de la programmation par démonstration ou par l'exemple[START_REF] Cypher | Programming by Demonstration[END_REF] est d'utiliser des séquences d'actions de l'utilisateur pour générer des programmes. Plus l'interface est interactive, plus cette approche est utile, bien qu'elle comporte certaines limites : la programmation par l'exemple est conçue pour ré-utiliser les actions, mais encore faut-il que ces actions aient eu lieu, et que le vocabulaire interactif soit suffisamment expressif. De plus il est parfois plus simple de décrire une action que de la démontrer au logiciel. C'est pourquoi, même si une fonction d'historique et d'enregistrement de macros avec, pourquoi pas, un mécanisme d'inférence serait extrêmement utile, cela ne répondrait pas à tous les besoins. La conception centrée sur l'utilisateur a montré son utilité, et je pense qu'une telle démarche est d'autant plus importante dans un domaine où l'informaticien professionnel pense qu'il connaît d'avance la nature du problème et de sa solution.

	Institut Pasteur, Service d'informatique scientifique	Laboratoire de Recherche en Informatique
	28, rue du Docteur Roux	URA 410 du CNRS
	75724 Paris Cedex 15	LRI -Bâtiment 490 -Université de Paris-Sud
	letondal@pasteur.fr	91405 Orsay Cedex,

Le problème qui se pose s'explique bien en termes de degrés de flexibilité logicielle

[START_REF] Nierstrasz | Component-Oriented Software Technology[END_REF]

:

• la paramétrisation fonctionnelle comporte une limite inhérente, puisque tous les paramètres doivent avoir été prévus ;

• la composition logicielle, où la structure est un paramètre, apporte plus de souplesse : mais ce niveau d'accès est soit trop difficile, s'il s'agit d'utiliser un framework, soit bien trop limité, s'il s'agit de faire de l'accrochage de boîtes graphiques (Java Beans) ; il faut pouvoir, si c'est nécessaire, mener l'utilisateur au niveau du composant lui-même pour le modifier ou pour en programmer un nouveau ;

• la flexibilité maximum est atteinte avec les langages de programmation généraux : il nous faut donc un degré de programmabilité de ce niveau, c'est-à-dire un langage général qui soit accessible directement depuis l'interface utilisateur de l'application. Le fait qu'il soit général n'exclut d'ailleurs pas une orientation vers le domaine par la présence de composants spécialisés.

Et Programmer,

En s'intéressant à l'activité logicielle réelle des biologistes plutôt qu'à la programmation et comment la définir, il s'agit en définitive d'aborder le problème du point de vue des utilisateurs.

  Le premier bénéfice attendu de cette approche est l'intérêt évident qu'il y a à intéresser les futurs utilisateurs d'un logiciel à sa conception, et la source potentielle d'innovation technologique qu'ils représentent[START_REF] Mackay | Beyond iterative design: User innovation in co-adaptive systems[END_REF]. Mais c'est aussi de répondre à la question posée ci-dessus sans préjuger de la réponse : on ne cherche pas à définir un environnement ni un langage de programmation mais un environnement d'analyse de séquences. Si la programmation y trouve sa place, ce sera dans la continuité de la problématique et non comme un ensemble d'idées a priori.

programmer c'est... mais... La programmation c'est l'abstraction, la généralisation : écrire un programme c'est modéliser des objets d'une manière suffisamment générale. Programmer amène parfois aussi à spécialiser, comme par exemple aller directement dans le code pour personnaliser une partie. Écrire un pilote de périphérique, c'est l'opposé d'une généralisation. Prendre une algorithme général (programmation dynamique), et régler ses équations pour l'appliquer à un domaine spécifique (la comparaison de séquences d'ADN), c'est aussi de la programmation. L'essence de la programmation c'est la conception d'algorithmes. Une partie infime des programmes écrits comporte un nouvel algorithme. C'est même un lieu commun de dire que la plus grande partie des programmes n'est pas de nature algorithmique, mais est plutôt composée de «colle», d'entrées-sorties, d'interface utilisateur. Ou bien doit-on suivre une certaine idée selon laquelle la simple présence d'une boucle dénote la conception d'un algorithme ?

  ainsi que les développements autour de la réflexivité des langages peuvent s'avérer de bons modèles techniques pour la manipulation du code des différents niveaux de complexité de l'application. Le prototype étant développé dans un langage comportant une assez bonne réflexivité, il a été possible d'y implémenter les principes d'accès à travers l'interface : accès à l'arborescence des widgets ainsi qu'à toutes leurs caractériques, accès au code des commandes, clonage des objets graphiques, copier-coller direct de code source, ... • L'idée de ne pas avoir nécessairement à définir systématiquement des types et des classes semble raisonnable, puisqu'il s'agit plus d'une approche d'utilisation avancée que de construction logicielle et de modélisation. Toutefois cela doit pouvoir être possible.• Il est indispensable de disposer d'un répertoire de composants (commandes, fonctions, structures de donnés, widgets, ...) réalistes qui fonctionnent d'emblée sans programmation (un framework, mais déjà instancié) et qui peuvent être ré-utilisés non seulement par composition, mais aussi tout simplement comme exemples.

	SUR QUELS PRINCIPES TECHNIQUES PEUT-ON
	S'APPUYER ?
	Mon objectif n'est pas (ici) de proposer une boîte à outils
	ou une interface utilisateur, mais plutôt d'évaluer, parmi
	les techniques actuelles, celles qui correspondent le
	mieux au contexte du problème. J'ai commencé à implé-
	menter certains des principes qui suivent dans un premier
	prototype dont le but essentiel est de fournir une base
	concrète à des discussions avec les biologistes, afin de
	susciter des idées de leur part et d'évaluer la pertinence
	de ces hypothèses techniques.
	• Un langage de script semble un choix raisonnable
	dans un contexte d'outils traitant essentiellement des
	chaînes de caractères et du texte. Pour le prototype,
	c'est Tcl/Tk qui a été choisi. Il existe d'ailleurs déjà une
	base de composants développés dans ce langage par la
	communauté des bio-informaticiens.
	• Le modèle de programmabilité offert par les tableurs
	semble adéquat : il combine la puissance de la manipu-
	lation directe avec celle de la manipulation programma-
	tique. Le prototype développé reprend cette idée de
	définir automatiquement des variables associées aux
	objets graphiques : par exemple, des tags peuvent être
	définis interactivement, et utilisés comme variables.
	Tableau 1: définitions de la programmation.

• Le code source d'une partie significative de l'application -et c'est une des choses à déterminer lors des ateliers -doit pouvoir être accessible depuis l'interface, comme le code HTML d'une page Web, ou comme l'outliner d'un objet de l'environnement du langage de prototype Self

[START_REF] Smith | Programming as an Experience: The inspiration for Self[END_REF]

. Dans le même ordre d'idées les protocoles méta-objets

[START_REF] Kiczales | The Art of the Meta-Object Protocol[END_REF]

ou plus généralement les idées d'open implementation,

Compte tenu de cette analyse, notre problème semble donc résolu : il suffit de créer un langage/environnement de programmation ayant les propriétés énoncées ci-dessus. Mais le fait que les biologistes, dans leur ensemble, n'utilisent pas les nombreux langages et environnements à leur disposition amène à penser que cette analyse est trop courte. En réalité le problème des biologistes n'est pas tant les fonctionnalités du langage qu'on leur propose que l'intégration de l'activité de programmation dans leur contexte de travail. Or, si l'on sait bien ce qu'est un langage de programmation, il n'est pas si facile de définir la programmation elle-même. En guise d'illustration, le tableau 1 propose un certain nombre de définitions, dont chacune est aisément contredite.


Georgios Balikas
email: georgios.balikas@imag.fr

Reza Amini

Multi-label, Multi-class Classification using Polylingual Embeddings

We propose a Polylingual text Embedding (PE) strategy, that learns a language independent representation of texts using Neural Networks. We study the effects of bilingual representation learning for text classification and we empirically show that the learned representations achieve better classification performance compared to traditional bag-of-words and other monolingual distributed representations. The performance gains are more significant in the interesting case where only few labeled examples are available for training the classifiers.

Introduction and Preliminaries

In this work we propose a mechanism for combining distributed representations of documents in different languages. Each document in a given language is first translated using an existing Machine Translation (MT) tool. The rationale behind is that translation offers the possibility to enrich and disambiguate the text, especially for short documents. Documents are then represented by aggregating the embeddings of their associated text spans in each language [START_REF] Le | Distributed representations of sentences and documents[END_REF][START_REF] Mikolov | Distributed representations of words and phrases and their compositionality[END_REF] using a non-linear auto-encoder (AE). The AE is trained on their concatenated representations and a classifier is finally trained in the polylingual space outputed by the auto-encoder. Our classification results in a subset of the publicly available Wikipedia show that our approach yields improved classification performance compared to the case where a classical bag-of-words space is used for document representation, especially in the case where the size of the training set is small.

Neural Networks have recently shown promising results in several machine learning and information extraction tasks [START_REF] Tang | Learning sentiment-specific word embedding for twitter sentiment classification[END_REF][START_REF] Zhang | Text understanding from scratch[END_REF][START_REF] Gao | Learning continuous phrase representations for translation modeling[END_REF]. For text classification, the use of embeddings as inputs or initializations to more complex architectures has been investigated and, for example, [START_REF] Kalchbrenner | A convolutional neural network for modelling sentences[END_REF][START_REF] Kim | Convolutional neural networks for sentence classification[END_REF] study the benefits of embeddings of sentence-length spans (sentences and/or questions). In the multilingual setting, [START_REF] Gouws | Bilbowa: Fast bilingual distributed representations without word alignments[END_REF] proposed an approach to learn bilingual embeddings exploiting parallel and non-parallel text in the languages, [START_REF] Faruqui | Improving vector space word representations using multilingual correlation[END_REF] proposed to use correlated components analysis, together with small bi-lingual lexicons, to learn how to project embeddings in two separate languages into a common representation space and [START_REF] Lauly | An autoencoder approach to learning bilingual word representations[END_REF] proposed an approach similar to ours that uses an auto-encoder to learn bilingual representations.

In the next section we present our polylingual embedding strategy. In the experimental part (Section 3), we empirically show that the learned representations constitute better classification features compared to several baselines and their value can strongly benefit classification settings with few labeled examples. We discuss these results in Section 4 and conclude in Section 5.

The proposed approach

Monolingual distributed representations (DRs) project text spans into a languagedependent semantic space where spans with similar semantics are closer in that space. Here, we aim to combine two distributed representations of documents corresponding to the original document and its translation using an auto-encoder. We will refer to those combined representations as Polylingual Embeddings (PE). We suppose that the auto-encoder will disentangle the language-dependent factors and will learn robust representations on its hidden layer encoding as illustrated in Figure 1. Given a document d i in English, we first translate it into French using a commercial translator, we then generate the distributed representations of the document and its translation {G (d i )} 2 =1 , and then aggregate those DRs using an auto-encoder (Algorithm 1).

The auto-encoder is learned over all concatenated distributed representations of documents using a stochastic back-propagation algorithm. In this work we consider two strategies to create the DR of each document. The first one is based on average pooling, where word representations are first obtained using the word2vec tool [START_REF] Mikolov | Efficient estimation of word representations in vector space[END_REF]. DR of documents, i.e. functions (G ) ∈{1,2} , are then obtained by averaging the vectors of words contained in them. In this study we consider the continuous bag of words (cbow) and the skip-gram models that generate word representations. The second strategy is based on the distributed Memory Model of paragraph vectors (DMMpv) and distributed bag-of-words of paragraph vectors (DBOWpv) models [START_REF] Le | Distributed representations of sentences and documents[END_REF], that extend cbow and skip-gram respectively. In this case, (G ) ∈{1,2} are defined by the output of the models without further processing.

Require: {G (d i )} 2 =1 , a trained AE 1: for each document d i do 2: Concatenate G 1 (d i ) and G 2 (d i ) 3:
Get PE representation of d i as the hidden encoding of the AE fed with the concatenation

The Experimental Framework

The data. Training neural network models to generate distributed representations benefits by large amounts of free text. To train the models that generate DRs we used such free texts in English and French:3 the left part of Table 1 (under "Distributed Representations") presents some basic statistics for those data. We used the same number of documents for the two languages to avoid any training bias. The raw text was pre-processed by applying lower-casing and space-padding punctuation. Similarly to previous studies [START_REF] Mikolov | Efficient estimation of word representations in vector space[END_REF][START_REF] Le | Distributed representations of sentences and documents[END_REF], we kept the punctuation. Publicly available implementations of the models were used with their default parameters: the word2vec tool 4 for the cbow and skip-gram and the doc2vec for the DBOWpv and DMMpv from Gensim [START_REF] Řehůřek | Software Framework for Topic Modelling with Large Corpora[END_REF].

For the classification task we used the raw version of the Wikipedia dataset of the Large Scale Hierarchical Text Classification challenge [START_REF] Partalas | Lshtc: A benchmark for largescale text classification[END_REF]. The original dataset contains 60,252 categories; we restrict our study here in a fraction of the dataset with 12,670 documents belonging to the 100 most common categories. The right part of Table 1 presents basic statistics for this subset. Baselines. We used as a first baseline Support Vectors Machines (SVM) fed with the tf-idf representation of the documents, which is commonly used in text classification problems (denoted by SVM BoW ). As a second baseline, we used k-Nearest Neighbours (k-NN) and SVMs learned on the monolingual space of the DRs of English documents (denoted respectively by SVM DR and k-NN DR ). These baselines aim at evaluating the value of the fusion mechanism (PE) that we propose. k-NN and SVMs were adapted to the multi-label setting (denoted respectively by SVM PE and k-NN PE ). For the former, given the labels of the k nearest training instances of a test document, the algorithm returns the labels that belong to at least p% of its nearest neighbours. For each run k ∈ {13, 14, 15} and p ∈ {0.1, 0.2, 0.3} are decided using 5-fold cross-validation on the training data. The SVMs were used in an one-vs-rest fashion; they return every label that has a positive distance from the separating hyperplane. The value of the hyperparameter C ∈ {10 -1 , . . . , 10 4 } that controls the importance of the regularization term in the optimization problem, is selected using 5-fold cross-validation over the training data. Then, for the AE we considered as activation functions the hyperbolic tangent and the sigmoid function. The sigmoid performed consistently better and thus we use it in the reported results. The AE was trained with tied weights using a stochastic back-propagation algorithm with mini-batchs of size 10 and the euclidean distance of the input/output as loss function. The number of neurons in the hidden layer was set to be 70% of the size of the input.5

Experimental Results

Table 2 presents the scores of the F 1 measure when 10% of the 12.670 documents were used for training purposes and the rest 90% for testing. We report the classification performance with the four different DR models (cbow, skipgram, DBOWpv and DMMpv) and 2 learning algorithms (k-NN and SVMs) for different input sizes. The columns labeled k-NN DR and SVM DR present the (baseline) performance of SVM and k-NN trained on the monolingual DRs. Also the last line of the table indicates the F 1 score of SVM with tf-idf representation (SVM BoW ). The best obtained result is shown in bold. We first notice that the average pooling strategy (cbow and skip-gram) performs better compared to when the document vectors are directly learned (DBOWpv and DMMpv). In particular, cbow seems to be the best performing representation, both as a baseline model and when used as base model to generate the PE representations. On the other hand, DBOWpv and DMMpv perform significantly worse: in the baseline setting the best cbow performance achieved is 44.25 whereas the best DMMpv configuration achieves 30.49, 14 F 1 points less.

The PE representations learned on top of the four base models improve significantly over the performance of the monolingual DRs, especially for k-NN. Comparing the two learning methods (k-NN PE and SVM PE ), we notice that k-NN PE performs best. This is motivated by the fact that distributed representations are supposed to capture the semantics in the low dimensional space. At the same time, the neighbours algorithm compares exactly this semantic distance between data instances, whereas SVMs tries to draw separating hyperplanes among them. Finally, it is known that SVMs benefit from high-dimensional vectors such as bag-of-words representations. Notably, in our experiments increasing the dimension of the representations consistently benefits SVMs.

We now examine the performance of the PE representations taking into account the amount of labeled training data. Figure 2 illustrates the performance of the SVM BoW and SVM PE and k-NN PE with PE representations when the fraction of the available training data varies from 10% of the intial training set to 90% and in the case where, cbow and skip-gram are used as DR representations with an input size of 300. Note that if only a few training documents are available, the learning approach is strongly benefited by the rich PE representations, that outperforms the traditional SVM BoW setting consistently. For instance, in the experiments with 300 dimensional PE representations with cbow DRs, when only 20% of the data are labeled, the SVM BoW needs 20% more data to achieve similar performance, a pattern that is observed in most of the runs in the figure. When, however, more training data are available the tf-idf copes with the complexity of the problem and levarages this wealth of information more efficiently than PE does.

Conclusion

We proposed the PE, which is a text embedding learned using neural networks by leveraging translations of the input text. We empirically showed the effectiveness of the bilingual embedding for classification especially in the interesting case where few labeled training data are available for learning.

Fig. 2 :

 2 Fig. 2: Comparison of the performance of the learning algorithms learned on different representations with respect to the available labelled data. The dimension of the PE representations is 300.

Table 1 :

 1 Statistics after pre-processing the datasets. The distributed representations dataset refers to the data used to train G. The classification data refer to the supervised dataset used for classification purposes.

		Input		Output
		layer	Hidden	layer
		W	layer	W T
		English		English
			. . .
		French		French
	4: end for
	Algorithm 1: The process of generating PE representations	Fig. 1: An AE that generates the PE in its hidden layer. The dashed boxes de-note the document DRs in the corre-
		sponding language.

Table 2 :

 2 F 1 measures of difference algorithms. The performance of 5-fold crossvalidated SVM using the bag-of-words representation is 36.03 Our approach. Using the above presented DR model, we first generated the document embeddings in English and French in a d-dimensional space with d ∈ {50, 100, 200, 300}.

			cbow			skip-gram
	dim.	k-NNDR SVMDR k-NNPE SVMPE k-NNDR SVMDR k-NNPE SVMPE
	50	39.19	37.20	39.58	32.84	38.25	34.74	37.51	32.09
	100	40.20	40.01	43.53	37.54	39.34	38.61	41.15	34.54
	200	40.48	43.41	45.86	42.50	39.73	40.96	42.79	41.08
	300	40.42	44.25	46.33	43.38	39.62	42.67	42.62	42.74
			DBOWpv			DMMpv
	50	24.45	25.06	30.26	24.08	24.47	25.56	29.55	24.94
	100	31.20	28.53	34.63	26.88	24.74	29.31	31.21	27.22
	200	27.73	29.80	36.02	30.80	18.22	30.04	29.01	32.10
	300	27.79	29.92	38.71	30.82	15.98	30.49	25.20	32.01
	SVMBoW				36.03

http://statmt.org/

https://code.google.com/p/word2vec/

The code is available at http://ama.liglab.fr/ ~balikas/ecir2015.zip.

Acknowledgements

We would like to thank the anonymous reviewers for their valuable comments. This work is partially supported by the CIFRE N 28/2015 and by the LabEx PERSYVAL Lab ANR-11-LABX-0025.