dataesr/scientific-paragraphs-categorization huggingface dataset:
Conclusion This work extends the certified contract management system of  [3]  with template expressions, which allows for drastic performance improvements and reusability in terms of the concept of instruments. Along with changes to the contract language, we developed a formalization of the payo↵ intermediate language in Coq. Our approach introduces the abstract syntax of the payo↵ language as an inductive data type with the semantics of the payo↵ language and the compilation from the contract DSL defined as partial functions (using Coq's Option data type). A number of important properties (including soundness) of the translation from contracts to the payo↵ language have been proven in Coq. Moreover, Coq's code extraction mechanism is used to obtain a certified compiler implementation in the Haskell programming language.
We are currently working on establishing the important property of the new time-parameterized payo↵ evaluation function, which states that given a contract c and its compilation into payo↵ code il , evaluating il at time t gives us the same result (upto discounting) as first advancing c to time t, then compiling it to payo↵ code, and then evaluating the result at time 0. A Secrecy-Preserving Language for Programming of Distributed and Object-Oriented Actor Systems ⇤.
It is therefore possible to build a virtual machine for Creol with a simple and well-protected interface, thereby avoiding some lowlevel security issues. The simplicity of its formal semantics is a good basis for formal analysis, and for extensions of the language with build-in support of security notions. We consider a minimal core language inspired by Creol, and extend it to consider sensitivity of information in the so-called Secrecy Preserving Creol (SeCreol) language. Furthermore, the Creol encapsulation mechanisms allow us to consider a dynamic type system for security levels, integrated in the operational semantics, which can be approximated by the static typing system.
Language Extension: SeCreol SeCreol is a language for programming of concurrent object-oriented systems that maintains security information as well as type information, such that considering the noninterference policy, typable programs are provably secure. Security information in SeCreol are assigned to each object and program element stating who (i. e. , which objects in which security classes) can have direct or indirect read access to them, denoted (r, ir). Therefore, to have a system that preserves secrecy of information, we use a combination of access control and information flow by determining the security class for each object capturing direct access, and tracking security information through computation paths to capture indirect accesses. Moreover, access such as direct and indirect read can be interpreted di↵erent for di↵erent program elements.
Abstract Taint analysis is a form of data flow analysis aiming at secure information flow. For example, unchecked user input is considered typically as "tainted", i. e. , as untrusted and potentially dangerous. Untrusted data may lead to corrupt memory, undermine the correct functioning or privacy concerns of the software otherwise, if it reaches program points it is not supposed to. Many common attack vectors exploit vulnerabilities based on unchecked data and the programmer's negligence of foreseeing all possible user inputs (including malicious ones) and the resulting information flows through the program. We present a static taint analysis for Go, a modern, statically typed programming language. Go in particular features concurrent programming, supporting light-weight threads dubbed "goroutines", and message-based communication.
Motivation The high-level programming language Go is gaining traction, being used in various software products like Docker and Dropbox, as well as for Android and iOS applications  [4]. Support for concurrency based on goroutines and channel communication lies at the very core of Go's design. While standing, at least syntactically and in spirit, in the tradition of C, Go is lightyears ahead compared to the more low-level language C, when it comes to considering "secure" computation. Two notable improvements on that front are Go's advanced static type system and the absence of pointer arithmetic. But still, the concurrency features and the intended distributed and mobile applications and platforms, make the task to ensure secure computation more challenging. In open, interactive and even mobile applications, it is even more vital: One needs to ensure that unchecked, arbitrary user input does not reach sensitive points in the program, potentially leading to memory corruption or other violations, and that private data does not go astray, leaking to the outside or other applications.
NWPT'16 2 Static taint analysis Information flow analysis  [3]  is widely studied and used for many languages, including Java and C, but is currently not implemented for Go. A taint analysis identifies flows of private information to untrusted places, e. g. , a SMS to the attacker, or untrusted information such as user input passed on or processed without sanity checks. We will concentrate on the former type (privacy-based) of taint analysis. The analysis defines private information and untrusted places through a list of sources and sinks. In that it can be seen as a form of a def-use-analysis. Sources are API calls which could read sensitive data, and sinks are API calls which can write data to an untrusted place. Our taint analysis is static and context-sensitive, concentrating on direct information flows.
The Go programming language The small example from Listing 1 illustrates the analysis, highlighting a few Go features. The main function spawns a call to f as a new goroutine (think "thread") using the keyword go, handing over the freshly created synchronous channel via the actual parameter ch. The channel is (obviously) shared between parent and child goroutine, and used to communicate string values from parent to child and, thereby, also synchronizes between them: sending to the channel is done in location n 6 and reading from it in location f 2. The example defines two functions source and sink , whose only purpose here is to illustrate the concepts of sources and sinks for the taint analysis. Go supports pointers (though no pointer arithmetic as in C): In the example, the argument to the sink -function is passed as a reference.
Extensions To make our approach more widely applicable, we present a detailed metamodel that captures a wider range of aspects of the robots (sensors, motors, communication), and allows design of distributed systems. Distribution can be modeled through replication of existing instances on the modeling level, or through composition. Upon deployment, code generated for a robot in the model is mapped to the corresponding physical entity. As the property specification language spans the entire model, this gives naturally rise to partial monitors in each system that contribute to a global property. Annotations structure the evaluation of the sub-formulas into a hierarchy with an explicit mapping to individual instances.
Hence, the family of separating sequences is defined as S s2S {z s }. The test cases used in the first phase of the HSI method are generated by the concatenation of the sequences in Q, and Z and the reset sequence r as follows: S s2S r. q s. z s , where q s and z s , respectively, denote a sequence in Q which is used to reach s and the set of separating sequences for s. In the second phase of the HSI method, the target state and the output of the transitions that are not covered in the first phase while traversing the state cover set are checked. Using DeltaJava  [5] , an SPL is specified in terms of a core module and a set of delta modules. The core module represents the implementation of a valid configuration in the SPL which comprises sets of Java classes and interfaces. A delta module describes a set of changes in the core module which can be addition or removal of the fields, methods and also classes and interfaces in the core module.
To better define the type of changes in the modelling level, we need to consider the e↵ect of applying the DeltaJava delta modules on the test models. To this end, we define a semantic domain for DeltaJava programs based on FSMs. The core model, which is an FSM, describes the behavior of a set of objects instantiated from the classes comprised in the core module. The states in the core model, are symbolic states, which correspond to the aggregation of a set of concrete states where each concrete state represents a valuation of variables. The transitions in the test model correspond to the method calls in the objects. Hence, a method call/return is considered as the input/output of a transition. Each method call manipulates a set of variables in the abstract state which results in moving from the current state to the state that comprises the valuation of the variables after performing the method call.
Its variability is specified in terms of delta modules A, B, and C, which generate software products P 1 and P 2. Within those products, the modules A and B are common to both products, whereas module C is exclusive to product P 2. Syntactic changes, i. e. , program code that is explicitly introduced by module C, can be easily identified using the DOP structure. Semantic changes, i. e. , behaviour that is implicitly modified by the presence of module C, may be di cult to scrutinize though. Consider the parameterised test suites T 1 and T 2 for the respective products P 1 and P 2 , which cover the products' symbolic control-flow graphs. When exploiting the structure of the DOP approach, test suite T 1 covers all paths of the modules A and B within product P 1. Thus, verifying those modules' correctness in product P 2 becomes redundant.
We thank the members of the PC for their work in selecting the talks. We also thank the invited speakers and all the participants (almost 50 of them) for making NWPT '16 a memorable event. October 19th, 2016  Aalborg University ,  Denmark Kim G. Larsen  and  Jiri Srba Acknowledgement. This work was funded by institutional research grant IUT2-1 from the  Estonian Research Council. Acknowledgment. I have started this work together with  Zoltán Ésik  when I visited him in Szeged in February 2016. Unfortunately, Zoltán did not live to see it completed.
A detailed diagram of the contactless indentation device is presented in figure  2a. An air compressor was used to provide an air flow controlled by a pressure regulator. The duration of the air flow output was controlled by solenoid valves. The air passes through a glass pipette with an inner diameter of 1 mm. The distance between the end of the pipette and the sample was fixed at 10 mm. A laser system was used to measure the vertical displacement of the skin during the test with a sampling frequency of 8 kHz, as shown in figure  2b, c. The laser line was composed of 400 sensors over a length of 7 mm. A software application was developed with Labview TM language (National Instruments) to control the system. A turntable was placed on the head of the laser to rotate both the laser and the glass pipette together around the pipette axis.
Statistical analyses MATLAB software was used for statistical data analysis. Analysis of variance (ANOVA) is a statistical model used to analyse the differences between and among groups and to determine if the differences between the means are statistically significant. The data are considered statistically significant if the pvalue is lower than the significance level defined (0. 05 in our case). In our study, we used ANOVA to see whether we had statistically significant differences as a function of age and gender (adhesive force, Young's modulus and SMa). In statistics, the Pearson correlation coefficient (r) is a measure of the linear dependence (correlation) between variables. The Pearson correlation coefficient value was used to determine the strength of the relationship between variables.
RELATED WORKS The Internet of Things (IoT) has been considered the technology that will integrate classical networks and networked objects  (Miorandi, Sicari et al. 2012). Through IoT, it is expected that things can be identified automatically, can communicate with each other, and out of this, we can make better decisions for ourselves. One important question in this regard is how do we convert the data generated or captured by IoT into knowledge that we may be able to use for our convenience? An important work pertinent to this question is that of  (Tsai, Lai et al. 2014). They proposed knowledge discovery in databases (KDD) and data mining technologies to find the information hidden in the data of IoT. Recent researches do focus on developing effective data mining technologies for the IoT.
Multimodal Fusion and Fission To determine the driving event, the context parameters need to be fusioned. Multimodal fusion is the process of combining two or more signals or parameters obtained from two or more sensors (or other sources such as IoT) using two or more modalities. Once fusioned, the driving event is interpreted at the higher-level of abstraction. Machine learning training sets (i. e. supervised learning) are created so that the driving event in consideration can be easily predicted. The fusioned information is searched/matched on the knowledge database to determine if a pattern to the new situation is found. If so, then such situation has a meaning to the system and a corresponding action needs to be implemented. Consider, for example, the fusion of the following data. It represents a typical driving situation.
Methodology We created a driving simulator using Unity 3D software (Engine 2016) to mimic driving scenarios in the laboratory. As one drives, the data from the driving event are sent to the ontology template as a JSON data. These data instantiate various classes and objects in the ontology. The result is an actual driving event. The ontology becomes an actual description of the driving event. The event needs to be classified so it is fed as input to the machine learning classifier. The process yields an identification of a driving event. For now, the driving events are basic ones: stop, turn left, turn right, and normal driving. These are representative samples of all other driving events. Why only a limited driving events? The logic is simple: if this works fine with the representative samples, then it will work fine in all other driving events.
Simulation, Data Analysis and Processing In the simulation experiments, the aim is to detect the driving event. To do so, parameters that describe the context of the vehicle are needed. We collected all data that are near our vehicle (parameters for the context of the environment). We also pre-defined the context of our driver (i. e. we are the driver). These objects need to be identified for the purpose of classification using machine-learning algorithms. We record road objects (e. g. pedestrian, traffic signs, other vehicles) detected by the car. The class "RoadObject" is a template for this purpose. A RoadObject has the following properties: (i) type (e. g. stop, pedestrian, vehicle, etc. ), (ii) speed, (iii) acceleration (iv) distance (i. e. distance of this object from us), (v) position, (vi) lane and (vi) weight.
The RoadObjects are stored in the JSON format. To collect data, multiple test drives were conducted for each common driving event. As it is to be used as training set for machine learning algorithms, we collected 1699 driving state; the repartition of each driving event is shown in Table  1  This is a representative sample of the basic and preliminary driving events conducted in the lab. Machine learning algorithms require formatted data (generally numeric) and a fixed number of columns. For instance, we used one hot encoding for the categorical data, like the position on lane. The last step in data processing is tagging the data. We used the simple tool in Python, the IDE Jupyter Notebook.
K-Fold Cross Validation and Machine Learning Classification Results Validation measures how a predictive model will perform after generalization on an independent data set. After processing and tagging our data, experiments with machine learning algorithms were made using scikit-learn library. We experimented with decision tree and k-nearest-neighbor algorithms. Results are validated using cross-validation with 10 folds, meaning that we have divided the dataset into 10 equal parts, and each time we trained it on 9 parts and tested it on the tenth. The results are an average precision of 95% for decision tree and a precision of 93% for the k-nearest neighbour algorithm. The results indicate good results, although the number of sample is quite low. We intend to test further with other parameters for each algorithm to get better results; we will also collect more data in different situations.
As far as we know, there is not a formalization of the failure detector abstraction in MapReduce-based systems. This is mainly due to the difficulty of modeling a framework for an environment with strictly dynamic requirements. In this paper we study the omission failures in MapReduce systems, formalizing their failure detector abstraction by means of three different algorithms, namely HR-FD (High Relax Failure Detector), MR-FD (Medium Relax Failure Detector) and LR-FD (Low Relax Failure Detector), according to the time heterogeneity, i. e. , how much relaxation the system is capable to tolerate in order to detect an omission failure. The rest of the paper is as follows. In Section 2, we specify the problem we aim to solve. After that, in Section 3 we define the system model in which the different modules (HR-FD, MR-FD and LR-FD) are based on.
Simulation environment and experimental process In the next sections, we describe the different modules of our failure detector abstraction. In order to validate our al gorithms, we have performed a set of experiments that compare them with Hadoop MapReduce. These experiments have been made by means of statistical-based simulations. In order to make this evaluation, we have considered 25 containers, which are able to simultaneously run 25 Map (with an input split of 128 MB) or Reduce tasks. This number of containers is sufficient to evaluate the approach, considering 25 containers per workload. We consider that every Map and Reduce container is the same, and can execute a particular portion (split) of the workload. The application master manages both Map and Reduce tasks. Commonly, the number of mappers is bigger than the number of reducers.
High relax failure detector In this module of the framework, called high relax failure detector (HR-FD), we extend the default functioning of the MapReduce failure detector mechanism. Particularly, since the default timeout of Hadoop MapReduce has a static based timeout mechanism of 10 min, we leave this value as it is, but only for large jobs, that is, those ones whose completion time is above this value. For other jobs, whose completion time is below the value of 10 min, the timeout should be adjusted according to the estimation of the job completion time. In this way, the failure detector timeout will be fair to most of the user requests, regardless of the other parameters. This statement agrees with the state-of-the-art literature  [5, 8, 17, 19, 23, 38] , where it is stated that most large-scale MapReduce clusters run small jobs.
Performance In order to detect a MapReduce straggler through the HR module, the initial timeout adjustment is crucial. As we have stated before, this algorithm should be capable to adjust a job specific timeout, according to the estimated job completion time, and a probable margin of error. This is particularly important for small jobs, whose estimated completion time is under 10 min. For longer lasting jobs, we have decided to leave the default timeout of the Hadoop MapReduce. By this statement, we have placed a higher boundary (that is, 10 min) of the timeout. Knowing that the majority of the production clusters run small jobs  [5, 8, 17, 19, 23] , this timeout is actually addressing the vast majority. We consider that there are also very tiny jobs whose estimated completion time is very small, in terms of seconds.
Medium relax failure detector The previous algorithm (Algorithm 5) deploys a static timeout service. That is, the timeout provided by HR-FD is static, although adjusted at the beginning. Although the algorithm outperforms the default Hadoop mechanism, our aim is to extend the basic HR-FD algorithm by providing a dynamic timeout value. The ideal choice would be to use an estimated progress score of the overall job, which is then divided in its phases and consequently, in individual tasks. A dynamic timeout can rely on the progress score, especially when is predictable in terms of tasks. This is an already built-in feature in MapReduce-based systems  [1, 2, 21] , and other contributions have given even more accurate results in this field  [28, 29, 32]. The main novelty in this module is outlined in the lines of Algorithm 6, where the algorithm calculates the progress score, by adding a margin of error value (λ), that should carry the timeout of the next iteration.
Furthermore, we have also demonstrated the correctness of the three algorithms. As future work, we will instantiate these abstractions for different data-intensive computing systems, in order to enhance the behavior of these frameworks in terms of failure detection and its relation with the default timeout. This is particularly important in the case of production clouds. Indeed, many SLAs are dependent on the timing assumptions of the dataintensive computing systems. Any decision making process made in this scenario should be based on the knowledge of the accuracy boundaries of these systems. This constitutes an important challenge in order to achieve that the data-intensive computing systems constitute a fierce competitor in some fields where relational database systems have been ruling for many decades.
Objectives This article aims to describe an innovative study design for the assessment and investigation during 4 months (following stroke), of minor stroke patients' psychological health (depression, anxiety), coping strategies and quality of life combining classical standard scales and questionnaires with EMA using a smartphone application. Primary objective is a methodological one. We aim to evaluate feasibility, acceptability, quality and reliability of data collected by EMA in minor stroke patients at different times and in different contexts during the first 4 months following a stroke. Secondary objectives focus on studying psychopathological manifestations after stroke and the processes involved in their onset and evolution. Thus, we have several objectives considering these points: (1) to estimate the frequency and assess the evolution of anxiety and depression in minor stroke population, (2) to determine the risk factors and determinants of PSA and PSD in minor stroke patients and to study if coping is a reliable predictor, (3) to describe the clinical and psychosocial characteristics of depressed and anxious individuals after a minor stroke, (4) to describe symptomatic characteristics of PSD and PSA, (5) to study the sequences and dynamic processes between anxiety and depression symptoms, coping strategies and contextual and ecological factors at different times (during the first days, at 2 months and at 4 months) and contexts (hospitalization, discharge, return to work) after stroke.