dataesr/scientific-paragraphs-categorization huggingface dataset:
BLAST queries of P2CS Users can query P2CS entries by browsing genomes and sequence clusters, by searching gene names/locus tags, and by searching for protein domain combinations. A new feature now allows users to identify homologous of proteins of interest within P2CS by using basic local alignment search tool (BLAST)  (13). Users have full control over BLAST parameters/output if they want to vary default options, and can add hits to their P2CS gene cart. P2CS proteins can also be used as BLAST queries against Uniprot or Genbank. The BLAST option can be found under 'Search' in the top bar of each P2CS page.
Expanded features Additional significant improvements to the existing functionalities have been implemented. Each individual gene page now provides an enriched secondary structure highlighting the protein domains, extended clustering data to include clusters sharing 80% identity, and available gene associated literature through UniProt and Search Tool for the Retrieval of Interacting Genes/Proteins (STRING)  (19, 20)  D540 Nucleic Acids Research, 2015, Vol. 43, Database issue and a link to the PubMed database. Finally, the criteria governing the analysis of genetic organization of TCS genes have been extended to consider in addition to co-oriented genes, neighboring divergent genes localized on opposite DNA strands.
DISCUSSION AND FUTURE DIRECTIONS The P2CS database is a tool for two-component system analysis. It provides a consistent classification of TCS proteins, alongside diverse tools and intuitive navigation for analysis by users. Recent features implemented in P2CS include the provision of phylogenetic trees of TCS proteins, which can provide important evolutionary insights into TCS biology. Figure  2  shows a section of the receiver domain tree for the TCS proteins of Hyphomicrobium sp. MC1. The purple locus tags define a clade of 22 receiver domains from proteins largely belonging to the OmpR family of RR (possessing Trans reg C effector domains (  21 )). Most of the ompR family genes are paired with HK genes as indicated by the colored bars, although four are orphans (HYPMC 0587, HYPMC 0955, HYPMC 4611 and HYPMC 4032).
The remaining proteins are orphans. The dendrograms thus suggest that the two orphans (BCE 1587 and BCE 3620) are likely partners for one another. In fact, such a partnership has already been suggested by the study of de Been et al. (18). We will continue adding new genomes to P2CS as they are made public, and will continue developing new functionalities of P2CS to provide more analysis options for users. Firstly we intend creating a new module, which will allow users to create dendrograms for a user-selected sets of proteins. This should allow the rational engineering/selection of proteins for introduction into a genome, either to act as potential partners for an existing TCS protein or to minimize their cross talk with existing TCS proteins. We also intend to develop a support vector machine for the categorization of TCS proteins, as an alternative to the algorithm based on RPS-BLAST, which P2CS currently uses  (10).
Look up table for the transmittance and albedo of each aerosol component Values of individual transmittances and albedo are precomputed for each of the five aerosol components in SIR-AMix and stored in a LUT. For that purpose, the software libRadtran is used  (Mayer and Kylling, 2005). More details on this radiative transfer code are given in Sect. 3. 1. 1. Transmittances are computed as the ratio of the DSSF considering a gaseous atmosphere and an aerosol layer exclusively made of component i, and the DSSF for the same atmosphere free of aerosols (see Eqs. 4 and 12) T i aer,dir θ 0 , δ 0 , u H 2 O = E i dir θ 0 , δ 0 , u H 2 O E clean,dir θ 0 , u H 2 O , (21) T i aer,dif θ 0 , δ 0 , u H 2 O = E i dif θ 0 , δ 0 , u H 2 O E clean θ 0 , u H 2 O , (22) where the numerator and denominator quantities are computed with libRadtran.
Simulated DSSF: the radiative transfer code libRadtran Highly accurate values of global, direct, and diffuse DSSF are simulated using the software libRadtran  (Mayer and Kylling, 2005)  (http://www. libradtran. org). libRadtran is able to calculate downwelling solar irradiance at any altitude with an accuracy that is comparable to other state-ofthe-art radiative transfer codes  (van Weele et al. , 2000). A broad range of atmospheric and geometric situations can be taken into account by libRadtran. For instance, simulations of irradiance can be run considering an aerosol layer made of one or multiple GADS aerosol components. Furthermore, libRadtran accounts for the hygroscopicity of each aerosol component to modulate simulated irradiances as a function of atmospheric water vapor content.
Description of experiments The objectives of the six experiments conducted in Sect. 4 are detailed as follows. -Experiment 1 in Sect. 4. 1. 1 evaluates the accuracy of the DSSF estimated by SIRAMix against exact DSSF simulations from the radiative transfer code libRadtran. -Experiment 2 in Sect. 4. 1. 2 investigates the sensitivity of SIRAMix regarding the quality of the inputs by quantifying the error of DSSF estimates when inputs are affected by inaccuracies. -Experiment 3 in Sect. 4. 1. 3 shows the benefits of using a varying AOD as input of SIRAMix against the constant aerosol content assumed by the LSA-SAF product. - It is worth stressing here that all DSSF estimates or measurements considered in the experiments below are in units of W m -2 and therefore instantaneous. This also applies to McClear 1-minute averaged estimates, as it can be considered that atmospheric conditions are invariant during 1 min  (Lefèvre et al.
4. 1. 1). Nonetheless, the better estimation of diffuse DSSF by SIRAMix cannot be explained only by the use the LSA-SAF surface albedo, as this would mean that this product is generally more accurate than MODIS's (see Sect. 4. 1. 2). This is something that has not been observed in the literature  (Carrer et al. , 2010b). The different selection of clear sky instants mentioned in the present manuscript and in the article describing the McClear methodology  (Lefèvre et al. , 2013)  explains most of the differences observed between the McClear's scores in both studies. According to experiments, the methodology proposed in this study (see Sect. 2. 4) considers many mildly or highly aerosol-polluted (yet clear) instants of time that may have been ruled out in  (Lefèvre et al. , 2013) , in which a different filtering strategy was used (see  Sect.
Acknowledgements. First of all, the authors feel indebted to  S. Coelho  ( IPMA ) for providing us with the MACC-II data used in this study. Also, we would like to thank the  McClear team  for making their product available. The BSRN team, the  AEMET service , and the  LSA-SAF  colleagues from  KIT  are also acknowledged for providing the ground DSSF measurements used for validation. We thank the libRadtran team for their assistance in using their software and  J. -J. Morcrette  for his help in understanding the AOD data generated in MACC-II. Finally, we would like to thank the two reviewers that revised our work for their sound and useful comments. One of us (X. Ceamanos) was supported by  EUMETSAT  in the framework of the  LSA-SAF  project. Edited by:  R. Engelen.
This definition of persistence is the same as chemotactic index and D/T directionality ratio commonly used to quantify polarized cell migration  [9, 10]. Persistence in this context will illustrate the movement sustainability in one direction  [10]. SkyPad is provided as a user friendly add-in for Excel spreadsheets (https://sites. google. com/site/cadotbruno/ algorithms) and can be used in any Excel spreadsheet containing xy or xyz coordinates from particle tracking of any length. Furthermore, SkyPad is editable, easy access and can be used in a large range of applications among the scientific community, therefore fulfilling the guidelines recently proposed for the use of bioimaging software  [11].
Skypad algorithm SkyPad add-in is a free software: it can be redistributed and/or modified under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or any later version. SkyPad is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. A copy of the GNU General Public License (gpl. txt) should be distributed along with this macro. If not, see ,http://www. gnu. org/licenses/. Distances in the algorithm are calculated as follow: In 2D : d~ffi ffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi (X nzi {X n ) 2 z(Y nzi {Y n ) 2 q In 3D : d~ffi ffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi (X nzi {X n ) 2 z(Y nzi {Y n ) 2 z(Z nzi {Z n ) 2 q Where n is the starting frame and i the number of frames to increment until d reach the distance threshold DT.
This line of research, traditionally known as incremental computation, aims to reduce dynamic problems to static (conventional or batch) problems by developing compilers that automatically generate code for dynamic responses. This is challenging, because the compiler-generated code aims to handle changes asymptotically faster than the source code. Early proposals  (Demers et al. 1981; Pugh and Teitelbaum 1989; Field and Teitelbaum 1990)  were limited to certain classes of applications (e. g. , attribute grammars), allowed limited forms of data changes, and/or yielded suboptimal efficiency. Some of these approaches, however, had the important advantage of being implicit: they required little or no change to the program code to support dynamic change-conventional programs could be compiled to executables that respond automatically to dynamic changes.
These toplevel type annotations simply mark what part of the input data is subject to change. Type inference assigns types to the rest of the program and the translation algorithm translates the program into self-adjusting target code. Observational Equivalence  Figure 1. 1:  Visualizing the translation between the source language Level ML and the target language AFL, and related properties. Theoretical results. Figure  1. 1 illustrates how source programs written in Level ML, a purely functional subset of ML with level types, can be translated to self-adjusting programs in the target language AFL, a language for self-adjusting computation with explicit primitives  (Acar et al. 2006c ). We prove three critical properties of the approach. • Type soundness. On source code of a given type, the translation algorithm produces well-typed self-adjusting code of a corresponding target type (Theorem 6.
We also present experimental evidence that the target programs respond to dynamic changes efficiently. Compiler and runtime design. We have implemented our approach as an extension of Standard ML with the HaMLet and MLton compiler (HaMLet; MLton). The implementation takes SML code annotated with level types at the top-level, conducts type inference that assigns level types to the rest of the programs, and generates self-adjusting code by inserting the self-adjusting primitives via type-directed, local rewrites. Such local rewrites, however, can lead to globally suboptimal code by inserting redundant calls to self-adjusting primitives. We therefore formulate a global rewriting system for eliminating such redundant code, and prove that the rewriting rules are terminating and confluent. We implement the runtime system for self-adjusting primitives directly in SML.
For each of these, we only need to insert some keywords into the program to specify the desired behavior. Specifically, most benchmarks require trivial decorations, often amounting to inserting type qualifiers in one or two lines of code. No changes to the structure of the types, or any part of the code itself, are necessary. Our techniques for controlling the space-time tradeoff for list data structures can reduce memory consumption effectively while only proportionally slowing down updates. The executables generated by the compilers respond automatically and significantly faster (e. g. , several orders of magnitude or more) to both small and aggregate changes while moderately increasing memory usage compared to the familiar batch model of computation.
Now suppose we wish to make x changeable while leaving y stable. We can read x and place x2 into a modifiable (because we can only read within the context of a changeable expression), and immediately read back x2 and finish by writing the sum. 1 quareplus_CS: int mod * int → C int fun squareplus_CS (x, y) = let x2 = mod (read x as x' in write(x' * x')) in read x2 as x2' in let r = x2' + y in write(r) As this example shows, rewriting even a trivial program can require modifications to the code, and different choices about what is or is not changeable lead to different code. Moreover, if we need squareplus SC and squareplus CS-for instance, if we want to pass squareplus to various higher-order functions-we must write, and maintain, both versions. If we conservatively treat all data as modifiable, we would only need to write one version of each function, but this would introduce unacceptably high overhead.
Translation The main purpose of our type system is to support translation. Given a source expression and its type, translation inserts the appropriate mod, read, and write primitives and restructures the code to produce an expression that is well-typed in the target language. The implicitly self-adjusting source language is polymorphic over levels. The type system of the target language, which is explicitly self-adjusting, is also polymorphic but explicitly so: polymorphic values are given as lists of values (within a select construct), with each value in the list being the translation of the source value at specific levels. Moreover, polymorphic values are explicitly instantiated by a syntactic construct in the target language; in the source language, instantiation is implicit. Our translation generates code that is well-typed, has the same input-output behavior as the source program, and is, at worst, a constant factor slower than the source program.
Since the source and target languages differ, proving these properties is nontrivial; in fact, the proofs critically guided our formulation of the type system and translation algorithm. A more detailed example: mapPair. To illustrate how our translation works, consider a function mapPair that takes two integer lists and increments the elements in both lists. This function can be written by applying the standard higher-order map over lists. Figure  2. 1 shows the purely functional code in an ML-like language for an implementation of mapPair, with a datatype α list, an increment function inc, and a polymorphic map function. Type signatures give the types of functions. To obtain a self-adjusting mapPair, we first decide how we wish to allow the input to change. Suppose that we want to allow insertion and deletion of elements in the first list, but we expect the length of the second list to remain constant, with only its elements changing.
We can express this with the versions of the list type with different changeability: datatype α list = nil | cons of α * α list inc : int → int fun inc (x) = x+1 map : (α → β) → α list → β list fun map f l = case l of nil ⇒ nil | cons(h,t) ⇒ cons(f h, map f t) mapPair : (int list * int list) → (int list * int list) fun mapPair (l1,l2) = (map inc l1, map inc l2) • α list C for lists of α with changeable tails; • α list S for lists of α with stable tails. Then a list of integers allowing insertion and deletion has type int S list C , and one with unchanging length has type int C list S. Now we can write the type annotation on mapPair shown in Figure  2. 2. Given only that annotation, type inference can find appropriate types for inc and map and our translation algorithm generates self-adjusting code from these annotations.
Note that to obtain a self-adjusting program, we only had to provide types for the function. We call this language with level types Level ML. Target code for mapPair. Translating the code in Figure  2. 2 produces the self-adjusting target code in Figure  2. 3. Note that inc and map have level-polymorphic types. In map inc l1 we increment stable integers, and in map inc l2 we increment changeable integers, so the type inferred for inc must be generic: ∀δ. int δ → δ int δ. Our translation produces two implementations of inc, one per instantiation (δ=S and δ=C): inc S and inc C (in Figure  2. 3). Since we want to use inc with the higher-order function map, we need to generate a "selector" function that takes an instantiation and picks out the appropriate implementation: inc : ∀δ. int δ → δ int δ val inc = select {δ=S ⇒ inc_S | δ=C ⇒ inc_C} In mapPair itself, we pass a level instantiation to the selector: inc  [δ=S].
Scaling to large and dynamic data Recent advances in the ability to collect, store, and process large amounts of information, often represented in the form of graphs, have led to a plethora of research on "big data". In addition to being large, such datasets are diverse, arising in many domains ranging from scientific applications to social networks, and dynamic, meaning they change gradually over time. Self-adjusting computation provides a natural abstraction for enabling programs to respond efficiently to dynamic data provided that the space usage remains relatively small. In this section, we provide the overview of two techniques for scaling self-adjusting computation to process large and dynamic data: precise dependency tracking and probabilistic chunking scheme. The first technique reduces time and space usage by improving the precision of dependency tracking that self-adjusting computation relies on.
Precise dependency tracking Implicit self-adjusting computation relies on a modal type system to guarantee properties important to the correctness of change propagation-all changeables are initialized and all their dependencies are tracked. This type system can be conservative and can generate self-adjusting programs that contain redundant dependencies. Using a simple list-partitioning function, we outline the limitations of the type system, and describe how we resolve them to improve the time and space usage of self-adjusting computation. List Partition in Level ML. Figure 2. 4  shows SML code for a list-partition function partition f l, which applies f to each element x of l, from left to right, and returns a pair (pos, neg) where pos is the list of elements for which f evaluated to true, and neg is the list of those for which f x evaluated to false.
2. All changeable data should be placed into modifiables and all their dependencies should be tracked. 3. The target language must verify that self-adjusting constructs are used correctly to ensure correctness of change propagation. To address the first challenge, we enrich an information-flow type to check dependencies among different components of the changeable pairs. We introduce labels ρ into the changeable level annotations, denoted as C ρ. The label serves as an identifier for modifiables. For each function of type τ 1 → τ 2 , we give labels for the return type τ 2. The information flow type system then infers the dependencies for each label in the function body. These labels decide which data goes into which modifiable in the translated code. To address the second challenge, the translation algorithm takes the inferred labels from the source program, and conducts a type directed translation to generate selfadjusting programs in destination passing style.
The translation rules are guided only by local information-the structure of types and terms. This locality is key to simplifying the algorithm and the implementation but it often generates code with redundant operations. For example, the translation rules can generate expressions like read x as x ′ in write(l ρ , x ′ ), which is equivalent to x. We can easily apply rewriting rules to get rid of these redundant operations after the translation. Translation correctness. Given a constraint-based source typing derivation and assignment φ for some term e, there are translations from e to (1) a target expression e t and (2) a destination return expression e r , with appropriate target types: Theorem 6. 7. 1. If C; P; Γ ⊢ e : τ, and φ is a satisfying assignment for C, then  (1).
Self-adjusting translation Our translation algorithm extends the algorithm in Section 6. 3 to support full SML, including (recursive) data types and imperative references. The translation algorithm takes SML code and transforms it into SML code containing self-adjusting computation primitives, whose implementations will be supplied by the run-time system. The self-adjusting primitives include mod, read, and write functions for creating, reading from, and writing to modifiable references. At a high level, the translation rules inspect the code locally, insert reads where changeable data is used (according to type information), and ensure that each read takes place within the dynamic scope of a call to mod. To ensure this and other correctness properties, the rules distinguish stable and changeable modes.
Γ ⊢ x : τ ֒→ S x ′ Γ ⊢ (ref x) : (τ ref C ) ֒→ S mod (write(x ′ )) (Ref) Γ ⊢ x 2 : τ ′ ref C ֒→ S x 2 Γ, x 1 : τ ′ ⊢ e : τ ֒→ C e ′ Γ ⊢ let x 1 = !x 2 in e : τ ֒→ C read x 2 as x 1 in e ′ (Deref) Γ ⊢ x 1 : τ ′ ref C ֒→ S x 1 Γ ⊢ x 2 : τ ′ ֒→ S x ′ 2 Γ ⊢ e : τ ֒→ C e ′ Γ ⊢ let = (x 1 := x 2 ) in e : τ ֒→ C impwrite x 1 := x ′ 2 in e ′ (Assign) (2) mod (read e as x ′ in write(x ′ )) -→ e (3) Figure  7. 4: Optimization rules mode ε, source expression e at type τ translates to e ′ ". In stable mode S, the translation produces stable code that cannot inspect changeable data or directly use changeable code; in changeable mode C, the translation produces changeable code that can appear within the body of a read and can manipulate references. For translation of imperative references, we add another primitive impwrite that updates the value of a modifiable directly.
Back end The back end of the compiler is implemented based on MLton. It takes the SML code generated from the front end, conducts various optimizations, and links the code with a selfadjusting run-time library to generate a self-adjusting executable. MLton's whole program compilation strategy makes optimization relatively easy to implement, producing efficient self-adjusting programs. Besides, MLton's support for equality testing, including polymorphic equality and pointer equality, is critical for building the self-adjusting runtime.
Optimization Our translation algorithm follows a system of inductive rules, which are guided only by local information-the structure of types and terms. This locality is key to simplifying the algorithm and the implementation but it often generates code with redundant operations. For example, translating fst x, where x : int $C × τ 2 $S , in changeable mode generates the term read (mod (let r = fst x in write(r))) as x ′ in write(x ′ ), which is redundant: it creates a temporary modifiable for the first projection of x and immediately reads its contents. A more efficient translation, let x ′ = fst x in write(x ′ ), avoids the temporary modifiable. Such redundancies turn out to be common, because of the local nature of the translation algorithm. We therefore developed a post-translation optimization phase to eliminate redundant operations.