dataesr/scientific-paragraphs-categorization huggingface dataset:
6-b ). For each focus location we calibrated the system and re-emitted the time-reversed buffer (see Table  I ) with 5 milliseconds pulse repetition period and 10% duty cycle (approximately 38 milliwatts per square centimeter temporal average intensity at the piezo disc at 10 volts). For each sampling location we logged with an oscilloscope one instance of the original analog waveform of the time-reversed signal (1 millisecond at 2. 5 megahertz). Subsequently, we simultaneously activated all transmitters with ten cycles to log the unfocused signals. We recorded 2 × 9 × 9 = 162 data set. Capturing all sets lasted approximately 90 minutes. 3) Findings: Fig. 7  shows the areas on the hand affected by ultrasound. The unfocused waves have the same energy distribution in all sets (see Fig. 7-a ).
With the emergence of Docker, it becomes easier to encapsulate applications and their dependencies into lightweight Linux containers and make them available to the world by deploying them in the cloud. Compared to hypervisorbased virtualization approaches, the use of containers provides faster start-ups times and reduces the consumption of computer resources. However, Docker lacks of deployability verification tool for containers at design time. Currently, the only way to be sure that the designed containers will execute well is to test them in a running system. If errors occur, a correction is made but this operation can be repeated several times before the deployment becomes operational. Docker does not provide a solution to increase or decrease the size of container resources in demand.
• Docker registry is on the right-hand side in Figure  1. It stores and distributes images. The default registry is the Docker Hub, which hosts thousands of public images. Docker containers are created using base images. A Docker image can include just the OS fundamentals, or it can consist of a sophisticated pre-built application stack ready for launching. To create an image, the most convenient option is to write a script file composed of various commands (instructions) named Dockerfile and then execute it. Many organizations run their own registry that can be used to store private images. The Docker daemon will download images from registry in response to requests.
Thus, shared tasks provide an opportunity to overcome some of the challenges to replication in natural language processing-in particular, the definitional, data, and scoring issues. The work reported here explores the question of whether the evaluation of replicability in natural language processing can be pushed forward to the highest level of the replicability hierarchy by taking advantage of these aspects of the shared task model. The rationale behind this approach is that one can capitalize on the fact that the systems that are used to address a challenge task all accommodate the same input and output formats, as specified in the challenge. And, the scoring code is open and freely available. Therefore, system results on a challenge dataset should be very easy to replicate without incurring significant training and effort-or, at least, they should be possible to replicate, if given access to the original system.
Results A total of seven teams participated in CLEF eHealth 2016 task 2. Three teams submitted systems to the replication track. One team submitted a system that addressed the subtask of named entity extraction and Question Scoring Scale Part 1. System configuration Q. 1 Is it easy to understand which are the system prerequisites, to check whether they are already installed? Yes/No Q. 2 Is it easy to follow the installation instructions to install the prerequisites that may be missing? 5-point scale Part 2. Installing the System Q. 3 Is it easy to follow the installation instructions to install the system itself? 5-point scale Q. 4 Did you need to contact the system authors to install any part of the system? Yes/No Part 3. Running the System on the CLEF eHealth 2016 datasets Q. 5 Is it easy to follow the instructions in the user manual to use the system to process the challenge dataset(s)? 5-point scale Q.
Description of the Robot Wifibot presents a multi-purpose robot. It is a Wifi-enabled, low cost and running Linux platform. Wifibot is useful for several applications in the fields of education, research, surveillance and entertainment. It is a differential robot with 4 driving wheels. It is characterized by an open and modular architecture controlled by a serial communication link and by Wifi. It integrates a computing board unit running on Linux, Ubuntu. This platform stands by its simplicity and efficiency. The Wifibot is composed by an anodized aluminum frame, an USB motorized camera, 4 infrared sensors, central inertia Vn-100 and a laser sheet Hokuyo UTM -30LX. The robot chassis is controlled using a RS232 port. The Wifi board ensures a wireless connection of the system with the configured access point which is provided freely.
Introducing the programming tool After validation of the localization's part of the Wifibot, we look for piloting it and activating the autonomous navigation. The control has been realized using the programming tool RTMaps Studio running on Linux and based on C++ language. The software is already installed on both Wifibot and the user computer. So, to ensure the communication between them, we developed two projects on each side using appropriate blocks and modules that we call packages to send and receive data. On the robot side, we connect Wifibot. pck package which is responsible of sending and receiving information about the system during its navigation. We can access the left and right speeds as well as the odometric position. The laser telemeter and robot's orientation values are also given by two other packages.
By combining the camera pose information with the dense 3D data obtained from the stereo triangulation, a vicinity map of the user environment is constructed. A safe walking path (obstacle free) is determined, while the warning messages are transmitted through micro-vibration stimulation. However, the system requires a powerful processing unit and is considered invasive. In  [16] , the proposed aerial obstacle detection framework is based on a 3D smartphone that captures the 3D structure of the scene through stereo vision. With the help of magnetometer and accelerometer sensors, the system establishes the walking direction of a VI user by identifying potential dangerous obstacles along the path. The system has been tested with actual blind users and proved to be effective. However, the approach suffers from its sensitivity to any sudden camera movement and changes in the lighting conditions.
Obstacle Recognition Framework The obstacle recognition framework involves an offline learning process that exploits a training image database structured into four major and generic categories of obstacles: vehicles, bicycles, pedestrians and static obstructions. The categories have been selected in order to correspond to most common types of dynamic/static objects encountered during indoor/outdoor navigation. The class of static obstacles is characterized by a high variability of instances such as: pylons, traffic signs, blocking rod; trees, garbage cans, bumps, walls, fences or bushes. Because the main constraint of our framework is to develop a real-time application we have decided to simplify the classification process to a relatively reduced set of categories (four) rather than perform a generic recognition task (i.
Compared with BoW VLAD can achieve very competitive retrieval performances with significantly smaller complexity and memory demands (i. e. , for an image, VLAD requires 16-256 bytes, while BOW hundreds of Kbytes). Similar to BoW, but at a reduced scale, a codebook q : X → C, C = [c 1 , c 2 ,. , c K ] ∈ R d×K is learned offline from the training examples (i. e. , 10,000 images from the learning database) using the k-means clustering algorithm. Here, C denotes the set of centroids, while X is the descriptor space. So, for each image I, N points of interest (I = [x 1 , x 2 ,. , x N ] ∈ R d×N ) are extracted using the pyramidal FAST method and each local BRIEF descriptor is assigned to its nearest word in the vocabulary NN(x). The residual vector v i can be computed by accumulating all differences between the image descriptors and the associated centroid (i.
Support Vector Machine (SVM) Training and Prediction The final step of the image recognition module is given by the SVM training (offline process) and SVM prediction (online process). For the offline process, we have used a dataset composed of 10,000 image patches and their associated global VLAD descriptors. We have adopted a SVM classifier with CH I_Square kernel, which has been proven to present powerful generalization capabilities  [33]. For each considered category (i. e. , vehicle, bicycle, pedestrian and static obstacles) an individual SVM has been trained in order to determine the optimal separation plane between the current class and all other images from the training dataset, while maximizing the margin: f (V) = m ∑ j=1 y j •α j •CHI_Square kernel V, V j + b, (9) where CH I_Square kernel V, V j represents the selected CHI-Square kernel; α j , y j m j=1 is the training set with y j ∈ {-1, +1} and b is the hyperplane free term.
For each category, a single SVM classifier is trained using one-versus all strategy (i. e. , the images from the current class are considered as positive examples while all other images from the training dataset are used as negatives samples. The SVM model creates a partition of the 128 dimensional VLAD feature space into separate categories. In the online phase, for each image patch extracted by the obstacle detection module, a global representation using binary VLAD descriptors is constructed. This representation is applied as input to the trained SVM models. The one-versus-all classification method has been used in order to predict the image patch category. A patch is tested against all trained SVM and the one with the greatest margin and f (V) > 0 is selected as representative. To satisfy the real-time constraint imposed to the application, the entire process has been parallelized on multiple threads.
The number of threads is adaptively adjusted depending on the total number of objects detected in the scene. In addition, in order to deal with the situation when an image patch cannot be confidently assigned to any of the considered classes (i. e. , the output of SVM is negative f (V) < 0) we have introduced an extra category denoted Outlier. The overall performance of the obstacle classification method is influenced by the size and the content of the training image dataset used in the offline learning process. We can expect that a higher number of training examples can lead to a better estimation of the separation hyperplanes. Still, increasing the size of the learning data set is not sufficient. In order to avoid overfitting problems  [33] , a relatively high variability of appearances need to be ensured.
Objective Evaluation The proposed assistive device has been tested mostly in outdoor environments because of the high complexity and diversity of static/dynamic objects. Regarding the computer vision-based obstacle detection module the video camera embedded on the smartphone has been used as an acquisition device. The video stream is acquired at a frame rate higher than 25 images with a resolution of 320 × 240 pixels. A testing database has been developed, including 20 items with the average duration of 10 min. Figure  9  shows some examples of the recorded videos. Even though the video camera is mounted on VI user waist belt, the captured video streams can exhibit various types of motion, sudden changes in the lighting intensity or contain trembled and cluttered images. 1 An object is marked as urgent if its associated distance relative to a VI user is inferior to 2 m, otherwise is considered as normal; 2 An object is considered as approaching the subject if the associated distance between successive frames is decreasing, otherwise is marked as departing the VI person.
Objective Evaluation The proposed assistive device has been tested mostly in outdoor environments because of the high complexity and diversity of static/dynamic objects. Regarding the computer vision-based obstacle detection module the video camera embedded on the smartphone has been used as an acquisition device. The video stream is acquired at a frame rate higher than 25 images with a resolution of 320 × 240 pixels. A testing database has been developed, including 20 items with the average duration of 10 min. Figure  9  shows some examples of the recorded videos. Even though the video camera is mounted on VI user waist belt, the captured video streams can exhibit various types of motion, sudden changes in the lighting intensity or contain trembled and cluttered images. When a ground truth data set is available, the obstacle detection/classification errors can be globally described with the help of two error parameters, denoted by Based on these entities, the object detection/classification performances can be globally evaluated using the precision (P), recall (R) and F-norm (F) parameters, extensively used in the state of the art for evaluation purposes  [34]  and defined as: ( ) = ( ) ( ) + ( ) , ( ) = ( ) / + ( ) , ( ) = 2 • ( ) • ( ) ( ) + ( ) ; (10) The precision P is a measure of fidelity and is inversely related to the first type of errors (false positives).
The difficulty in the evaluation is given by the lack of reproducibility of the outdoor conditions. Even though, for the vision module we can record the video stream and then perform the detection to determine the system performance. In the case of the ultrasonic module such an approach is intractable. So, all the experimental results were obtained by actual VI users walking in real outdoor environments. When a ground truth data set is available, the obstacle detection/classification errors can be globally described with the help of two error parameters, denoted by N MD(MC) and N FD(FC) , and respectively representing the number of missed detected (resp. missed classified) objects and the number of falsely detected (resp. false classified) obstacles. Let us denote by N D(C) the total number of correctly detected (resp.
The recognition system receives as input the image patches extracted using the vision-based object detection module. Table  6  presents the confusion matrix for each of the considered categories. The number of elements in the considered ground truth (GT) is also indicated here. As mentioned in Section 3. 2 we introduced an extra category, called "Outlier". When an image patch cannot be confidently assigned to any of the considered classes, it will be marked as outlier. The proposed strategy makes it possible to assign an image to a category based on its resemblance to the training dataset and not just because it has to belong to a given class. Concerning the acoustic feedback, for all image patches classified as Outliers only a BEEP warning is sent to the VI user. For objects identified only by the sensor module it is impossible to assign semantic information.
In this case, in order to inform user about the presence of a possible dangerous obstruction a BEEP warning is sent into the bone conduction headphones. The experimental evaluation of the recognition module was conducted on a set of 1190 image patches. The classification-related precision, recall and F-score measures are presented in Table  7. The experimental results obtained validate the proposed approach, with a classification F-score superior to 82% for each of the considered categories. The lowest rates are obtained for the bicycle class. This behavior can be explained by the images used in the training phase. As indicated in Section 3. 2, we have used to develop the training dataset images from the PASCAL repository, In the second part, we have focused on the evaluation of the obstacle classification module that allows the semantic interpretation of the detected obstacles.
In this case, in order to inform user about the presence of a possible dangerous obstruction a BEEP warning is sent into the bone conduction headphones. The experimental evaluation of the recognition module was conducted on a set of 1190 image patches. The classification-related precision, recall and F-score measures are presented in Table  7. The experimental results obtained validate the proposed approach, with a classification F-score superior to 82% for each of the considered categories. The lowest rates are obtained for the bicycle class. This behavior can be by the images used in the training phase. As indicated in Section 3. 2, we have used to develop the training dataset images from the PASCAL repository, which includes images of static bicycles without any humans. Because the detection module is based on motion information analysis, for bicycles with people riding them both objects are characterized by the same motion pattern.
Acknowledgments: This work was supported by a grant of the  Romanian National Authority for Scientific Research and Innovation ,  CNCS-UEFISCDI , project number:  PN-II-RU-TE-2014-4-0202. Part of this work has been funded by  University Politehnica of Bucharest , through the  "Excellence Research Grants" Program ,  UPB-GEX. Identifier: UPB-EXCELENT , Ȃ-2016, No. 97/26. 09. 2016. We would like to thank the blind associations involved in the European project  ALICE  (www. alice-project. eu)for helping us conduct the experiential evaluation.
Device drivers are essential components of any operating system (OS). They specify the communication protocol that allows the OS to interact with a device. However, drivers for new devices are usually created for a specific OS version. These drivers often need to be backported to the older versions to allow use of the new device. Backporting is often done manually, and is tedious and error prone. To alleviate this burden on developers, we propose an automatic recommendation system to guide the selection of backporting changes. Our approach analyzes the version history for cues to recommend candidate changes. We have performed an experiment on 100 Linux driver files and have shown that we can give a recommendation containing the correct backport for 68 of the drivers. For these 68 cases, 73.
I. INTRODUCTION The Linux kernel today runs servers, desktop PCs, and laptops, as well as being at the heart of the Android OS, which runs the majority of smartphones, tablets, and a multitude of other devices. Device manufacturers increasingly find it important to have support for their products, in the form of device drivers, in the Linux kernel. The Linux kernel, however, is fast evolving, with frequent kernel-level API changes. This raises a challenge for device driver developers who have to choose a target kernel version that will be acceptable to the potential users of the device. A solution that helps ensure the continuing availability of the driver code is to target the current mainline version of the Linux kernel, so that the driver code can be integrated into the Linux kernel distribution itself and maintained by the mainline kernel developers  [12].
Users, however, typically run older versions of the kernel, which are considered to be more stable. For such users, the driver must then be backported to older kernel versions. Currently backports are typically done manually, on a case by case basis. An alternative is provided by the Linux backports project, which provides a compatibility library to 32nd IEEE International Conference on Software Maintenance and Evolution (ICSME), Raleigh, North Carolina,  October 2-10, 2016. hide differences between the current mainline and a host of older versions, and provides patches that allow a set of 800 drivers to target this compatibility library. These patches are either created manually by the backports project maintainers, or are created using manually written rewrite rules, based on the transformation tool Coccinelle  [27].
In either case, however, the backports project maintainer has to determine where changes are needed in the code to backport and how to carry out these changes. Both of these operations are tedious and error prone. While the Linux backports project provides partial automation, the user is limited to the versions for which backports have been prepared. In this paper, we propose a step towards truly automating these tasks, in the form of a recommendation system for backporting driver files over code changes. Our approach accepts as input a driver file in a given Linux version, the older Linux version to which the driver file needs to be backported (the target version), and the git repository that stores the changes to the Linux source code. It first bisects the repository to find two subsequent commits in the repository such that compiling the driver file results in a compilation error in the older commit version and a successful compilation in the newer commit version.
1) To the best of our knowledge, we are the first to work on recommending changes with the goal of automating backporting. 2) We propose a recommendation system that identifies a change in the code history that breaks the driver, and recommends code change candidates that enable backporting of the driver code. 3) We evaluate our approach on 100 Linux device driver files. The recommendation list contains the correct backported code for 68 of the device driver files. Among these driver files, 85. 3% of the correct recommendations are located in the Top-1 of the recommendation list. The remainder of this paper is structured as follows. We provide some background in Section II. In Section III, we present our proposed approach. We then describe our experiments in Section IV. We present related work in Section V.
A. Git Git is a decentralized version control system that has recently become very popular due to the services that it provides and the tools that have been developed around it. Git is currently used by many software projects, including the Linux kernel. Git is designed around a workflow in which developers pull changes from other developers, modify their copy of the code on top of these changes, and request that other developers pull the changes that they have made. Pulling from another repository creates a merge node, representing the result of merging the two sets of changes. Technically, the commits are organized as a directed acyclic graph (DAG), although they are often collectively referred to as a tree. To be sure to have access to complete information about earlier changes in a software project, we focus on the case where there is a single main developer of the system, with whom other developers want to regularly synchronize.
The development of the mainline Linux kernel follows this model, as developers request that Linus Torvalds pull their changes prior to each release. In this case, we can view the commits and merges made by the main developer as a single primary trunk (level 1), and the commits made by other developers subsequent to pulling from the main developer and prior to requesting a pull from the main developer as being a secondary trunk (level 2), extending from the developer's initial pull to the merge. Such developers may furthermore serve as the main developer with respect to other developers, perhaps their local colleagues, leading to tertiary (level 3), quaternary (level 4), quinary (level 5), senary (level 6) trunks, etc. Figure  1  presents an example git tree illustrating pulls, merges, and primary, secondary, and tertiary trunks.
B. GumTree A critical point of our approach is to be able to precisely identify changes between two commits in a code base. Linebased tools such as GNU diff are not sufficient, because a change can be mixed with irrelevant code fragments that happen to appear on the same line. To address this issue, we use tree differencing, as implemented by the tool GumTree  [4]. GumTree identifies common subtrees in an abstract syntax tree, and then integrates common ancestors as long as there are not too many differences among their other descendants.