dataesr/scientific-paragraphs-categorization huggingface dataset:
Concrete Semantics The semantics of a logic program is usually given in terms of the SLD relation on goals  (Lloyd 1987). In this section, we present instead a local semantics which is similar to that of  Ströder et al. (2011). Basically, this semantics deals with states that contain all the necessary information to perform the next step (in contrast to the usual semantics, where the SLD tree built so far is also needed, e. g. , for dealing with the cut). In contrast to  (Ströder et al. 2011) , for simplicity, in this paper we only consider definite logic programs. However, the main difference w. r. t. (Ströder et al. 2011 ) comes from the fact that our concrete semantics only considers the computation of the first solution for the initial goal. This is the way most Prolog applications are used and, thus, our semantics should consider this behaviour in order to measure the coverage in a realistic way.
A Tool for Concolic Testing In this section, we present a prototype implementation of the concolic testing scheme. The tool, called contest, is publicly available from the following URL http://kaz. dsic. upv. es/contest. html It consists of approx. 1000 lines of Prolog code and implements the concolic testing algorithm of Definition 5 with function alt as described in Section 4. 2 and a maximum term depth that can be fixed by the user in order to guarantee the termination of the process. Moreover, we also introduced a bound for the number of alternatives when computing function alt trace (see Definition 4). Roughly speaking, when the number of alternatives is too high, we give up aiming at full choice coverage and return sets with only one clause label (which suffice for clause coverage). Table  1  shows a summary of the coverage achieved by the test cases automatically generated using contest.
In this context, our tool will be useful not only for test case generation, but also to detect program errors during concolic testing (e. g. , negated atoms which are not instantiated enough, incorrect calls to arithmetic built-in's, etc). See the online appendix (Appendix A) for more details on extending concolic execution to full Prolog. 5 Related Work and Concluding Remarks  Mera et al. (2009)  present a framework unifying unit testing and run-time verification for the Ciao system  (Hermenegildo et al. 2012). The ECL i PS e constraint programming system  (Schimpf and Shen 2012)  and SICStus Prolog  (Carlsson and Mildner 2012)  both provide tools which run a given goal and compute how often program points in the code were executed. SWI-Prolog  (Wielemaker et al. 2012 ) offers a unit testing tool associated to an optional interactive generation of test cases.
Moreover,  Vidal (2015)  presents no formal results nor an implementation of the concolic execution technique. Summarizing the paper, we have introduced a novel scheme for concolic testing in logic programming. It offers a sound and fully automatic technique for test case generation with a good code coverage. We have stated the particular type of unification problems that should be solved to produce new test cases. We have proposed a correct algorithm for such unification problems. Furthermore, we have developed a publicly available proof-of-concept implementation of the concolic testing scheme, contest, that shows the usefulness of our approach. To the best of our knowledge, this is the first fully automatic testing tool for Prolog that aims at full path coverage (here called choice coverage).
* This work has been partially supported by the  EU (FEDER)  and the  Spanish Ministerio de Economía y Competitividad  under grant  TIN2013-44742-C4-1-R  and by the  Generalitat Valenciana  under grant  PROMETEOII/2015/013. Part of this research was done while the third author was visiting the University of Reunion; G. Vidal gratefully acknowledges their hospitality.
The LELIE project These considerations motivated the development of the LELIE project  (Barcellini et al. , 2012) ,  (Saint-Dizier, 2014) , which is a system that detects several types of errors in technical documents, whatever their authoring and revision stages are. Lelie produces alerts related to these errors on terms, expressions or constructions that need various forms of improvements. By error, we mean the non-observation of an authoring rule in the guidelines that is applicable to the situation, for example the use of passives, modals or negation which must be avoided in instructions. LELIE also allows to specify business constraints such as controls on style and the use of business terms. The errors detected by LELIE are typical errors of technical texts (e. g. Table  1 ), they are not errors in ordinary language.
Pairing LELIE with an error correction memory An error correction memory is a necessary complement to Lelie to produce technical documents with an efficient and contextually accurate controlled natural language level. Indeed, systems such as LELIE, are rule-based. Rules can detect the main situations. Filters can be paired with these rules, however, these cannot be multiplied indefinitely. A hybrid approach that pairs a generic rule-based system with a learning procedure that observes in an accurate manner the technical writer's correction activity to adjust errors seems to be relevant and operational. In this paper, we develop our analysis and the features of an error correction memory. Our approach is based on a two level organization: -the development of relatively generic correction patterns, which correspond to a common correction practice of a number of technical writers.
It is a crucial tool, paired with a rule-based system such as LELIE, for improving the language quality of technical texts following CNL principles, which are felt to be too rigid. This tool is useful since correcting errors in texts is indeed a time consuming, painful and costly task. It should also make corrections more homogeneous over large texts and should avoid to introduce new errors when making corrections. This notion of error correction memory originates from the notion of translation memory, it is however substantially different in its principles and implementation. An in-depth analysis of memory-based language processing is developed in  (Daelemans et al. , 2005)  and implemented in the TiMBL software. These investigations develop several forms of statistical means to produce generalizations in syntax, semantics and morphology.
RUBRIC, a Flexible Tool for Automated Checking of Conformance to Requirement Boilerplates,  (Chetan et al. , 2013)  is dedicated to requirement control. It is based on a kind of grammar that describes the structure of the various boilerplates the users want to use, based on Rupps Boilerplates syntax. The parsing allows the recognition of ill-formed structures. Besides boilerplate recognition, this system has rather simpler controls on CNL constraints (called Natural Language Best Practices Checking) such as absence of negation, no passives, conjunctions, controls on fuzzy and vague terms, etc. which are potentially problematic constructs in requirements. This tool does not propose any correction help. The RAT-RQA system, developed by the Reusecompany for authoring requirements has similar properties.
It is developed for a number of languages and is connected to the IBM Doors requirement management system. Finally, let us mention RABBIT, designed for developing control natural language for authoring ontologies in a form understandable to people, in opposition to e. g. OWL. In this section, the features and the impact of an error correction memory are analyzed w. r. t. the language performance and cognitive activity of technical writers: how this system affects and improves their activity and what could be the real benefits when it is operational and accepted. Then we develop the experiments that lead to the system: the corpus and the memorization of corrections. Finally, we develop more formal aspects concerning the formalism of correction rules, their associated contexts of use, and the way error correction rules are induced from previously made corrections.
Technical writer behavior analysis The first step in the definition of an error correction memory is to observe how technical writers work from a linguistic and cognitive point of view with the alerts produced by LELIE. Alerts are inserted in the original document in various ways, depending on the authoring tool that is used. For example, alerts are displayed as specific comments in MS Word. In Editorial suites such as Scenari, which has been connected to Lelie, alerts appear as text bubbles or paper pads with links to explanations and definitions. Corrections can therefore be made on the original document. In our experimentation, the following questions, crucial for the design of a controlled natural language system, have been considered: -What do technical writers think of the relevance of each alert? -What are the strategies deployed by technical writers to make corrections? -Over large documents, how do they manage to produce stable and homogeneous corrections? -How much of the text fragment where the error occurs is modified? Does the modification affect the sentence content? -How difficult is a correction and what resources are required (e.
Memorizing technical writers' corrections An observation on how technical writers proceed was then carried out from our corpus. The tests we made do not include any temporal or planning consideration (how much time it takes to make a correction, or how they organize the corrections) or any consideration concerning the means and the strategies used by technical writers. At this stage, we simply examine the correction results, which are stored in a database. At the moment, since no specific interface has been designed, the initial and the corrected texts are compared once all the corrections have been made. The only exception are requirements since the Doors requirement management system keeps tracks of all modifications made by authors. The global process for memorizing corrections is the following in the context of fuzzy lexical items and negation: -for a new fuzzy lexical item or negation that originates an alert, create a newentry in the database, include its category and a priori severity level for fuzzy terms.
The severity level has two origins: the a priori severity level given in CNL recommendations, and the opinion of senior technical writers involved in our experiments. This severity level can be updated during the learning process. Severity mainly relies on the ambiguities which are generated or the difficulty to realize the task (e. g. close smoothly: what does this means and how to carry out this action?). -for each alert concerning this item, include the whole sentence in which it appears in its database entry and the correction made by the technical writer. Indicate who made the correction (several writers often work on similar texts). Alerts as well as corrections are tagged. Changes are basically characterized by the use of new words or a different word order. -If the initial sentence has not been corrected then it is memorized and no correction is entered.
Correction rules are based on patterns that identify structures via unification. The first pattern identifies the error while the second one, based on the first proposes a correction: [error pattern] [correction pattern]. These patterns are based on the syntax of Dislog (Discourse in Logic, (Saint-Dizier, 2012)), a logic-based language that runs on the TextCoop platform. Patterns include specific variables that represent contextual recommendations. Besides its logic-based character, Dislog extends the expressive power of regular expression, in particular via (1) the introduction of feature structures which may be typed, (2) negation on symbols which must not occur in the expression, (3) reasoning procedures and calls to knowledge for various controls and computations and (  4 ) the construction of representations or results (e.
The task consists in constructing, from the error correction database, the set Err 1 of the different contextual error corrections where duplicates are eliminated and replaced by a frequency measure. -Step 1b: detecting correction inconsistencies. The next task is to detect in the set Err1 situations where W, Scope and Cont are similar but Corr is different. This means that a given error in the same context gets different corrections. This kind of inconsistency must be resolved by means of different strategies which can be parameterized: (a) a decision is made by an administrator or via mediation, (b) the most frequent correction Corr is kept, or (c) it is possible to generalize over the two corrections when there are minor differences between them. The result is the set Err2 of consistent contextual error corrections.
Overall organization of the system The overall organization of the system is rather simple, it is basically an extension to Lelie connected to the text editor used by the company at stake. The main components of the error correction system include resources and processing modules which are specific to this task. The main resources are: -lexicons of e. g. fuzzy lexical items. These are categorized by means of lexical categories (e. g. adverb, adjective, etc. ), severity level, semantic features (e. g. for adverbs: manner, temporal, for verbs: WerbNet classes)). Additional, domain specific, features can be added to allow more accurate and relevant forms of generalizations. This allows the definition of the types required for the induction step presented in the previous section, -local grammars, e.
g. to identify a construction that is a negation or an adverbial phrase where the head term is fuzzy, -the contextual error corrections database. The main processing components are: -the contextual error correction rule induction mechanism, with its connection to the error database, -the module that interacts with technical writers to propose generalizations in a readable manner, -the modules that connect Lelie (rules and resources) with the induction mechanism. All these modules are written in Prolog SWI, using the kernel syntax so that they can be used in various implementation contexts.
A few typical error correction patterns for fuzzy lexical items Correction patterns have been categorized considering (1) the syntactic category of the fuzzy item and (2) the correction samples collected in the database. Organized by syntactic category, here are a few relevant and illustrative types of patterns which have been induced: -fuzzy determiners: their fuzzy character is not easy to circumvent, a solution is the specification, via a recommendation, of an upper or a lower boundary (X) or an interval, major patterns are: [ a few Noun ] [ less than X Noun ]. , [ most Noun ] [ more than X Noun ]. Besides patterns, which are generic, the context may induce a correction recommendation for the value of X: depending on Noun and its usage (context) a value or a few close values for X can be suggested, e.
For example, convenient may be paraphrased by that has debugging tools. Such paraphrases can be suggested to technical writers from the corrections already observed and stored in the error correction database. At the moment, 27 non-overlapping patterns have been induced from the corpus. Error correction recommendations are more difficult to stabilize because contexts may be very diverse and related to complex business aspects. At the moment, (1) either a precise recommendation has emerged or has been found in non fuzzy text counterparts and has been validated or (2) the system simply keeps track of all the corrections made and displays them by decreasing frequency. In any case, the correction decision is always the responsibility of the technical writer.
Some typical error correction memory scenarios for negation Negation is much more difficult to correct than fuzzy lexical items. On the same corpus, our observations show that only about 50% of the alerts on negation produced by Lelie are judged to be relevant by technical writers, therefore there is about 50% of noise, which is very high. This is however not surprising because technical writers tend to say that an alert is not relevant when they do not know how to correct it without altering too much the text or producing a correction that is worse than the error. Among the 50% which are relevant, about 35% can be easily corrected while the remaining 15% must be corrected but their correction is difficult from a language or knowledge point of view. In contrast with fuzzy terms, negation gets corrections which may be quite different in French and in English.
The main modules of this error correction memory system have been implemented in Prolog and connected to Lelie: the database, the induction algorithm and the automatic production of correction patterns with recommendations. These modules must now be integrated into each company's authoring system to be operational. Companies use a large diversity of editorial environments where the integration of the modules we implemented is possible via some substantial interface work. Systems like Doors (for requirement authoring and management) or Scenari (editorial suite) keep track of all changes including corrections made on texts, these traces can be re-used to construct the error correction database (section 3. 3). The internal representations of most editorial systems are XML structures: it is therefore a priori possible to generate correction patterns and to use the man-machine interfaces of the editorial system at stake to generate readable correction patterns.
The database is realized in Prolog as follows: alert ( [ type of alert ], [ tagged term(s) ], [ lexical category ], [ severity level (1 to 3) ], [ [ sentence with alert, sentence after correction with tags, ID of writer ],. ]). For example: alert ( [ fuzzy ], [ progressively ], [ adverb ], [3], [ [ [ <fuzzy>, progressively, </fuzzy>, heat, the, probe ], [ [ <revised>, heat, the, probe, progressively,  in, 5,seconds, </revised>]], [John] ]. ].
We present numerical simulations of metastable states in heterogeneous neural fields that are connected along heteroclinic orbits. Such trajectories are possible representations of transient neural activity as observed, for example, in the electroencephalogram. Based on previous theoretical findings on learning algorithms for neural fields, we directly construct synaptic weight kernels from Lotka-Volterra neural population dynamics without supervised training approaches. We deliver a MATLAB neural field toolbox validated by two examples of one-and two-dimensional neural fields. We demonstrate trial-to-trial variability and distributed representations in our simulations which might therefore be regarded as a proof-of-concept for more advanced neural field models of metastable dynamics in neurophysiological data.
One important approach to characterize the former, nervous tissue at the mesoscopic scale, are neural fields, i. e. , continuum approximations of infinitely large neural networks  (Coombes et al. , 2014). In a recent theoretical study, beim  Graben and Hutt (2014)  investigated stationary states and heteroclinic dynamics in neural fields with heterogeneous synaptic connectivity. The present work applies this previous study to describe experimentally observed transient neural activity as a proofof-concept of our theoretical approach. We propose a novel hypothesis on the origin of trial-to-trial variability observed in most experimental data, on episodic cell assembly dynamics and on sparsely sampled neural representations. Moreover, we disseminate our software implementation as a MATLAB neural field toolbox to facilitate further research on this intriguing field of computational neuroscience.
Numerical Studies For a numerical implementation of the theoretical results above, we have to discretize time and space. Using MATLAB, temporal discretization on the one hand is achieved through the ordinary differential equation solver ode15s for stiff problems. On the other hand, spatial discretization converts the kernels w 1 and w 2 into tensors of rank two and three, respectively. Consequently, the integrals in Equation (  8 ) become contractions over products of tensors and state vectors u(t). In order to properly deal with tensor algebra, we use the Sandia Tensor Toolbox 2. Our neural field toolbox, thus obtained is available as Supplementary Material. We evaluate our implementation in the next subsections by means of two examples.
Context. Long-baseline interferometry is an important technique to spatially resolve binary or multiple systems in close orbits. By combining several telescopes together and spectrally dispersing the light, it is possible to detect faint components around bright stars in a few hours of observations. Aims. We provide a rigorous and detailed method to search for high-contrast companions around stars, determine the detection level, and estimate the dynamic range from interferometric observations. Methods. We developed the code CANDID (Companion Analysis and Non-Detection in Interferometric Data), a set of Python tools that allows us to search systematically for point-source, high-contrast companions and estimate the detection limit using all interferometric observables, i. e. , the squared visibilities, closure phases and bispectrum amplitudes.
The search procedure is made on a N × N grid of fit, whose minimum needed resolution is estimated a posteriori. It includes a tool to estimate the detection level of the companion in the number of sigmas. The code CANDID also incorporates a robust method to set a 3σ detection limit on the flux ratio, which is based on an analytical injection of a fake companion at each point in the grid. Our injection method also allows us to analytically remove a detected component to 1) search for a second companion; and 2) set an unbiased detection limit. Results. We used CANDID to search for the companions around the binary Cepheids V1334 Cyg, AX Cir, RT Aur, AW Per, SU Cas, and T Vul. First, we showed that our previous discoveries of the components orbiting V1334 Cyg and AX Cir were detected at >25σ and >13σ, respectively.
This kind of method is particularly critical to detect faint companions, as they can be at the sensitivity limit of the instrument or even not be a statistically significant detection (i. e. , <3σ). We therefore created CANDID (Companion Analysis and Non-Detection in Interferometric Data) to address these aspects. This is a suite of Python tools, which contains two main functions: 1) one to perform a systematic search for faint companions (Sect. 2); and 2) one to estimate the detection limit from long-baseline interferometric observations (Sect. 3). This tool is made available to the community 1. CANDID is made for detecting high-contrast, point-source companions orbiting a spatially resolved primary star, although it also works with an unresolved primary and contrast <50%. In this paper, we used CANDID to look for companions in binary Cepheids.
The calibrators, listed in Table  1 , were selected using the SearchCal 2  software  (Bonneau et al. 2006 (Bonneau et al. , 2011) )  provided by the Jean-Marie Mariotti Center 3. We reduced the data using the standard MIRC pipeline  (Monnier et al. 2007) , which consists of computing the squared visibilities and triple products for each baseline and spectral channel, and correcting for photon and readout noise. Squared visibilities are estimated using Fourier transforms, while the triple products are evaluated from the amplitudes and phases between three baselines forming a closed triangle. We used CANDID to search for a component within ±50 mas. For RT Aur, we might have detected a companion at 3. 8σ using only the closure phases, while we only have a 2. 3σ detection using all observables.