abstract: Custom hardware accelerators for Deep Neural Networks are increasingly popular: in fact, the flexibility and performance offered by FPGAs are well-suited to the computational effort and low latency constraints required by many image recognition and natural language processing tasks. The gap between high-level Machine Learning frameworks (e.g., Tensorflow, Pytorch) and low-level hardware design in Verilog/VHDL creates a barrier to widespread adoption of FPGAs, which can be overcome with the help of High-Level Synthesis. hls4ml is a framework that translates Deep Neural Networks into annotated C++ code for High-Level Synthesis, offering a complete and user-friendly design process that has been enthusiastically adopted in physics research. We analyze the strengths and weaknesses of hls4ml, drafting a plan to enhance its core library of components in order to allow more advanced optimizations, target a wider selection of FPGAs, and support larger Neural Network models.
author:
title: De-specializing an HLS library for Deep Neural Networks: improvements upon hls4ml

# Introduction

Deep Neural Networks (and other types of Machine Learning models) are data-hungry, computationally intensive algorithms capable of obtaining outstanding results in applications such as image classification and speech recognition. As new models keep growing in size and complexity, their number of operations and memory footprint pose significant challenges, especially under the strict latency and power consumption constraints typical of real-time edge systems.

Thus, there is a growing need for specialized inference accelerators, with FPGA-based solutions often providing a good trade-off between flexibility and performance. FPGAs offer a faster design time than ASICs, reconfigurability allows them to keep up with the ongoing evolution of Neural Network models, and they consume significantly less power than GPUs. They can be used to create either processor-like systems that support many types of Neural Networks or specialized accelerators tailored to a single network model.

The main obstacle to broader adoption of FPGAs in the Deep Learning community is the wide gap between software design and RTL implementation: the translation of a Deep Neural Network model (typically written and trained in a Python-based software framework) into an efficient FPGA design requires hardware expertise that is not easily found among Machine Learning experts. Automatic design flows have been proposed to mitigate this issue; many exploit well-established High-Level Synthesis techniques to translate annotated C/C++ code into Verilog/VHDL.

One HLS-based framework is hls4ml , which was first developed to enhance high energy physics experiments at CERN by simplifying the development of Deep Learning accelerators on FPGA. hls4ml is rapidly evolving; however, its core functionality remains tied to a library of C++ components representing standard Deep Learning operators. This library has been optimized for Vivado HLS (Xilinx's High-Level Synthesis tool), it contains parametric data types to allow quantization, and it assumes that the accelerator will be composed of a sequence of operators representing the different network layers.

We argue that such characteristics limit the real applicability of hls4ml to state-of-the-art Deep Neural Network models and propose modifications to the library of components that have the potential of making it more portable and efficient. We also aim to substitute commercial tool Vivado HLS with an open-source High-Level Synthesis engine, Bambu , to have more control on the translation from C++ to Verilog/VHDL and to increase the number of supported FPGA targets. Part of this work has only been outlined in theory, while part of it is currently under development, and we expect to support our claims with experimental evidence within a short time frame.

# HLS tools and compilers for Deep Learning

Extensive research has been published on specialized processors for Deep Learning, and many of them were implemented on FPGA. With a fixed processor template, different applications can achieve different performance depending on how well they exploit the available computational resources. Instead, our focus in this section is on tools and compilers to support the development of accelerators tuned to a specific application and a specific Neural Network model, sacrificing flexibility to result in a better performance.

The automatic translation of Deep Neural Network models into FPGA accelerators often relies on well-established High-Level Synthesis techniques to generate Verilog/VHDL code. Whether they start from a pre-trained, unspecialized model or choose a hardware/network co-design approach, existing workflows are often composed of two steps. First, the high-level Neural Network model is translated into a lower-level software programming language, and then High-Level Synthesis is applied to this intermediate representation to obtain an RTL design, ready to be synthesized and deployed on FPGA.

hls4ml follows this pattern: it is a toolchain designed to exploit High-Level Synthesis in the implementation flow for a Deep Neural Network accelerator on FPGA, and its intermediate format is C++ code. Section analyzes hls4ml more in detail since it is the baseline upon which our work is going to be developed.

FINN is a compiler framework targeting Xilinx FPGAs that can produce high-throughput hardware accelerators and help explore architectural trade-offs. Its primary focus is on quantized Deep Neural Networks: floating-point data are substituted with smaller, fixed-point types that are better suited to resource-limited FPGAs. In particular, FINN works very well with extremely low bit-widths (less than 4 bits fixed-point), and it contains a Pytorch library for quantization-aware training to ensure reasonable accuracy even with such small data types. Underneath the surface, FINN's approach is based on a library of parametric C components optimized for Vivado HLS. The user can choose between two accelerator templates with different resource utilization and throughput characteristics: a feed-forward streaming dataflow pipeline (for small networks that can afford to store all weights on-chip) or a computation engine that offloads part of the data to external memory (for larger networks or smaller boards). FINN is a powerful tool because it integrates each step of the design and implementation flow, from the definition and training of the network to the deployment of the accelerator on AWS FPGA instances. Nevertheless, the compilation passes are designed for quantization-aware models with extremely low bit-widths, resulting in a network/hardware co-design approach that is not directly applicable to a generic pre-trained Deep Neural Network.

LeFlow is another HLS-based project supporting the automatic implementation of Deep Learning operators on FPGA. The input is a Tensorflow graph, transformed by Google's XLA compiler into an LLVM IR that can be processed by the LegUp HLS tool. The obtained accelerators represent typical Neural Network layers, working under the assumption that both weights and inputs of the model are available on-chip: this strongly limits the possibility of using the same toolchain on complete networks. Moreover, XLA is built to generate code for CPUs and GPUs, resulting in LLVM IRs that are not suitable for FPGAs and too low-level to apply meaningful optimizations.

Other tools exist that offer automatic methods to deploy Deep Neural Networks on FPGAs, as the ones described in . Most of them support fixed-point data types arguing that the additional accuracy of floating-point calculation does not compensate for the resource utilization overhead; some are based on HLS, while others provide hand-written RTL kernels. They are all focused on accelerating Convolutional Neural Networks, which are the backbone of computer vision tasks, so they benefit from the regular computation patterns, redundancy, and reduced dynamic range typical of convolutional layers.

# hls4ml: benefits and drawbacks

hls4ml was initially presented as a compiler for the implementation of fully connected Neural Networks on FPGA , presenting a specific use case where a Multi-Layer Perceptron was used to perform a classification task within a physics experiment at CERN. hls4ml automatically translates high-level models built and trained within typical Deep Learning frameworks (Keras, Tensorflow, Pytorch, or any other that can export graphs in the ONNX format) into C++ code and then uses Vivado HLS to generate a corresponding RTL design. The translation to C++ is based on a library of parametric templates that work with fixed-point data types, effectively quantizing the original model post-training. Other optimizations introduced to comply with the strict latency constraints imposed by the experiment are weights compression (pruning) and parallelization of multiplications. Following studies presented additions to the tool to support quantization-aware training and automatic heterogeneous quantization , binary and ternary networks , and Convolutional Neural Networks .

A user-friendly interface based on Python makes hls4ml accessible to Deep Learning developers that are not familiar with hardware design. Key optimization choices are exposed as configuration options: the user can specify a data type for the whole model or on a per-layer basis and tune parallelism against resource usage for multipliers (reuse factor). Network compression is exploited by enforcing sparsity in the training phase and relying on Vivado HLS to eliminate operations with zero-weights, so there is no configuration option to control pruning. After the user imported a model and specified configuration options, hls4ml parses the model and builds a C++ representation: it selects the corresponding operators from a library of parametric components, adjusts data types for weights, biases, and results, and adds compilation directives (pragmas) to drive the High-Level Synthesis process according to the user-defined configuration. Finally, hls4ml takes care of launching Vivado HLS and logic synthesis tools to generate the design and evaluate its performance.

Alongside the evident benefits that hls4ml can offer in the automation of what would otherwise be a long, expensive manual translation, there are some drawbacks that inherently limit its usage. Appropriate implementation choices for small, fully-connected models under tight latency constraints may not always be beneficial for larger networks: most notably, storing network weights inside on-chip logic and unrolling all loops to increase parallelism quickly depletes available resources. This approach does not scale well to state-of-the-art Deep Neural Networks, having orders of magnitude more weights and computations than the 3-layer MLP model presented in the original hls4ml publication. Moreover, optimizing the C++ library for Vivado HLS prevents the use of hls4ml to develop accelerators on FPGAs from vendors other than Xilinx. To the best of our knowledge, support to target Intel FPGAs is under development, but it may require a new implementation of the components library, reinforcing our hypothesis that portability is a weak point for hls4ml.

The library implementation of activation functions contains a practical example of features that are only applicable on a Xilinx backend through Vivado HLS. Non-trivial activation functions (including softmax) are implemented as tables of constant values representing the function output for a given range of inputs. To create the tables, the C++ library initializes a list of values following a pattern that Vivado HLS recognizes and transforms at compile-time so that the final RTL design only contains the pre-computed lookup table stored in BRAMs. Instead, other HLS tools may not interpret the C++ pattern as the construction of a constant table, wasting resources and increasing the overall latency to implement the actual mathematical functions and control logic contained in the code.

While investigating this issue, we also found out that if the configuration defines a default fixed-point type for the entire network, the decision is overwritten in the softmax layer with a fixed-point type empirically selected to fill the available BRAM size on specific Xilinx FPGA models. In particular, to target a Xilinx 18k BRAM, tables of 1024 elements encoded as 18-bit fixed-point values are used.

# Proposed improvements

Our work aims at overcoming some limitations of the hls4ml framework to increase its efficiency and applicability: the front-end to import models will mostly remain unchanged to maintain a user-friendly interface, while the library of C++ components will need significant modifications. In this first phase, we conducted an in-depth analysis of hls4ml and identified key opportunities for improvement: some of those are still preliminary ideas, and they will need further study and refinement; for others, we defined a path towards implementation. The following sections describe the two areas where we propose to focus our efforts.

## Portability

hls4ml uses Vivado HLS as back-end to generate RTL designs from C++ code, and this choice strongly influences the library of components used to build the C++ representation of the input Neural Network model. Each component is described with coding techniques and compiler directives (pragmas) specific to Vivado HLS, limiting the portability of code to other High-Level Synthesis tools. Efforts to make the library less specific would enable using different HLS and logic synthesis tools in the back-end, extending the range of supported FPGA platforms: our goal is to leverage an open-source HLS tool, PandA-bambu , but the de-specialization of the library would also open the way for other commercial and open-source HLS tools.

Modifications to the library have already started: as described in Section , the implementation of activation functions as tables of constant values depended on a special feature of Vivado HLS, so we had to find a different solution to replicate the same behavior in a way that other tools could correctly interpret. Arrays of constant values can be computed exploiting the concept of 'constexpr,' introduced in the C++11 standard to identify functions and variables that can be evaluated at compile-time, together with some functions of the C++14 standard library. In our new implementation, each activation function contains a static method called 'compute()' with instructions for the computation of the desired function output. A dedicated class template is called to initialize the constant tables, requiring as input the 'compute()' method and the length N of the array that will be constructed: at compile-time, a constexpr array of N elements will be created and populated with values calculated by the specific 'compute()' method. This version of the code correctly produces tables of constant values thanks to compile-time expression resolution, and it does not need to rely on Vivado HLS anymore.

The realization of this solution highlighted some additional issues: for example, hls4ml uses data types from the arbitrary precision library by Xilinx (ap_types ), which cannot be used within a constexpr. Instead of modifying the ap_types library, we preferred to replace it with our extension of a similar open source library based on the "Algorithmic C (AC)" data types from Mentor Graphics . Both libraries are designed for functional simulation, and they have separate synthesis-oriented implementations that are only compatible with a specific High-Level Synthesis tool: our modified version of ac_types instead is already optimized for synthesis, and it can be compiled with standard C/C++ compilers. With a few modifications, the types defined by our library can be used within constexpr. Finally, the original implementations of the activation functions were based on mathematical functions available in the C++ standard library (exponential, trigonometric, and hyperbolic functions), which were also not compatible with constexpr, so it was necessary to substitute them with the constexpr-compliant math library 'gcem' .

## Quantization

Together with the low power consumption, speed, and flexibility, another feature offered by FPGAs is the possibility of exploring custom data types, exposing opportunities for quantization that are not available or inefficient on general-purpose processors. Neural Networks are inherently robust to errors, so quantization to integer and fixed-point data types has been widely studied and applied, with different techniques and on different hardware platforms. The underlying assumption is that a small percentage loss in accuracy is well compensated by significant reductions in power consumption, memory requirements, and area utilization: floating-point data types are considered essential during the training phase but inefficient for inference.

However, it is reasonable to assume that not all application scenarios that would benefit from FPGA acceleration are tolerant to the accuracy loss introduced by integer and fixed-point quantization (especially if applied post-training). Custom floating-point data types, based on the IEEE standard or with entirely different numeric encodings, can disclose a new design space where the accuracy is improved with respect to fixed-point quantization and performances are better than baseline floating-point models.

In hls4ml, fixed-point quantization is the default choice: the user can select the most appropriate fixed-point formats for each layer of the input model, evaluating through simulation what is their impact on accuracy and performance. The underlying assumption is that FPGA implementations of floating-point operations are usually inefficient (Vivado HLS itself often discourages the use of floating-point data types). Instead, we want to extend the library of components to allow the use of customized floating-point data types in hls4ml: we have full control over the internal behavior of bambu, so it will be possible to match custom data types in the C++ representation with optimized RTL operators. The front-end to import models will not require substantial modifications, while support for functional simulation will be added to measure accuracy loss; in the future, it could also be useful to introduce automatic design space exploration tools to direct the choice of data types.

# Conclusion

hls4ml is a useful tool to simplify the translation of Deep Neural Network models into FPGA accelerators: its current version can produce optimized designs with low latency for a small class of input models, targeting Xilinx FPGAs through Vivado HLS. In this paper, we outlined a plan to modify the C++ library at the core of hls4ml to remove some of its limitations: we expect that our de-specialization effort will increase the applicability to a more diverse set of input applications and portability to a broader selection of FPGA targets, while at the same time leading to the creation of more efficient accelerators.


abstract: Textual sentiment analysis and emotion detection consists in retrieving the sentiment or emotion carried by a text or document. This task can be useful in many domains: opinion mining, prediction, feedbacks, etc. However, building a *general purpose* tool for doing sentiment analysis and emotion detection raises a number of issues, theoretical issues like the dependence to the domain or to the language but also pratical issues like the emotion representation for interoperability. In this paper we present our sentiment/emotion analysis tools, the way we propose to circumvent the difficulties and the applications they are used for.
author: Alexandre Denis; Samuel Cruz-Lara; Nadia Bellalem
title: General Purpose Textual Sentiment Analysis and Emotion Detection Tools

# Sentiment Analysis and Emotion Detection from text

## Definition

One of the most complete definition of the sentiment analysis task is proposed by Liu in which a sentiment is defined as a quintuple $\langle e, a, s, h, t\rangle$ where $e$ is the name of an entity, $a$ an aspect of this entity, $s$ is a sentiment value about $a$, $h$ is the opinion holder and $t$ is the time when the opinion is expressed by $h$. The sentiment analysis task consists in outputing for a given text or sentence the set of sentiments that this text conveys. Whereas sentiment analysis is limited in general to binary sentiment value (positive, negative) or ternary (positive, negative, neutral), emotion detection consists in determining the sentiment value among a larger set of emotions, typically Ekman's emotions : joy, fear, sadness, anger, disgust, or surprise.

## Difficulties and existing approaches

A difficult aspect of sentiment analysis is the fact that a given word can have a different polarity in a different context. In , authors oppose the *prior polarity* of a word, that is the polarity that a word can have out of context, and the *contextual polarity*, that is the polarity of a word in a particular context. There are many complex phenomena that influence the contextual valence of a word as the table  shows, and most of the approaches thus reduce the scope of the problem to $\langle s \rangle$ the sole sentiment value or sometimes to $\langle e, s, h
\rangle$, the entity, the sentiment value and the holder like in .

Given the complexity of the task, it is not a surprise that the first approaches to the problem use machine learning. In an unsupervised approach is proposed. It uses the Pointwise Mutual Information distance between online reviews and the words "excellent" and "poor". Its accuracy ranges from 84% for the automobile reviews to 66% for the movie reviews. In , a corpus of movie reviews and their annotation in terms of number of stars is used to train several classifiers (Naive Bayes, Support Vector Machine and Maximum Entropy) and obtain a good score for the best (around 83%). More recent work in machine learning approaches to sentiment analysis explore successfully different kinds of learning algorithms such as Conditional Random Fields or autoencoders which are a kind of Neural Networks and which offer good performance on the movie reviews domain . A detailed and exhaustive survey of the field can be found in .

# Cross Domains problems

A general purpose sentiment analysis or emotion detection tool is meant to work in different domains with different applications and thus faces at least three problems: the dependence of the algorithms to the domain they were developed on, the representation of emotions/sentiments for interoperability, and the fact that different applications may require other languages than English, and as such the multilinguality issue must be considered. We detail these three problems in this section.

## Domain dependence

#### Machine learning dependence

An important issue of supervised machine learning is the dependence to the training domain. Classical supervised algorithms require a new training corpus each time a new domain is tackled. In several methods are tried to overcome the domain-dependence of machine learning and they show that the best results can be obtained by combining small amounts of labeled data from the training domain and large amounts of unlabeled datas in the target domain. Actually, unsupervised or semi-supervised machine learning seems more adequate than purely supervised machine learning to reach domain-independence . Another approach is to use hybrid methods, classifiers trained on corpora and polarity lexicons. Indeed, polarity lexicons, such as Sentiwordnet or the Liu Lexicon , being in general domain-independent seem to be an interesting track to follow.

#### Types of emotions dependence

Moreover the set of relevant emotions depends on the domain. In a generic emotion analysis tool, there is not much choice apart providing a set of the least domain specific emotions, hence the frequent choice of Ekman's emotions. These may not describe accurately the affective states in all domains, for instance their use is criticized in the learning domain , but their independence to the domain and the existence of Ekman's based emotional lexicons such as WordNet-Affect  makes them a common practical choice.

## Interoperability

The representation of emotions for interoperability is an important issue for a sentiment/emotion analysis tool that is meant to work in several domains and with several applications. We advocate the use of EmotionML a W3C proposed recommendation for the representation of emotions. An interesting aspect of EmotionML is the acknowledgement that there exists no consensus on how to represent an emotion, for instance is an emotion better represented as a cognitive-affective state like , as a combination between pleasure and arousal like , or as an Ekman emotion ? Thus, EmotionML proposes instead an emotion skeleton whose features are defined by the target application. An emotion is defined by a set of descriptors, either dimensional (a value between 0 and 1) or categorical (a discreet value), and each descriptor refers to an emotional vocabulary document. An emotion and its vocabulary can be embedded in one single document or the emotion can refer to an online vocabulary document.

## Multilinguality

A general purpose sentiment/emotion analysis tool is also required to be working in other languages than English. Most of the work related to multilinguality is tied to subjectivity analysis, a simpler sentiment-like analysis which consists in determining whether a text conveys an objective or subjective assessement. Several solutions are possible, for instance training classifiers on translated corpora, using translated lexicons, building lexicons or corpora for targeted language . Recent experiments with automatic translation for sentiment analysis show that the performance of machine translation does not degrade the results too much . We refer the interested reader to for a good overview of the topic.

# Tools and applications

We present here the sentiment/emotion analysis tools and the applications that use them in the context of the Empathic Products ITEA2 project (11005)[^1], a european project dedicated to the creation of applications that adapt to the intentional and emotional state of the users.

## Sentiment/emotion analysis tools

We implemented several sentiment analysis and emotion detection engines, and will briefly present them here. All of them are integrated in one Web API that takes text in input and returns a single emotion formatted in EmotionML format, dimensional valence for sentiment analysis engines and categorical emotion for the emotion detection engines[^2]. A support also exists for non-English languages following using Google machine translation but this service has not yet been evaluated.

For emotion detection, the approach uses an emotion lexicon, namely WordNet-Affect by detecting emotional keywords in text complemented with a naive treatment of negation which inverts the found emotion, ad hoc filters (smileys, keyphrases) and simple semantic rules. Despite its simplicity this tool manages to reach performance similar to other approaches when evaluated on the Semeval-07 affective task dataset , it obtains 54.9% of accuracy given an emotion to valence mapping (joy is positive and the others are negative).

For sentiment analysis, we are currently exploring two opposed approaches, one symbolic and one with machine learning. The symbolic approach follows as an attempt to both tackle the linguistic difficulties we mentioned thanks to valence shifting rules and domain dependence by using general purpose lexicons. It works by first retrieving the prior polarity of words as found in the Liu lexicon after a part-of-speech tagging phase with the Stanford CoreNLP library. Then, a parsing phase enables to construct the dependencies (also with Stanford CoreNLP), the resulting dependencies are filtered such that prior word valence is propagated along the dependencies following manually crafted rules for valence shifting or inversion. This approach enables to be more precise, for instance the sentence "I don't think it's a missed opportunity" would be tagged as positive by the application of two valence flipping rules, a modifier rule for "missed opportunity", and a verb negation rule for "don't think". This approach obtains 56.3% accuracy on the Semeval-07 dataset and 65.86% accuracy on the Semeval-13 data set. The impact of rules has also been evaluated and show that the rules enable to gain 5% accuracy on the Semeval-13 dataset as opposed to a simple lexical approach that only takes the average valence of all words contained in a sentence.

The second approach relies on machine learning by training a classifier, namely a Random Forest classifier evaluated on the Semeval-13 dataset. It uses simple features such as the stemmed words and the part-of-speech but manages to obtain 64.30% accuracy on Semeval-07 and 60.72% accuracy on Semeval-13 both evaluated with 10-fold cross validation. We also performed preliminary evaluation of the cross-domain abilities of the statistical approach and observed that when trained on the Semeval-07 dataset and evaluated on Semeval-13 it obtains 47.08% accuracy. While training it on Semeval-13 and evaluating it on Semeval-07, it obtains 55.5% accuracy. The significant difference is likely caused by the dataset dissimilarities: first the Semeval-07 dataset is much smaller than Semeval-13 (1000 utterances vs 7500 utterances) and then, training on Semeval-07 is less efficient, and second the Semeval-07 dataset only consists in short news headline while the Semeval-13 dataset is composed of tweets which are much longer and then a better source for training. We assume that the difference in text length could also explain the difference in the results for the symbolic approach (56% vs 65.86%) since it is known that text length can influence the performance of sentiment analysis engines. A less difficult cross-domain evaluation would then rely on datasets that share the same properties in terms of text length and available data size.

## Applications

### Video conference feedback

One problem of video conference is the lack of feedback that the presenter can have about its remote audience. The first application of our sentiment/emotion analysis tool consists in providing the presenter an aggregated feedback of the emotional state of its audience. We assume that the audience is both attending to the videoconference remotely and expressing its feelings over a textual channel, using Twitter, Facebook or by chat. Moreover in the context of the Empathic Products project, the audience video feedback is also analyzed with regards to visual emotions. The interoperability solution based on EmotionML proves to be an efficient option for combining the two kinds of feedbacks. The most generic emotional output is the binary valence which offers a basic yet more reliable characterization of the affective state of the audience. Emotions are also possible, but depending on the video domain (e-learning, news, etc.), Ekman's emotions may not be fully relevant. The sentiment/emotion of all messages sent by audience participants is averaged; when using valence it is possible to animate a gauge, when using emotions, it is possible to animate iconic emotion representations (fig. )

### E-learning virtual world emotion tagging

E-learning in a virtual world requires some level of investment by the participants and is eased by their collaboration. It has been shown that emotional information can enhance the collaboration. For instance show that participants interact more if provided with emotional clues about their partner's current state. We propose to integrate our sentiment analysis tool to the Umniverse collaborative virtual world : the virtual world works as a situated forum in which participants can move around and submit posts. When participants submit posts they can annotate by hand the emotion that their post carries (with Ekman's emotions). Our tool can then be used to pre-annotate each post by proposing automatically an emotion. After posts have been annotated and published to the forum, it is possible to filter the existing posts by their annotated emotion and as such find all the posts that carry sadness for example.

### Global opinion of TV viewers

An early application for sentiment analysis has been the annotation of movie reviews in order to automatically infer the sentiment of viewers towards a movie . We propose to apply the same idea to the TV shows. It is known that regular TV shows have Twitter fan-base who discusses the show. The idea is thus to conduct sentiment/emotion analysis on Twitter streams that are related to a particular TV show. The ongoing work related to that application is thus inline with recent work in sentiment analysis and emotion detection in Twitter, see for instance .

# Conclusion

When developing a sentiment/emotion analysis service that is meant to be generic enough to work with several different applications, it is important to consider whether the algorithms are tied to a particular domain, whether the representation of output emotions is homogenous for all applications and whether the algorithms may be adapted to other languages than English. We detailed these three problems while mentioning the existing solutions to them. We introduced our own sentiment/emotion analysis service developed in the context of the Empathic Products ITEA project which partially adresses these problems. While interoperability seems satisfactory enough and multilinguality support has already been shown to be robust when using machine translation, the domain dependence aspects could be improved. In particular we evaluated the algorithms on two quite different domains, the news headlines provided by the Semeval-07 affective task evaluation and the tweets provided by the Semeval-13 sentiment analysis in Twitter evaluation. The results show significant difference, probably caused by the difference of text length between the two types of dataset. Nevertheless, for future work we are considering approaches that are more hybrid such as in order to tackle domain dependence.
*This work was conducted in the context of the ITEA2 "Empathic Products" project, ITEA2 1105, and is supported by funding from the French Services, Industry and Competitivity General Direction.*

[^1]: http://www.empathic.eu/

[^2]: The Web API is currently accessible on http://talc2.loria.fr/empathic