dataesr/scientific-paragraphs-categorization huggingface dataset:
Metabolomic analysis of EXPEL-extruded fluid One mL of methanol (Wako, Tokyo, Japan) was added to 200 μL of EXPEL-extruded fluid. Sampled were then sonicated and split into two separate vials, each containing 0. 6 mL of initial solution: i) GM (general metabolites) and ii) LM (lipid mediators). Description of further sample processing was outlined elsewhere  [23]. MS data acquisition was performed on UPLC coupled to triple-quadrupole MS (LCMS-8050; Shimadzu, Kyoto, Japan), according to manufacturer instructions for analysing Primary Metabolites version 2. 0 (Cat. : # 225-24865A, Shimadzu) and Lipid Mediators version 2. 0 (Cat. : # 225-24873A, Shimadzu). Peak areas of individual metabolites were normalised against the spiked internal standards and then uploaded in the Multi Experiment Viewer software version 4.
The P value indicates which biologic annotations are significantly associated with the input molecules relative to all functionally characterized mammalian molecules. "Ratio" (differential yellow line and markers) refers to the number of molecules from the dataset that map to the pathway listed divided by the total number of molecules that map to the canonical pathway from within the IPA knowledgebase. (C) Normal tissue gene expression of potential biomarkers candidates discovered from colorectal cancer (left panel) and liver metastases (right panel). mRNA expressions were assessed using BioGPS public database.
ACKNOWLEDGMENTS The authors acknowledge the experimental support of  Dr. Chantal Humblet ,  Mrs. Alice Marquet  ( GIGA-histology platform, ULg ) and  Mrs. Naima Maloujahmoum  ( Metastasis Research Laboratory ) for experimental support. The authors are also thankful to the institutional Biobank ( Dr. Stéphanie Gofflot ) of the  University Hospital Liege  for providing patient material and to the  Mass Spectrometry Facility  ( Dr. Mazzucchelli Gabriel ,  Dr. Smargiasso Nicolas ,  Prof. Edwin De Pauw ) of the  University of Liege  for sample analysis.
This paper describes the design and implementation of a comprehensive OCaml interface to the Sundials library of numeric solvers for ordinary differential equations, differential algebraic equations, and non-linear equations. The interface provides a convenient and memory-safe alternative to using Sundials directly from C and facilitates application development by integrating with higher-level language features, like garbage-collected memory management, algebraic data types, and exceptions. Our benchmark results suggest that the interface overhead is acceptable: the standard examples are rarely twice as slow in OCaml than in C, and often less than 50% slower. The challenges in interfacing with Sundials are to efficiently and safely share data structures between OCaml and C, to support multiple implementations of vector operations, matrices, and linear solvers through a common interface, and to manage calls and error signalling to and from OCaml.
Introduction Sundials  [9]  is a suite of six numeric solvers: CVODE, for ordinary differential equations, CVODES, adding support for quadrature integration and sensitivity analysis, IDA, for differential algebraic equations, IDAS, adding support for quadrature integration and sensitivity analysis, ARKODE, for ordinary differential equations using adaptive-step additive Runge-Kutta methods, and KINSOL, for non-linear equations. The six solvers share data structures and operations for vectors, matrices, and linear solver routines. They are implemented in the C language. In this article we describe the design and implementation of a comprehensive OCaml  [13]  interface to the Sundials library, which we call Sundials/ML. The authors of Sundials, Hindmarsh et al. [10] , describe "a general movement away from Fortran and toward C in scientific computing" and note both the utility of C's pointers, structures, and dynamic memory management for writing such software, and also the availability, efficiency, and relative ease of interfacing to it from Fortran.
We exploit this possibility in our library; for example, algebraic data types are used to structure solver configuration as opposed to multiple interdependent function calls, polymorphic typing ensures consistent creation and use of sessions and linear solvers, and phantom types are applied to enforce restrictions on vector and matrix use. On the other hand, all such interfaces add additional code and thus runtime overhead and the possibility of bugs-we discuss these issues in section 4. The basic techniques for interfacing OCaml and C are well understood  [13,  Chapter 20]  [15] [5, Chapter 12][14, Chapters 19-21], and it only takes one or two weeks to make a working interface to one of the solvers using the basic array-based vector data structure. But not all interfaces are created equal! It takes much longer to treat the full range of features available in the Sundials suite, like the two solvers with quadrature integration and sensitivity analysis, the different linear solver modules and their associated matrix representations, and the diverse vector data structures.
In particular, it was not initially clear how to provide all of these features in an integrated way with minimal code duplication and good support from the OCaml type system. Section 3 presents our solution to this problem. The intricacies of the Sundials library called for an especially careful design, particularly in the memory layout of a central vector data structure which took several iterations to perfect. The key challenges are to limit copying by modifying data in place, to interact correctly with the garbage collector to avoid memory leaks and data corruption, and to exploit the type and module systems to express documented constraints and provide a convenient interface. Our interface employs higher-order functions and currying, but such functional programming techniques are incidental; ultimately, we cannot escape the imperative nature of the underlying library.
Solver sessions Using any of the Sundials solvers involves the same basic pattern: (i) a session object is created; (ii) several inter-dependent functions are called to initialize the session; (iii) "set * " functions are called to give parameter values; (iv) a "solve" or "step" function is called repeatedly to approximate a solution; (v) "get * " functions are called to retrieve results; (vi) the session and related data structures are freed. The sequence in figure 1, extracted from an example distributed with Sundials, is typical of steps i to iii. Line 1 creates a session with the (CVODE) solver, that is, an abstract type implemented as a pointer to a structure containing solver parameters and state that is passed to and manipulated by all subsequent calls. This function call, and all the others, are followed by statements that check return codes.
Users may provide their own custom linear solvers by specifying subsets of the 13 operations, or even their own alternate linear solvers by directly setting the four pointers. Sundials includes three main linear solver families: a diagonal approximation of system Jacobians using difference quotients, Direct Linear Solvers (DLS) that perform LU factorization on Jacobian matrices, and Scaled Preconditioned Iterative Linear Solvers (SPILS) based on Krylov methods. The DLS modules require callback routines to calculate an explicit representation of the Jacobian matrix of a system. The SPILS modules require callback routines to multiply vectors by an (implicit) Jacobian matrix and to precondition. As was the case for solver sessions, the initialization and use of linear solvers is subject to various rules.
The OCaml program extract in figure  2  is functionally equivalent to the C code of figure  1. But rather than specifying Newton iteration by passing a constant (CV_NEWTON) and later calling linear solver routines (like CVSpilsSetLinearSolver), a solver session is configured by passing a value that contains all the necessary parameters. This makes it impossible to specify Newton iteration without also properly configuring a linear solver. The given value is translated by the interface into the correct sequence of calls to Sundials. The interface checks the return code of each function call and raises an exception if necessary. In the extract, the ~setup and ~jac_times_vec markers denote labelled arguments [13, §4. 1]; we use them for optional arguments, as in this example, and also to clarify the meaning of multiple arguments of the same type.
Cvode. Spils. set_eps_lin cvode_mem e In choosing between the two possibilities, we strove for a balance between enforcing correct library use and providing a simple and natural interface. For instance, bundling the choice of Newton iteration with that of a linear solver and its preconditioner exploits the type system both to clarify how the library works and to avoid runtime errors. Calls like that to set_eps_lin, on the other hand, are better made separately since the default values usually suffice and since it may make sense to change such settings between calls to the solver. The example code treats a session with CVODE, but the IDA and KINSOL interfaces are similar. The CVODES and IDAS solvers function differently. One of the guiding principles behind the C versions of these solvers is that their extra features be accessible simply by adding extra calls to existing programs and linking with a different library.
Providing optional settings in separate functions divides the interface into smaller pieces. Unlike the features handled by init, the only ordering constraint imposed on these functions is that they be called after session initialization. The simulation is advanced by repeatedly calling Cvode. solve_normal. We define a first function to advance the simulation time t to a given value tnext. When a zero-crossing is signalled, it updates the array element for θ , reinitializes the solver, and re-executes. The simulation is started by calling this function. showloop 0. 0 Despite tail-recursive calls in stepto and showloop, this program is undeniably imperative: callbacks update arrays in place, mutable memory is shared between arrays and nvectors, and sessions are progressively updated. This is a consequence of the structure of the underlying library and works well in an ML language like OCaml.
t. When there are no longer any references to an Nvector. t, it is collected and its finalizer frees the N_Vector and associated global root. This permits the payload to be collected when no other references to it exist. We found that this choice works well in practice provided the standard vector operations are also defined for payload values-that is, directly on values of type 'data-since callbacks can no longer use the nvector operations directly. The only drawback we experienced was in implementing custom linear solvers. Such linear solvers take nvector arguments, which thus become payload values within OCaml, but they also work with callbacks into Sundials that take nvector arguments. The OCaml code must thus 'rewrap' payload values in order to use the callbacks. The "backlink" field is configured when an N_Vector is created by a function in the OCaml Nvector module.
Sessions OCaml session values must track an underlying C session pointer and also maintain references to callback closures and some other bookkeeping details. We exploit the user data feature of Sundials to implement callbacks. The main technical challenges are to avoid inter-heap loops and to smoothly accommodate sensitivity analysis features. The solution we implemented is sketched in figure  5   The type variables are instantiated from the nvector passed to the init function that creates session values. The type variables ensure a coherent use of nvectors, which is essential in operations that involve multiple nvectors, like nvlinearsum, since the code associated with one of the arguments is executed on the data of all of the arguments. The cvode field of the session record contains a pointer to the associated Sundials session value *cvode_mem.
Generic linear solvers A generic linear solver essentially tries to find a vector x to satisfy an equation Ax = b, where A is a matrix and b is a vector. Sundials provides a single type for generic linear solvers that encompasses instances from two families, DLS and SPILS. The two families, however, are essentially implemented using different operations and attached to sessions by different functions with different supplementary arguments, for instance, CVODE provides CVDlsSetLinearSolver and CVSpilsSetLinearSolver. We thus found it more natural to define two distinct types, each with their own associated module. Instances of the DLS family manipulate explicit representations of the matrix A and the vectors b and x. The type for a generic DLS is exposed as (slightly abusing syntax): type ('m, 'data, 'kind, 'tag) LinearSolver.
Values of this type are provided by solver-specific submodules whose particularities we now summarize. For our purposes, the important thing is not what the different modules do, but rather how the constraints on their use are expressed in Sundials/ML. Diagonal linear solvers. The CVODE diagonal linear solver is interfaced by the submodule: module Diag : sig val solver : ('data, 'kind) session_linear_solver val get_work_space : ('data, 'kind) session -> int * int val get_num_rhs_evals : ('data, 'kind) session -> int end A Cvode. Diag. solver value is passed to Cvode. init or Cvode. reinit where it is invoked and makes calls to the Sundials CVodeSetIterType and CVDiag functions that set up the diagonal linear solver. The get_ * functions retrieve statistics specific to the diagonal linear solver-here the memory used by the diagonal solver in terms of real and integer values, or the number of times that the right-hand side callback has been invoked.
One response to the question "Should I use OCaml to solve my numeric problem?" is to rephrase it in terms of the cost of calculating results ("How long must I wait?") against the cost of producing and maintaining programs ("How much effort will it take to write, debug, and later modify a program?"). This section provides insight into the former cost. The latter cost is difficult to quantify, but it is arguably easier to write and debug OCaml code thanks to automatic memory management, strong static type checking, bounds checking on arrays, and higher-order functions. This combined with the other features of OCaml-like algebraic data types, pattern matching, and polymorphism-make the Sundials/ML library especially compelling for programs that combine numeric calculation and symbolic manipulation.
Conclusion We present a comprehensive OCaml interface to the Sundials suite of numeric solvers. We outline the main features of the underlying library, demonstrate its use via our interface, describe the implementation in detail, and summarize extensive benchmarking. Sundials is an inherently imperative library. Data structures like vectors and matrices are reused to minimize memory allocation and deallocation, and modified in place to minimize copying. It works well in an ML-style language where it is possible to mix features of imperative programming-like sequencing, loops, mutable data structures, and exceptions-with those of functional programminglike higher-order functions, closures, and algebraic data types. An interesting question that we did not treat is how to build efficient numerical solvers in a more functional style.
It turns out that the abstract data types used to structure the Sundials library are also very useful for implementing a high-level interface. By overriding elements of these data structures, namely the clone and destroy operations, we are able to smoothly integrate them with OCaml's automatic memory management. Designers of other C libraries that intend to support high-level languages might also consider this approach. For Sundials, some minor improvements are possible-for instance, adding (i) a user data field to nvectors and matrices that could be exploited for 'backlinks', (ii) a function to return the address of the session user data field so that it can be registered directly with the garbage collector, and (iii) a mechanism for overriding the reallocation mechanism within banded and sparse matrices to eliminate the need to reimplement certain operations,-but the approach works well overall.
In our interface, C-side structures are mirrored by OCaml structures that combine low-level pointers, their associated finalize functions, and high-level values. This is a standard approach that we adapted for two particular requirements, namely, to give direct access to low-level arrays and to treat callbacks efficiently. The first requirement is addressed by combining features of the OCaml big array library with the ability to override the Sundials clone and destroy operations. The second requirement necessitates a means to obtain the OCaml "mirror" of a given instance of a C data structure. The backlink fields solve this problem well provided care is taken to avoid inter-heap cycles. Besides the usual approach of using weak references, we demonstrate an alternative for when the mirrored structures are "wrappers".
We found phantom types combined with polymorphic variants are a very effective way to express constraints on the use and combination of data structures that arise from the underlying library. While Generalized Abstract Data Types (GADTs) are used in our implementation, they are not exposed through the interface, probably because in this library we prefer opaque types to variant types since they permit a better division into submodules. The evaluation results show that the programming convenience provided by OCaml and our library has a measurable runtime cost. The overall results, however, are not as bad as may perhaps be feared. We conjecture that, in most cases, the time gained in programming, debugging, and maintenance will outweigh the cumulative time lost to interface overhead. Since programs that build on Sundials typically express sophisticated numerical models, ensuring their readability through high-level features and good style is an important consideration.
Here, we further extend the model of pairwise influence between predefined communities, called Running Influence (RI) which allows obtaining information about influenced entities, and select the influenced community subset and finally evaluates the impact that communities have on each other. We propose an additional metric for evaluating impact communities have on each other within citation networks, Reference Ratio, as an addition to the Time-Dependent Citation Ratio. We also show extensive experiments using real-world dataset, which enable us to compare proposed metrics and study the impact of communities. The remainder of the article is structured as follows. Section 2 describes state-of-the-art dealing with influence, communities and citation networks. Section 3 introduces preliminary notions needed and specifies our research problem in detail.
The arrow in CR A→B indicates the direction of the citation influence. Moreover, contrary to previous works  [25] , which ignore the size of the considered possible reference group, we propose to distinguish two interpretations of Citation Ratio metric, namely local and global one. While a detailed discussion on the two types can be found in our previous work  [8] , we will only limit ourselves to recall the two definitions. Definition 1 Global Citation Ratio is the ratio given by Formula  (1) , where in the denominator we consider all possible communities from available data (set S is equal to universe U ). The result of this metric, assuming that we have a wide range of conferences in the dataset, captures the ratio between citations from a particular conference to all conferences in a global and unbiased way.
Data Description In order to verify the proposed method, we have performed experiments in the real-world dataset consisting of the research papers: Microsoft Academic (MA) database  [30]. The dataset contains 126 909 021 scientific publication entries and 528 682 289 citations between them  [31] , including the venue (conference) indication. This data was the base for creating the citation networks snapshots for each year, containing the number of citations from and to conferences. The summary of the dataset can be seen in Table  1. We limited all conferences and journals available in the dataset to a subset, as the subject of our experiments. In order to measure influence, we intended to choose a subset of already known and recognized conferences and journals. To achieve that, we have chosen the top-conferences/journals from Aminer list  [32]  using two groups: "Artificial Intelligence and Pattern Recognition" (AI) and "Databases and Data Mining" (DM).
The Aminer rank uses H5-Index  [24]. The final filtered list used in the experiments consists of 45 of Data Mining conferences and 77 Artificial Intelligence/Pattern Recognition conferences  3. The experiments involving DM and AI conferences were performed independently from each other. The implementation and experiments were done using PostgreSQL 4  version 9. 6 and R language 5  version 3. 3. 1 with the use of lmtest package 6  for Granger causality tests.
Experiments The conducted experiments, based on the described dataset, consisted of determining and estimating the influence between conference groups using the time span between 1950 and 2015. Each Running Influence was calculated with respect to Definition 3. As it was previously mentioned, we took into consideration the values of the RI of each pair of conferences in order to calculate the final value of RI. The value of RI was calculated using Algorithm 3. The examination of the model in terms of time, we have used three different priority functions: constant, linear and square root, shown in Figure  3. The choice of these functions was due to the fact that they emphasize different time-related aspects. A constant priority function emphasizes equally information in each time snapshot. On the other hand, both linear and square root functions perform annealing of historical data.
b-lactamases are enzymes which are commonly produced by bacteria and which degrade the b-lactam ring of b-lactam antibiotics, namely penicillins, cephalosporins, carbapenems, and monobactams, and inactivate these antibiotics. We performed a rational and comprehensive investigation of b-lactamases in different biological databases. In this study, we constructed hidden Markov model profiles as well as the ancestral sequence of four classes of b-lactamases (A, B, C, and D), which were used to identify potential b-lactamases from environmental metagenomic (1206), human microbiome metagenomic (6417), human microbiome reference genome (1310), and NCBI's nonredundant databases (44101). Our analysis revealed the existence of putative b-lactamases in the metagenomic databases, which appeared to be similar to the four different molecular classes (A-D).
2012; Rabausch et al. 2013). However, in the context of b-lactamase enzymes, environmental, and human metagenomic databases have not yet been adequately explored. To date, little is known about the environmental reservoirs of antibiotic resistance genes and even less is known about the potential sources of b-lactamases. Identifying the source of resistant genes and tracking their evolutionary history will promote efforts to combat antibiotic resistance among human pathogens. With this in mind, the current study was conducted to identify novel b-lactamases parsed in different biological databases. We then addressed the question of the existence of b-lactamases in metagenomic databases, followed by the analysis of their phylogenetic diversity. To identify new putative b-lactamases, we performed large-scale metagenome mining with the help of reconstructed putative ancestral sequences and hidden Markov model (HMM)-based profiles of extant enzymes.