dataesr/scientific-paragraphs-categorization huggingface dataset:
Acknowledgements The authors are grateful to Prof. C. Schär for his helpful comments and E. van Meijgaard for making available the RACMO model data. We acknowledge the observational data providers. Calculations for WRF311F were made using the TGCC super computers under the GENCI time allocation GEN6877. The WRF331A from CRP-GL (now LIST) was funded by the Luxembourg National Research Fund (FNR) through grant FNR C09/SR/16 (CLIMPACT). The KNMI-RACMO2 simulations were supported by the Dutch Ministry of Infrastructure and the Environment. The CCLM and REMO simulations were supported by the Federal Ministry of Education and Research (BMBF) and performed under the Konsortial share at the German Climate Computing Centre (DKRZ). The CCLM simulations were furthermore supported by the Swiss National Supercomputing Centre (CSCS) under project ID s78.
5; MgCl 2 2; Na 2 ATP 2; NaGTP 0. 3 (pH 7. 4). All recordings were made at 30 • C in a temperature-controlled recording chamber  (Luigs & Neumann, Ratingen, Germany). Presynaptic APs were generated by injecting brief (10 ms) depolarizing pulses of current at a frequency of 0. 1 Hz. In this condition, the AP had an inherent jitter of less than 3 ms. The voltage and current signals were low-pass filtered (3 kHz), and acquisition of 500 ms sequences was performed at 40 kHz with pClamp (Axon Instruments) version 10. Data were analyzed with a custom-made software written in Labview 10 (National Instruments).
(2011) , by minimizing the following function: f (x, y) = p n-1 i=0 w i (y i -f (x i )) 2 + (1 -p) x n-1 x 0 (f (x)) 2 dx (1) where p is the balance of the smoothing factor (from 0-1, 0 meaning a linear fit and 1 no smoothing at all), w is the weight of the current point (thus determined by the number of images used for the averaging of this point) and f (x) is the second derivative of the cubic spline function. Calcium fluorescence signals were not smoothed. For calcium imaging, to estimate the kinetics of the signal, the obtained signal was fitted with a logistic function by the Levenberg-Marquardt least-squares algorithm: f (x) = A 1 + exp (mu-x) * s (2) where A is the estimated amplitude of the signal, mu its midpoint and s the slope of the curve. All of this was implemented in custom-made software developed in Labview 10, National Instruments.
The problem of TR detection has been the subject of many studies due to the TR important roles. The search of TR in genomes can be done in two contexts: either in the case where a reference sequence exists or in the de novo context (i. e. without a reference sequence). TR detection on reference sequences of genomes, chromosomes or other types of assembled DNA sequences can be performed by a significant number of existing tools (see review  [8]  for examples). Most of these software contain two main steps. At first, potential TR are searched with either an exhaustive  [9, 10]  or a heuristic algorithm  [11]. Some of these search methods are specifically designed for ETR such as BWtrs  [9] , while others can search for both ETR and ATR such as TRF  [11]  and mreps  [10]. A filtering step is then executed for identifying the biologically significant repeats.
This interval is computed based on the coverage depth for the set SR and on the mean frequency of the arcs in c. In the pattern validation step of MixTaR (Step II. in Figure  1 ), we compute the maximum semi-global alignment score between the patterns and the long reads using the overlap alignment method proposed by the library SeqAn  [40]. This method is also used at the end of our algorithm (Step III. in Figure  1 ) for computing the overlap between the patterns and the short reads. To compute the local greedy assemblies, we chose SSAKE  [41]  due to its low running time and simple setup needed to obtain satisfying results  [17]. For our experiments we run the TR sequence search tool called mreps  [10]  in order to identify the TR from the contigs obtained with SSAKE. Mreps is a software tool designed for a fast identification in DNA sequences of both ETR and ATR with primitive patterns.
Even for the optimal value of k we can notice that, for the first chromosome of C. elegans, GAGE was not able to align approximately 30% of corrected long reads bases on the reference sequence [GenBank: GCA_000002985. 3]. The values presented in Figure  3  are obtained for long reads with a coverage depth of 20x. For long reads with a coverage depth of 100x we obtained similar values. This high percentage of unaligned bases is due to the complex structure of the chromosome whose length is approximately 15 Mb. Mreps identifies on it a significant number of TR as will be shown in the following paragraphs. In the case of the Philadelphia strain of L. pneumophila the percentage of aligned bases is significantly higher. Because of a smaller set of repeats and the short length (3. 4 Mb) of the genome [GenBank: GCA_000008485.
1], the correction of the long reads is more accurate. As for the first chromosome of C. elegans, similar results were obtained for long reads with a coverage depth of 20x and 100x. In Figure  3  we present the ones obtained for the set with a coverage depth of 20x. For the 130b strand of L. pneumophila, we corrected a set of real long reads [SRA:ERX620205]. The corrected long reads were then aligned on the draft genome constituted of 159 contigs [GenBank:GCA_000211115. 2]. The low percentage of aligned bases of the corrected long reads on the draft genome is probably caused by the error percentage in the set of real long read which is higher than the announced 16%  [24]. In the following, we present the results obtained with MixTaR on both simulated and real data sets. As mentioned before, our algorithm is set to analyse all the cycles of maximum length lmax from the de Bruijn graph and only a part of the cycles of length between lmax and Λmax.
Simulated data sets For our experiments, we needed a complex organism presenting numerous TR. We chose Caenorhabditis elegans, which is a transparent nematode widely used as a model organism. As presented in  [17] , C. elegans is an organism for which assemblers need high computation time for a low percentage of correctly mapped contigs. This is mainly due to the important number of repeats, such as TR. Its genome was downloaded from GenBank [GenBank:GCA 000002985. 3]. For our experiments, we used the first chromosome of C. elegans. This chromosome, of length of approximately 15 Mb, has a very complex structure and contains more TR than many complete genomes. We run mreps  [10]  to identify the TR from its reference sequence and we obtained a set of 39,006 TR with pattern p satisfying 2 ≤ |p| ≤ 100.
Paired-end short reads datasets with length of 100 bp and a coverage depth of 20x were obtained using the GemSIM read simulator  [43]. To test the impact of the sequencing errors of the short reads on the results quality of MixTaR, the first dataset is errorless (SR-NE, for Short Reads with No Error), while the second one (SR-E, for Short Reads with Errors) simulates Illumina errors. Two other sets of paired-end short reads were obtained by correcting the set SR-E: one (SR-CE1, for Short Reads with Corrected Errors 1) by using the trimming tool proposed by SSAKE  [41]  and the other one (SR-CE2 for Short Reads with Corrected Errors 2) by using the correcting tool proposed by ALLPATHS  [44] , one of the most efficient error correction methods for short reads  [16]. Long reads datasets of coverage depth of 20x and 100x were obtained using the PacBio reads simulator PBSIM  [42]  (LR-E x20 and x100, for Long Reads with Errors).
For our experiments, we used two sets of reads downloaded from the Sequence Read Archive at the NCBI: one set of paired short reads obtained with Illumina sequencing with a coverage depth of approximately 120x [SRA: ERX313832] and a set of long reads obtained with Pac-Bio sequencing [SRA:ERX620205]. In the following, we refer to these two sets of reads with SR-R130b (for Short Reads Real for 130b) and LR-R130b (for Long Reads Real for 130b). A second set of long reads (LR-RC130b, for Long Reads Real Corrected for 130b) was obtained by correcting the set LR-R130b with LoRDEC using the set SR-R130b and k = 19. The draft genome is constituted of 159 contigs [GenBank:GCA 000211115. 2].
Source Code Analysis with Spoon The first goal of Spoon is to enable standard developers to write their own domain-specific analyses on source code. This requires: first, an intuitive metamodel understandable by the mass of Java developers (presented in Section 2. 2), second, mechanisms to analyze source code elements. The latter is embodied by queries (Section 2. 3) and processors for traversing the program under analysis (Section 2. 4). But let us first give an overview of the library before going into the details of the Java metamodel of Spoon. Spoon is a meta-analysis tool, it provides software engineers with the primitives to write their own analyses. As such, Spoon does not any specific analysis such as dataflow analysis.
The Spoon Metamodel of Java A programming language can have different metamodels. An abstract syntax tree (AST) or model, is an instance of a metamodel. Each metamodel -and consequently each AST -is more or less appropriate depending on the task at hand. In this paper, we focus on Java and consequently on Java metamodels. For instance, the Java metamodel of Sun's compiler (javac) has been designed and optimized for compilation to bytecode, while, the main purpose of the Java metamodel of the Eclipse IDE (JDT) is to support different tasks of software development in an integrated manner (code completion, quick fix of compilation errors, debug, etc. ). Unlike a compiler-based AST (e. g. from javac), the Spoon metamodel of Java is designed to be easily understandable by normal Java developers, so that they can write their own program analyses and transformations.
All names are prefixed by "CT" Figure  3  shows the metamodel for Java executable code. Because of the complexity of the Java language, the code metamodel figure contains only an excerpt of all classes. There are two main kinds of code elements. First, the statements (CtStatement) are untyped top-level instructions that can be used directly in a block of code. Second, the expressions (CtExpression) are used inside the statements (for sake of readability, this can not be seen on the figure). For instance, a CtLoop (which is a statement) points to a CtExpression which expresses its boolean condition. Some code elements such as invocations and assignments are both statements and expressions (multiple inheritance links). Concretely, this is translated as an interface CtInvocation inheriting from both interfaces CtStatement and CtExpression.
The generic type of CtExpression is used to add static type-checking when transforming programs. This will be explained in details in Section 3. 2. The reference part of the metamodel expresses the fact that program references elements that are not necessarily reified into the metamodel (they may belong to third party libraries). For instance, an expression node returning a String is bound to a type reference to String and not to the compile-time model of String. java since the source code of String is (usually) not part of the application code under analysis. In other terms, references are used by metamodel elements to reference elements in a weak way. Weak references make it more flexible to construct and modify a program model without having to get strong references on all referred elements.
References are resolved when the model is built, the resolved references are those that point to classes for which the source code is available in the Spoon input path. Since the references are weak, the targets of references do not have to exist before one references them. The price to pay for this low coupling is that to navigate from one code element to another, one has to chain a navigation to the reference and then to the target. For instance, to navigate from a field to the type of the field, one writes field. getType(). getDeclaration().
Listing 1 gives an example of client code. Three filters are used. The first returns all AST nodes of type "Assignment". The second one selects all deprecated classes. The last one is a user-defined filter that only matches public fields across all classes. To guide the user in learning the metamodel, two pieces of information are TypeFilter returns all metamodel elements of a certain type (e. g. all assignment statements) FieldAccessFilter returns all accesses to a given field AnnotationFilter returns all elements annotated with a given annotation type ReturnOrThrowFilter returns all elements that ends the execution flow of a method available. First, the user is given a graphical user interface, that provides a navigable view of the Spoon AST of the program under analysis. A screenshot of this GUI is given in Figure  4.
First Class Intercession Mechanisms For transforming programs, Spoon provides first-class intercession mechanisms at different levels. At the structural level, Spoon enables one to add and remove types in packages, as well as fields and methods in types. At the behavioural level, Spoon enables one to modify any part of the code. For instance, one can add pre-conditions in methods, or add logging in catch blocks in an automated manner. Table  2  provides an overview of the main intercession methods of Spoon. All intercession methods take as parameter one or several AST nodes. However, for adding code only, for sake of pragmatism, Spoon enables one to manipulate code strings encapsulated in a special object: a "code snippet". In order for code snippets to seamlessly integrate with the existing AST-level intercession method, in the metamodel, a code snippet is a subclass of an AST node.
Statically Type-Checked Code Templating for Java We have seen so far two ways of writing code transformations. First, one can use the intercession API to manipulate AST objects. Second, one can generate code snippets using text fragments. Both have the same limitation: there is no way to be sure, before the actual transformation, that the transformed code will be compilable. § Spoon provides developers with a third way of writing code transformations: code templates. Those templates are statically type-checked, in order to ensure statically that the generated code will be correct. Our key idea behind Spoon templates is that they are regular Java code. Hence, the type-checking is that of the Java compiler itself. A Spoon template is a Java class that is type-checked by the Java compiler, then taken as input by the Spoon templating engine to perform a transformation.
Template Definition Listing 6 defines a Spoon template. This template specifies a statement (in method statement) that is a precondition to check that a list is smaller than a certain size. This piece of code will be injected at the beginning of all methods dealing with size-bounded lists. This template has one single template parameter called _col_, typed by TemplateParameter. In this case, the template parameter is meant to be an expression (CtExpression) that returns a Collection (see constructor, line 3). All metamodel classes, incl. CtExpression, implement § interface TemplateParameter. A template parameter has a special method (named S, for Substitution) that is used as a marker to indicate the places where a template parameter substitution should occur. For a CtExpression, method S() returns the return type of the expression.
Annotation Processing with Spoon. Spoon provides developers with a way to specify the analyses and transformations associated with annotations. Annotations are metadata on code that start with @ in Java. For example, let us consider the example of a design-by-contract annotation. The annotation @NotNull, when placed on arguments of a method, will ensure that the argument is not null when the method is executed. Listing 9 shows both the definition of the @NotNull annotation type, and an example of its use. The @NotNull annotation type definition carries two meta-annotations (annotations on annotation definitions) stating which source code elements can be annotated (line 1), and that the annotation is intended for compile-time processing (line 2). The @NotNull annotation is used on the argument of the marry method of the class Person.
Finally, the getConsumedAnnotationTypes() returns the set of processed annotations that are to be consumed by the annotation processor. Consumed annotations are not available in later processing rounds. Similar to standard processors, Spoon provides a default abstract implementation for annotation processors: AbstractAnnotationProcessor. It provides facilities for maintaining the list of consumed and processed annotation types, allowing the developer to concentrate on the implementation of the annotation processing logic. Going back to our @NotNull example, we implement a Spoon annotation processor that processes and consumes @NotNull annotated method parameters, and modifies the source code of the method by inserting an assert statement that checks that the argument is not null. The NotNullProcessor (Listing 10) leverages the default implementation provided by the AbstractAnnotationProcessor and binds the type variables representing the annotation to be processed and the annotated code elements to NotNull and CtParameter respectively.
More complex annotation processing scenarios can be tackled with Spoon. For example, when using the @NotNull annotation, the developer is still responsible for manually inspecting which method parameters to place the annotation on. A common processing pattern is then to use regular Spoon processors to auto-annotate the application's source code. Such a processor, in our running example, can traverse the body of a method, looking for expressions that send messages to a parameter. Each of these expressions has as hypothesis that the parameter's value is not null, and thus should result in the parameter being annotated with @NotNull. With this processing pattern, the programmer can use an annotation processor in two ways: either by explicitly and manually annotating the base program, or by using a processor that analyzes and annotates the program for triggering annotation processors in an automatic and implicit way.
Correctness The core of an AST-based source code analysis tool as Spoon is made of two components: a model of the program and a pretty-printer. For real-world and rich programming languages, it is hard to achieve a model that provably covers all parts of the language. Similarly, it is very difficult to prove that all prettyprinted versions of all valid models would be valid programs that 1) correspond to the original one, and 2) can be compiled and executed. To validate the correctness of those two components, we set up the following experiments: first, we collect a dataset of open-source programs; second, for each subject programs, we build the model from the original source code and we then pretty-print back as source code; third, we compile the pretty-printed source code; fourth, we run the test suite of the pretty-printed program to check whether the program has still the same observable semantics.
This process results in 13 software applications: Bukkit; Commons-codec; Commons-collections; Commons-imaging; Commons-lang; DiskLruCache; Javawriter; Joda time; Jsoup; JUnit; Mimecraft; Scribe Java; Spark. An archive containing the source code of those subjects is available as supplementary material. Table  4  gives the key descriptive statistics for this dataset: the commit id (the digest of the commit in the Git version control system, necessary for future replication), the size in number of statements (a semantic Line-of-Code measure, that we also call LOC in this paper), and the number of tests (as defined by the JUnit test framework: the number of test methods). The smallest programs have less than 1000 LOC and the biggest program has 31k LOC. The total is 166 079 statements. The number of test cases ranges from 14 to 15 067.
Performance We now discuss the performance of Spoon. How long does it take to create a model of a program and to write it back on disk? For each program of Table  4 , we measure the time required to parse the original program, build the model of the program as instance of the Spoon metamodel, and pretty print it to disk. All experiments are done on a MacBook with CPU Intel Core i7 (2GHz ) and 8Gb RAM (1600 MHz DDR3) and a solid state disk with an HFS file system. The version of Spoon is 2. 3. 1 and the version of the Java virtual machine is OpenJDK 7. The results are shown in Table  5. For 5 out of 13 subjects, the time to build a model of a program and write its pretty-printed version is lower than 1 second. For the remainder, it takes up to 6,8 seconds (for Commons-collections) to perform the same task.
Name If we compare those durations with the time required to compile the whole application (using javac), it is clearly less (between one third and one tenth). Consequently, this experiment shows that the compilation is a good upper bound of the price of source code analysis. Note that the Spoon time does not take into account the domain-specific analyses and transformations, it is only the basic cost to pay. According to the many different transformations we have done over the years, the transformation time is negligible compared to the model building and compilation time.
Meta-Object Protocol For Method Calls A meta-object protocol  [21]  enables developers to access the internals of a programming language's semantics. There are different meta-object protocols and different ways for implementing them. For instance, a meta-object protocol can modify the object instantiation or the read and write accesses of object fields. It can be implemented within the runtime environment (such as in Smalltalk) or with code transformation. In this section, we present an implementation of a meta-object protocol for method calls (called meta-call protocol or MCP) implemented as a code transformation with Spoon. A meta-object protocol for method calls enables one to intercept all method calls of a software application  [43]. The interception consists of many pieces of information starting with the receiver object, the method to be called and the parameter values.
Target constraints describe the characteristics of the AST nodes allowed to carry an annotation. For example, the annotation @Type(Customer. class) would restrict an annotation to be placed on classes or fields that extend the Customer type. An in-depth description of the semantics of these constraints can be found in  [32]. AVal has a four layer architecture: At the bottom lies the client code that must be validated. The client code carries domain annotations defined by the domain annotation library. The annotation types defined in the library are themselves annotated by constraining annotations defined by AVal (e. g. , @Requires). On the top layer, the validation of each constraint is implemented by a Spoon annotation processor.
In the presentation of WebService, a domain-specific meta-annotation @HasDefaultConstructor is used. It checks for the presence of a no arguments, public constructor in the annotated class. This is achieved by annotating the annotation type definition for the @HasDe-§ 1 @Requires ( WebMethod. class ) 2 @Type ( void. class ) 3 public @interface OneWay { 4 }; ¥ Listing 16: Methods annotated with OneWay must already be annotated with @WebMethod and must not return a value § faultConstructor with an AVal-defined annotation @Implementation, which makes the link between the AVal annotation and the Spoon processor that validates the rule it defines. The source code for the Spoon processor that checks this constraint is shown in Listing 18. This processor validates annotations that carry the @HasDe-faultConstructor meta-annotation, as specified by its implementation of the Validator <HasDefaultConstructor> annotation.