dataesr/scientific-paragraphs-categorization huggingface dataset:
THE LUSREGTES TOOL The LusRegTes tool is a test data generator, which consists of two main modules as follows (Figure  3 ).  Module 1: generating test data for the first version;  Module 2: selecting and generating test data for regression testing for the second version. Figure  3. The LusRegTes tool Module 1 of LusRegTes requires the following inputs: the first version of Lustre program to be analyzed, the length of path and the maximum number of loops in a path (that is, the number of times that a pre operator will be repeated in a path). This module automates running the Lesar tool with activation conditions. As a result, it provides a set of test data for testing the first version. Module 1 is detailed in Figure  4. The entire process of Module 2 is shown in Figure  5. The LusRegTes tool is developed in Java programming language, database MySQL and runs on the Linux operating system.
CASE STUDY We have applied the LusRegTes tool to the Heater Controller System, which is presented in Figure  7. The Heater Controller System is a typical example of the reactive system was built by using  When using the LusRegTes tool, the process is realized through two phases. First, module 1 will be run to generate test data for version 1 of the program (Figure  8 ). The test cases in Table  1  are used for regression testing of version 2. This allows testing only the changed parts and new parts in version 2. We can state that:  18,75% of test cases have been removed;  18,75% of test cases have been reused;  62,5% of test cases have been created.
3. 1. Problem statement Lustre/SCADE applications usually require very high quality and rigorous testing activities before deploying. During the development process, the Lustre program is often updated, so regression test should be performed to detect bugs. As for any regression testing activity, optimizing the number of executed test cases is an important issue. Suppose that we have a Lustre program L 1 and L 2 is a new version of program L 1. Comparing to version L 1 , version L 2 may:  Remove some functions;  Add some new functions;  Change some functions; IJECE ISSN: 2088-8708  LusRegTes: A Regression Testing Tool for Lustre Programs (Nguyen Thanh Binh) 2639  Leave functions unchanged.
28, 29 ll such features are available in the PCMSolver module, an application programming interface (API) for the PCM. 30 ] [35] [36]  Crucial aspects of our work are the variational formulation of the PCM equations  37  and the modular approach employed in the implementation. Both PCMSolver and the open-ended response code 10 are two independent modules which can be interfaced to any quantum chemistry software. This approach has several advantages over a non-modular code: modules can be developed and tested separately, new features can be made available to several programs at once, avoiding lengthy, tedious and error-prone multiple implementations, and the master program can be chosen freely, for instance based on the availability of different functionality. The rest of the paper is organized as follows: in Section 2 we present the theory for the quasienergy formalism in the context of the PCM.
10, 11 The implementation we present in this work follows Strategy 2. This avoids excessive modifications to the recursive core of the open-ended response code and allows a straightforward use of efficient response parameter elimination schemes. 47 The resulting computer code exploits interfaces between the Dalton program package,  59  the PCMSolver library,  30  the implementation of the open-ended, recursive approach to atomic orbital-based density matrix response theory  10  and the subsequent development of the latter for the calculation of single residues of response functions. 11 he interface to PCMSolver provides an alternative implementation of PCM capabilities at the SCF level of theory to the one presented by Cammi et al. 60  To test the linear transformations of the generalized Hessian and metric matrices of eqn (  39 ) and (  40 ), a non-recursive PCM-SCF linear response code was implemented exploiting the PCMSolver library.
MPA calculations The calculations were performed in a development version of the Dalton program using the open-ended response code of Ringholm et al. 10  One-electron property integrals and their arbitrary-order derivatives were provided by the Gen1Int library. 67 The XC functionals library XCFun 68 and the integrator library XCint were used for the evaluation of the XC terms and their derivatives. Finally, the PCM functionality was provided by the PCMSolver library. 30 The ESI † contains details about software versions and build toolchain used in this work. Vertical excitation energies were calculated for the 7 lowest excited states of the molecules in Fig. 1. MPA transition moments S were calculated for the same excitations from the residues of the response functions using the implementation described in ref.
Acknowledgements The authors thank  Daniel H. Friese  and  Radovan Bast  ( University of Tromsø-The Arctic University of Norway ) for discussion and technical help. R. D. R. thanks  Filippo Lipparini  ( Johannes Gutenberg Universita ¨t, Mainz ) for discussions on the weak formulation of the PCM and Jogvan  Magnus Haugaard Olsen  ( University of Southern Denmark ) for helping with the implementation and testing of the open-ended response scheme within Dalton. The authors acknowledge support from the  Research Council of Norway  through a  Centre of Excellence Grant  (Grant No. 179568/V30 ), from the  European Research Council  through a  Starting Grant  (Grant No. 279619 ) and from the  Norwegian Supercomputer Program  through a grant for computer time (Grant No. NN4654K ). A. H. S. acknowledges financial support from  Tromsø Forskningsstiftelse  ( SurfInt grant ).
INTRODUCTION Cloud computing has proven to be an advantageous alternative for both businesses and end users, providing previously unimaginable services at affordable or even free subscription plans. Engineers and developers of enterprise information systems can count on various types of cloud services, including Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS)  (Mell and Grance, 2011). In the market landscape of cloud computing, a recent trend is Database as a Service (DBaaS), which moves database storage and management to the cloud  (Hacigumus et al. , 2002; Mahmood, 2014). Applications that reside or not in the cloud can benefit from this model, which inherits advantages of other cloud services, such as availability, scalability and ease of management.
Another recent trend is cloud scripting, a programming solution to automate tasks in the cloud. This little-known alternative allows to build entire information systems by coupling existing cloud services. Google is a representative example of a company offering cloud services to both the general public  (email, calendar, storage, etc. )  and to developers. A useful resource for developers is Google Apps Script (GAS)  (Google Inc. , 2009; Ferreira, 2014) , a cloud scripting solution to automate access to cloud services. This programming tool takes advantage of Google's Platform as a Service (PaaS) layer, enabling to build applications that run on Google's infrastructure and use its libraries, services, and tools. In this model, developers do not need to manage or control any cloud infrastructure: they only deal with developing applications and performing environment settings  (Mell and Grance, 2011).
Among its features, Google Apps Script offers the ability to access relational cloud databases  (Google Inc. , 2017a). These new possibilities of cloud data management and programming bring, along with the benefits, some questions to be investigated. For example, cloud services often associate performance attributes (requisitions per second, maximum execution time, etc. ) with pricing models (free, pay-as-you-go, etc. )  (Li et al. , 2010). Thus, knowing the performance of services becomes important because, by ignoring it, a developer can generate more expenses or even make a cloud execution unfeasible  (Iosup et al. , 2011). In this paper, we investigated the access times for two different third-party cloud databases using Google Apps Script. This can provide subsidies for developers interested in these services.
BACKGROUND 2. 1 Cloud Databases As several cloud database providers exist and this preliminary work has no intention to perform a broad comparison between these services, we decided to concentrate in two relational database services: the Amazon Relational Database Service (RDS), a pioneer service launched by Amazon in 2009, and Morpheus, a recent database service offered by Morpheus Data since 2014. Our primary criteria to choose these services was related to their different launch dates, which could be an indicator of maturity of the service. Both services can be accessed through the JDBC (Java Database Connectivity) service offered by GAS. It is worth noting that Google also offers database services, both relational (Cloud SQL) and NoSQL (Bigtable and Datastore). However, as stated before, our aim was to evaluate the performance of disjoint services and using both cloud scripting and cloud databases from Google would bias the results.
Amazon Web Services -Amazon RDS for MySQL Amazon Web Services is a cloud computing pioneer offering a comprehensive set of global computing, storage, database, analytics, application, and deployments services. As part of this suite, Amazon RDS (Relational Database Service) is a service that facilitates the installation, operation and scheduling of a MySQL, Oracle, Microsoft SQL Server or Post-greSQL database in the cloud. It provides scalable capacity and manages database administration tasks. In its free program, it offers 750 hours of database micro-instances per month.
Morpheus Cloud Database Morpheus is a PaaS that started its services in 2015, offered by the Morpheus Data. Its flagship product is an online database service that allows users to create, deploy and host instances of four different types of database classes through public, private and hybrid clouds. It offers high reliability and availability, with each instance being deployed for free with a full replica, and with automated daily backups. The four database classes are: • MongoDB for non-structured data and documents; • MySQL for traditional RDBMS (Relational Database Management System); • Redis for in-memory data management; • ElasticSearch for distributed search.
Cloud Scripting Languages Cloud scripting is an approach to exploit cloud-based services in a programmatic way. This can be used to perform large scale distributed computations  (Murray and Hand, 2010; Dzik et al. , 2013)  or simply to coordinate multiple services from cloud providers. GAS is a prominent example of cloud scripting solution. It comprises a JavaScript-based programming language that allows you to build web applications and integrate Google Apps and third-party services. These scripts are written to an editor directly from the browser and run on Google's servers. Google Apps Script is a relatively new technology, launched in 2009. It is in constant development, with new features and features being implemented frequently. Table  1  summarizes the services accessible through GAS to the present date.
Environment Setup To start the work, we created free accounts in both services (Amazon RDS and Morpheus). The config- • Morpheus: Storage space of 5 GB and 1 GB of RAM. The connection of the script to the databases is done through the JDBC Service Apps Script. This feature offers 10 different IP address ranges that the platform can use to access the databases. These addresses serve to configure access permissions on the cloud database. The two databases use slightly different forms of configuring access permissions. Morpheus works with an Access Control List (ACL), and Amazon RDS creates the database within a Virtual Private Cloud (VPC), and VPC has a security group, which is responsible for controlling which IP addresses will be released to connect to the database. Both databases use the IP address allocation method called CIDR (Classless Inter-Domain Routing), which stores an IPv4 or IPv6 network specification.
Test Scripts The scripts developed for the tests are based on the SysBench benchmark 1  , a simple performance evaluation tool that allows you to quickly get an impression of the performance of systems. Part of this tool is dedicated to evaluating database performance and is used by authors who have investigated the performance of cloud databases  (Schwartz et al. , 2012). The original SysBench codes are written in the Lua programming language. For the tests in this work, codes have been rewritten using Google Apps Script. All codes have as principle to do basic SQL operations in a database, searching for a random value and then performing the operation. The main goal is to measure the time taken to process a specific amount of database operations. The tests are divided into the following categories of database operations: Inserts, Updates, Selects and Deletes.
The table used in the tests has five numeric/alphanumeric fields (see Table  2 ). Figure  1  present a code excerpt from the GAS test scripts. It performs a database connection, creates a table and executes a set of database insert operations. make within the maximum six-minute time period imposed by Google Apps Script. From this, in order for the two databases to successfully execute within the time limit, three test sets with different amounts of operations were performed for each type of access, in order to obtain the response times perceived by GAS. Times were measured using the Logger. log function, which records the time it started and finished running the script.
RESULTS Table  3  shows the maximum number of operations that each database performed in the six-minute time limit imposed by GAS. It can be seen in Table  3  that Amazon RDS performed a slightly higher number of operations than Morpheus, in the interval of six minutes. Considering the limits expressed in Table  3 , we set the following number of operations for the tests of access times: 100, 1000 and 3500. For each type of operation, we executed the scripts 10 times for each set of operations in each of the databases, then we calculated the mean and the standard deviation for each case. Tables  4, 5 , 6, 7 present the results for each type of operation. Observing the results obtained, it can be said that both databases presented similar performance. Access times were slightly lower for Amazon RDS in all cases, but the standard deviation was lower for Morpheus in some cases.
FINAL REMARKS In this work, we investigated the performance of two cloud databases, through codes written in Google Apps Script and executed in the Google cloud. The codes were adaptations of the SysBench benchmark, which performs basic SQL operations on databases. The results indicated similarity of performance among the cloud databases, although they are instances with non-identical configurations. Note that although a cloud service (GAS) is used to perform the access to databases, response times are feasible for applications that perform few operations. It is also worth mentioning that the instances used in this work are of low processing power, because they are both trials and free. In general, it is noted that the greatest limitation comes from the GAS itself, when establishing that an  execution can not exceed six minutes.
g. , max throughput, single appearance) whereas every case study would have its own objective. It must be possible to reuse the same design flow  [40, 5, 24, 20, 4]  on different case studies with each time an original optimization criteria. There is a lack for a dedicated model of the control which is able to represent all the acceptable schedules of the application according to constraints of different nature ranging from performance requirements to platform allocation (or any other hardware related concerns). In the current paper we show how a wide range of constraints inherited from the architecture could be formally expressed in a language that describes mapping conditions (and scheduling constraints) that will further restrict the potential schedules of the original SDF description. For this we use the Clock Constraint Specification Language ( ccsl) formalism.
ENCODING DATA AND CONTROL FLOW CONSTRAINTS IN CCSL The Clock Constraint Specification Language (ccsl)  [3]  is a declarative language to build specifications of systems by accumulation of constraints that progressively refine what can be expected from the system under consideration. The specification can be used and analyzed with our tool timesquare  [12]. ccsl mainly targets embedded systems and was then designed to capture constraints imposed by the applicative part, the execution platform or also external requirements from the users, like non-functional properties. Constraints from the application and the execution platform are bound together through allocation constraints also expressed in ccsl. The central concept in ccsl are the logical clocks, which have been successfully used for their multiform nature by synchronous languages to build circuits and control-oriented systems, to design avionic systems with data-flow descriptions or design polychronous control systems  [6] ).
The state space is made up with the state of the system in terms of the difference between the history used in each constraint (like for instance in the Precedence definition). From two states of the system, the set of clocks that tick synchronously is then representing the transition. This is the analysis technique used in section 5. Of course constructing the state space can be costly and static analysis techniques for instance based on the clock graph (see  [12] ) could be developed. Another interesting kind of analysis consists in testing if a specific static schedule (a total order of execution and resource access) is acceptable w. r. t. the specification. In this case one must encode his schedule in ccsl, add it to the original specification (like in  [13] ) and run a simulation of the resulting specification in timesquare.
). Then for each fixed choice of a class of constraints a given ad-hoc scheduling algorithm is established as optimal (Rate Monotonic, Earliest Deadline First). Instead, we choose to provide a constraint language powerful as ccsl to express a broad variety of constraints, and to let a general method (reachability analysis and model-checking basically) search for a candidate "best" schedule. This does not avoid the usual NP-completeness syndroma hidden behind many scheduling approaches, but works relatively well in practice due to symbolic representation techniques. Schedulability analysis by exhaustive model-checking has been attempted elsewhere  [2, 41] , but with assumptions quite different from ours in ccsl.
Motivation: Genome-wide datasets produced for association studies have dramatically increased in size over the past few years, with modern datasets commonly including millions of variants measured in dozens of thousands of individuals. This increase in data size is a major challenge severely slowing down genomic analyses. Specialized software for every part of the analysis pipeline have been developed to handle large genomic data. However, combining all these software into a single data analysis pipeline might be technically difficult. Results: Here we present two R packages, bigstatsr and bigsnpr, allowing for management and analysis of large scale genomic data to be performed within a single comprehensive framework. To address large data size, the packages use memory-mapping for accessing data matrices stored on disk instead of in RAM.
To perform data pre-processing and data analysis, the packages integrate most of the tools that are commonly used, either through transparent system calls to existing software, or through updated or improved implementation of existing methods. In particular, the packages implement a fast derivation of Principal Component Analysis, functions to remove SNPs in Linkage Disequilibrium, and algorithms to learn Polygenic Risk Scores on millions of SNPs. We illustrate applications of the two R packages by analysing a case-control genomic dataset for the celiac disease, performing an association study and computing Polygenic Risk Scores. Finally, we demonstrate the scalability of the R packages by analyzing a simulated genome-wide dataset including 500,000 individuals and 1 million markers on a single desktop computer.
Introduction Genome-wide datasets produced for association studies have dramatically increased in size over the past years. A range of software and data formats have been developed to perform essential pre-processing steps and data analysis, often optimizing each of these steps within a dedicated implementation. This diverse and extremely rich software environment has been of tremendous benefit for the genetic community. However, it has two limitations: analysis pipelines are becoming very complex and researchers have limited access to diverse analysis tools due to growing data sizes. Consider first the basic tools necessary to perform a standard genome-wide analysis. Conversions between standard file formats has become a field by itself with several tools such as VCFtools, BCFtools and PLINK, available either independently or incorporated within large framework  (Danecek et al.
2011; Li et al. 2011; Purcell et al. 2007). Similarly, quality control software for genome-wide analysis have been developed such as PLINK and the Bioconductor package GWASTools  (Gogarten et al. 2012). There are also several software for the computation of principal components (PCs) of genotypes, commonly performed to account for population stratification in association studies, including  EIGENSOFT (SmartPCA and FastPCA)  and FlashPCA  (Abraham and Inouye 2014; Abraham et al. 2016; Galinsky et al. 2016; Price et al. 2006). Then, implementation of GWAS analyses also depends on the data format and model analyzed. For example, the software ProbABEL  (Aulchenko et al. 2010)  or SNPTEST  (Marchini and Howie 2010)  can handle dosage data, while PLINK version 1 is limited to best guess genotypes because of its input file format.
Finally, there exists a range of tools for Polygenic Risk Scores (PRSs) such as LDpred  (Vilhjálmsson et al. 2015)  and PRSice  (Euesden et al. 2015) , which provide prediction for quantitative traits or disease risks based on multiple genetic variants. As a result, one has to make extensive bash/perl/R/python scripts to link these software together and convert between multiple file formats, involving many file manipulations and conversions. Overall, this might be a brake on data exploration. Secondly, increasing size of genetic datasets is the source of major computational challenges and many analytical tools would be restricted by the amount of memory (RAM) avail-able on computers. This is particularly a burden for commonly used analysis languages such as R, Python and Perl. Solving the memory issues for these languages would give access to a broad range of tools for data analysis that have been already implemented.
Hopefully, strategies have been developed to avoid loading large datasets in RAM. For storing and accessing matrices, memory-mapping is very attractive because it is seamless and usually much faster to use than direct read or write operations. Storing large matrices on disk and accessing them via memory-mapping has been available for several years in R through "big. matrix" objects implemented in the R package bigmemory  (Kane et al. 2013). We provide a similar format as filebacked "big. matrix" objects that we called "Filebacked Big Matrices (FBMs)". Thanks to this matrix-like format, algorithms in R/C++ can be developed or adapted for large genotype data.