dataesr/scientific-paragraphs-categorization huggingface dataset:
Below, we thus focused on the cell activation process. The genes in the T2EC dataset related to the cell activation comprise BATF, BCL11A, BPI, CD44, EGFR, LCP1, PIK3CG, PTPRC and SNX27. A subset of the genes above has known roles in erythroid development. Particularly, BCL11A is a TF that regulates  globin gene expression  (Sankaran et al. , 2009). CD44 is expressed in erythrocytes, and participates in the cell adhesion function  (Telen, 2000). Furthermore, EGFR  (Gandrillon et al. , 1999)  and PIK3CG  (Dazy et al. , 2003)  have been previously shown to promote self-renewal state and to inhibit cell differentiation in T2EC. In agreement with the previous observation, the expression of EGFR was downregulated during T2EC differentiation process (see Supplementary Fig. S5 ). The remaining genes however have no reported roles in erythroid differentiation.
The possible involvements of BATF, BPI and LCP1 in T2EC differentiation have also been raised in the original analysis of the dataset (see Supplementary Fig. S8  in  Richard et al. , 2016). A TF enrichment analysis of the cell activation gene set above using Enrichr (ENCODE TF ChIP-seq)  (Chen et al. , 2013)  indicated SPI1, a repressor of erythroid differentiation  (Hoppe et al. , 2016) , as the most significant TF. Interestingly, except for BCL11A and PIK3CG, most of the targets of SPI1 in the gene set, including BPI, CD44, LCP1 and PTPRC, were downregulated (see Supplementary Fig. S5 ). Therefore, excluding the targets of SPI1 and considering only TFs, we arrived with BATF as the most interesting candidate gene regulating T2EC differentiation. BATF is a member of the family of basic leucine zipper transcription factors, and has known function in the development of numerous cell types involved in the immune response  (Murphy et al.
Computational runtimes To assess the computational complexity of our approach, we measured the runtimes of SINCERITIES for 10-and 20-gene in silico datasets, and compared these runtimes to those of TSNI, GENIE3 and JUMP3. Table  4  gives the average runtimes (in seconds) for these methods for the main in silico dataset and for THP-1 differentiation data. Tree-based inference methods (GENIE3 and JUMP3) were significantly slower than SINCERITIES and TSNI. In particular, doubling the network size, the runtimes of GENIE3 and JUMP3 doubled and quadrupled, respectively. Meanwhile, the runtimes of SINCERITIES and TSNI finished almost instantaneously (<1 s) for these datasets, since these algorithms involved solving linear regressions. Finally, we noted that the regularized linear regressions in SINCERITIES are independent of each other and are therefore amenable for parallel computation.
The pseudo-time approach further assumes that the transition between cell states is deterministic, a hypothesis that is still hotly debated  (Moris et al. , 2016). In our experience, the success of cell ordering in reproducing the gene expression trajectory depends sensitively on the cell sampling strategy, that is, being able to sample the right cells at the right time point or stages. For example, the application of Wanderlust to the in silico time-stamped single cell dataset from yeast led to cell ordering that was incongruent with the sampling times, especially for latter time points (see Supplementary Figs  S1  and S2 ). Meanwhile, Kouno et al. showed by using multiple dimension scaling that the THP-1 cell differentiation follows a rather irregular temporal dynamics in the low-dimensional (2D) projected space (see also Supplementary Fig.
S3  for PCA, t-SNE and diffusion map analysis). As in the case of in silico dataset, Wanderlust ordering of THP-1 single cell expression data showed little correlation with the cell time stamps (see Supplementary Fig. S4 ). A similar situation was also reported for the T2EC dataset, where cell ordering using several pseudo-time algorithms led to incongruous outcomes  (Richard et al. , 2016). But, if the pseudo-time of the single cells could be generated, SINCERITIES could still be used with the pseudo-time replacing the time stamp. For this purpose, the cells should be first binned according to their pseudo-times. Subsequently, one can apply SINCERITIES using the pseudo-times of bin centers as the time stamps. Such a strategy is particularly appropriate when the cell differentiation progression is asynchronous.
SINCERITIES could overcome the issues of large dataset requirement, high computational complexity, and difficult cell ordering, as the network inference involves numerically efficient regularized linear regression and directly use time-stamped crosssectional data. SINCERITIES relies on the dynamical changes in the gene expression distributions via DDs to establish a directed GRN graph based on the Granger causality concept. Here, the directed edges imply a predictive causality, where the DDs of the regulators over a given time window have the information for predicting the DDs of the target gene one time window ahead. In comparison to our previous algorithm SNIFS (Sparse Network Inference For Single cell data) that employed Lasso  (Papili Gao et al. , 2016) , SINCERITIES provides predictions for the mode of the gene regulations (i.
e. the sign of the edges), and accommodates unevenly spaced time points-a common characteristic of time-stamped single cell datasets. When the time intervals are short, SINCERITIES formulation may miss gene regulations due to delayed gene responses. However, as the time windows in the single cell analysis typically differ by hours, such an issue may not be prominent. In addition, given enough time points, one could modify the GRN inference to include additional DDs beyond one time window lag. SINCERITIES produces a ranked list of edges based on the values of the coefficients a. Many GRN inference algorithms generate similar outputs, including TSNI, GENIE3 and JUMP3. As mentioned earlier, the magnitude of a coefficients indicates the confidence that a regulatory interaction exists. We allow the end-users to decide the cut-off value for a above which regulatory edges should be included in the GRN.
Conclusion In this work, we developed SINCERITIES for GRN inference using time-stamped cross-sectional single cell expression data, a common type of dataset generated by transcriptional profiling of single cells at multiple time points. SINCERITIES is based on the premise that changes in the gene expression distribution of a transcription factor in a given time window would cause a proportional change in the transcriptional expression distributions of the target genes in the next time window. The network inference involves numerically efficient ridge regression problem. In comparison to network inference algorithms for population average time series data (TSNI and JUMP3) and to a tree-based machine learning algorithm (GENIE3), SINCERITIES could provide significantly more accurate GRNs based on AUROCs and AUPRs.
Formally it is equivalent to expressing GPDs as Radon transforms of DDs  [17]. However there is no known first principle parameterization of GPDs fulfilling all theoretical constraints. For example, positivity and chiral symmetry -connecting a pion GPD to a pion Distribution Amplitude (DA)-usually evade DD parameterization. Therefore computing GPDs in a symmetry-preserving framework is an essential ingredient to satisfy a priori all GPD theoretical requirements as detailed e. g. in Ref. [18]. Here we briefly summarize the theoretical aspects of GPDs, discuss the symmetrypreserving feature of Dyson-Schwinger and Bethe-Salpeter equations, present a generic procedure to extend an overlap of Light Front Wave Functions (LFWFs) from the DGLAP to the ERBL region, and describe how it naturally fits in the software framework PARTONS.
Example The PARTONS framework is written in C++, but a lot of attention has been paid to automation features. It is possible to perform computations with PARTONS without writing a single line of C++ by using computing scenarios: a simple XML file containing the computation configuration (perturbative QCD hypothesis, GPD model, etc. ) and the kinematics of interest can be used to compute any GPD-related quantity, from GPDs themselves to observables. The code below gives an example of the computation of a Compton Form Factor (CFF) at LO. Each line of code corresponds to a physical hypothesis. Work is in progress to invert the Radon transform and build generic GPD models within PARTONS in a similar way. Such GPD models would immediately be ready for phenomenological studies and comparisons to experimental data thanks to the other components of the PARTONS framework.
Acknowledgements This work has been partially supported by  Spanish  ministry projects FPA-2014-53631-C2-2-P,  French GDR 3753 QCD  " Chromodynamique Quantique " and  ANR-12-MONU-0008-01  " PARTONS " and  U. S. Department of Energy, Office of Science, Office of Nuclear Physics , under contract no. DE-AC02-06CH11357.
Preface This volume contains the abstracs of talks that were selected for the presentation at the 28th Nordic Workshop on Programming Theory (NWPT  '16). The workshop was held at Rold StorKro (North Jutland) in Denmark in the period October 31st to November 2nd, 2016. The event was organized by Kim G. Larsen and Jiri Srba with the support of Rikke W. Uhrenholt. There were 32 submissions. Each submission was reviewed by three program committee members and the committee decided to accept 28 abstracts for the presentation. The program also included 4 invited talks by Andrzej Wasowski, Dines Bjørner, Jan Friso Groote and Alan Mycroft with the following abstracts (that appear in the order in which they were presented). • Finding Bugs in Linux Code with Type-And-Effect Abstraction by Andrzej Wasowski, IT University of Copenhagen.
Software projects suffer from conceptually simple resource manipulation bugs, such as accessing a de-allocated memory region, or acquiring a non-reentrant lock twice. The VBDB bug database contains entries for 100 such real bugs from several open source projects, including the Linux Kernel project. These historical bugs have been collected with the aim of giving concrete well understood and documented cases to program analysis researchers, in order to boost program verification research. I will discuss simplicity and complexity of real software manipulation bugs on examples selected from VBDB. One way to reduce the amount of such bugs is to use code scanners such as Smatch or Coccinelle. Unfortunately, while very efficient, code scanners are typically based on syntactic pattern matching, which is insufficient for identifying problems that span multiple functions and involve dynamically allocated memory.
Moreover, they do not ⇤ I would like to thank Lukáš Holík, Roland Meyer, and Tomáš Vojnar for the fruitful collaboration giving rise to the theory presented here. I would also thank Roland Meyer for the valuable comments on this paper. NWPT'  16  1  require any local state but determine their behavior by inspecting the shared heap. Our ambition is to use such summaries in order to enable more e cient static analyses. / Abstract System To overcome the poor scalability of static analyses for systems with an unbounded number of client threads we introduce a novel abstraction. Our abstract system is easier to analyse as it comes with just two concurrently operating threads: a low-level thread which executes the program code under scrutiny and a high-level thread which executes thread summaries like the ones presented above.
Heap, values, and the DOM In the Javascript small-step semantics we have the heap as the "permanent" store, which maps locations to objects and values which are being manipulated by the current expressions  [6]. To extend the semantics to include the DOM, we introduce a structure for the DOM-forest in the semantics. The semantics then defines the DOM API in terms of how this modifies both the DOM-forest as well as the objects directly available to the Javascript code via the heap. In terms of the semantic functions we keep the heap as a map from addresses to objects and introduce a DOM-function that maps IDs to DOM-trees. These IDs can be stored in the heap as a Javascript object. All manipulation of the DOM-structure will go via the API -even for DOM-nodes returned via the API. We are guaranteed that no element is ever deleted from the DOM heap (it may be removed from the main document or modified, but never actually deleted).
Future work The semantics for Javascript DOM allows us to build proofs by hand to express for instance, that a given piece of Javascript code will never cause DOM exceptions. The next big step is to build a static analysis tool that uses the semantics to analyse for potential errors in the DOM API usage. However, Javascript code found in the wild usually uses quite a bit more than just the Core DOM Level 1 API, and a secondary task is therefore to expand the semantics to include more of the DOM APIs. Another interesting approach we are considering is to formalise the semantics in an automated theorem prover, to ease the development of proofs.
Metamodelling refers to the act of defining metamodels which specify the abstract syntax of a modelling language. The abstract syntax defines the set of modelling concepts, their attributes and their relationships, as well as the rules for combining these concepts to specify valid models. For instance, the Ecore metamodel from the Eclipse Modelling Framework (EMF) can be used to define a metamodel for Petri Nets, which in turn can be used create a specific Petri Net model. The creation of models with di↵erent levels of abstraction improves the clarity and reusability of behavioural models. However, mainstream metamodelling approaches like UML and EMF only provide a fixed number of user-accessible levels. This limitation forces users to mix levels of abstraction and create synthetic conformance relations among elements in the same model  [1].
and Rutle, R. and Stolz, V. tools, our plugin reuses the EMF formats for models and metamodels. This way, the user can use any EMF-based tool required for any metamodelling-related task, such as code generation or model transformation. Furthermore, we provide an alternate Sirius-based 1  editor that is more oriented towards the creation of multilevel stacks, so that the user has yet another choice for her editor. MultEcore enhances EMF by allowing deep modelling stacks and multiple linguistic metamodels. From the user perspective, this is realized as a richer palette with the following types, listed in order of appearance in the palette displayed in Fig. 1c. • Ecore types Having the Ecore metamodel with potency 1. * at level M0 makes its types available at any level. • Ontological types As in any modelling tool, the user can instantiate the metamodels.
Duncan Cameron, Gudmund Grov and Léon McGregor Heriot-Watt University, Edinburgh, UK; {dac31,G. Grov,lm356}@hw. ac. uk Motivation Users of modern auto-active program verifiers, such as Dafny  [3] , use the program text to encode: (i) the program specification, (ii) the program implementation, and (iii) the proof guidance used to ensure that the program satisfies the specification. Whilst both the implementation and the specification are desirable, the proof guidance is a necessary evil used only to guide the underlying prover, which for Dafny is the Z3 SMT solver  [2]. The ratio of the number of lines of specification and proof annotations (LoA) to the number of lines of code (LoC) is called the annotation overhead. For non-trivial programs this ratio can be high -e. g. '5  LoA to 1 LoC'. Such a high degree of annotations may obfuscate the program text and act as a hindrance for mainstream uptake of the technique beyond niche markets.
This is applied to programs found in the Dafny library, and integrated with the Dafny Visual Studio IDE. Before going into these details, the types of proof constructs analysed are first outlined. Our approach Dafny is an imperative, object-oriented and functional programming language that has been designed for verification. Properties that have to be satisfied are commonly specified by contracts: given a precondition that a method can assume, it must guarantee that a given postcondition holds. Many annotation and programming constructs are supported to provide guidance to ensure that the contract holds 1. We will focus on the following constructs: Assertions The simplest form of proof guidance is the use of assert statements in the code. An assertion must be verified, but can then afterwards be used by the prover.
Lemma (calls) Dafny supports a ghost state which is only used for verification and will not be compiled. A lemma is a ghost method, i. e. a method that lives in the ghost state. Lemmas can be used for more complex assertions that will require guidance to be proven. A lemma contract specifies the desired property, while the method body is used to encode the proof guidance (using programming and annotation constructs). Variants All Dafny methods and loops must terminate. For simple cases, Dafny can prove this automatically; for more complex cases, the user must provide an expression, called a variant, which for each step has to decrease towards a lower bound.
Construct Calculations Dafny supports Dijkstra style calculational proofs  [4] , where the user can encode each step of a calculation, possibly augmented by hints (e. g. lemma calls). Tool support & results  2  We have developed a tool called DARe (Dead Annotation Removal) that works by traversing the Dafny abstract syntax tree and removing as many annotations as possible. Each time an annotation is removed, Dafny is applied to check if the program still verifies, and the constructs will only be removed if Dafny does not complain  3. For an annotation that could not be removed, DARe will try to break up any conjunctions and remove as many conjuncts as possible  4. Table  1  contains the results from applying DARe to 141 programs available from the Dafny library  5. The second column ('#Progs') shows how many of the programs contained the given type of construct; '#Inst' shows the total number of instances of the construct; '% Removed' shows the percentage of how many constructs could be removed.
Then of the remaining constructs that could not be removed: '#^' shows the remaining conjuncts (after being broken up); and '% ^removed' shows how many of these conjuncts could be removed. Note that for calculations, the table shows the sub-parts/steps of the calculations and not the full calculations themselves (albeit they will be removed if all elements of them are removed). Removing annotation had very little impact on the runtime of the verifier. Dafny has a very modern Visual Studio based IDE  [5] , where the verification process happens in the background and is highlighted in the program text. This is comparable to how compilation errors are shown in systems like Visual Studio. A desirable feature is to integrate DARe with this plug-in and highlight annotations that can be removed. As this is an interactive system, responsiveness and speed are crucial; this can be at odds with guaranteeing the simplest possible program as illustrated by a program with the annotations: a s s e r t A ; a s s e r t B ; a s s e r t C ; Assume that either the first assertion (A) or the second and third (B and C) are required.
A naïve approach will delete assert A; and then be left with assert B; assert C; a complete approach will try all possible combinations and find that keeping assert A will lead to the simplest/shortest program. However, this will be very slow -we have to call Dafny for each step and attempting all possible removal combinations will not be su ciently responsive. As an experiment, we implemented both versions for invariants and assertions, and found only one case where the simplest program gave a di↵erent result from the faster version for all 150 programs. In this case they still had the same number of annotations removed. We therefore used the fastest version, which has linear runtime. While we cannot formally guarantee that the shortest program is found, this experiment has shown that, in practice, it is likely to be.
Conclusion & future work The results have been encouraging and we are particularly surprised by the number of assertions that could be removed. The work is analogous to dead code elimination found in many compiler optimisations, but we are not familiar with any similar work for program verifiers, where the focus tend to be on the discovery of auxiliary annotations. There are several ways to extend our work. We could address further simplification techniques, possibly normalising formulas to CNF form and then split the conjuncts. We could also extend the tool to other constructs. For example, programming constructs for the ghost state can also be removed. Another example is to remove/simplify contracts for (auxiliary) recursive methods which are analogous to loop invariants; in this case a user will need to indicate whether or not a lemma is auxiliary.
Introduction Secure execution of third party code is crucial in mobile applications, web browsers, cloud technologies, etc. It has long been known that static analysis in insufficient for the detection of side-channel attacks (e. g. , cache attacks, power attacks, etc. ). This paper shows that automatic memory management also exposes side-channels that can be used to leak sensitive information in third party code. We present a series of simple attacks on modern runtimes, in particular Java sequential and parallel garbage collections and V8 default garbage that illustrate the potential of the attack. These attacks have also been shown to be effective over a network connection. To address the problem of leaks via garbage collection, we develop a model of a programming language that uses abstract secure runtime and security types to enforce security.
For example, a European call option instrument has template parameters such as maturity (the end date of the contract), strike, and the underlying asset that the option is based on. Compiling such a template once allows the engine to reuse compiled code, giving various parameter values as input to the pricing engine. Moreover, an inherent property of contracts is that they evolve over time. This property is precisely captured by a contract reduction semantics. Each day, a contract becomes a new "smaller" contract, thus, for pricing purposes, contracts need to be recompiled daily, resulting in a dramatic compile time overhead. To avoid recompilation in this case, the generated payo↵ code is parameterized over the current time so that evaluating the payo↵ code at time t gives us the same result (upto discounting) as first advancing the contract to time t, then compiling it to the payo↵ code, and then evaluating the result.
To avoid recompilation of a contract when time moves forward, we define a function cutPayo↵(). This function is defined recursively on the syntax of intermediate language expressions. The only interesting case is the case for payoff expressions: cutPayo↵(payoff(t, p 1 , p 2 )) = if(lt(t, now), 0, payoff(t, p 1 , p 2 )) The function guards the payoff expression with a condition guarding whether this payo↵ should have e↵ect. For the remaining cases, the function recurses on subexpressions and returns otherwise unmodified expressions. Avoiding recompilation can significantly improve performance especially on GPGPU devices. On the other hand, additional conditionals are introduced, which results in a number of additional checks at runtime. Experiments conducted with "hand-compiled" OpenCL code, which 3.