dataesr/scientific-paragraphs-categorization huggingface dataset:
One limitation of our work is that all of our metatheoretic results are specific to HeapLang, and would have to be reproduced, following the same pattern, if one wished to instantiate Iris $ȯ for another programming language. It would be desirable to make our statements and proofs generic. In future work, we would also like to better understand what can be proved about the time complexity of concurrent programs that involve waiting. Can the time spent waiting be bounded? What specification can one give to a lock, or a thunk that is protected by a lock? A fairness hypothesis about the scheduler seems to be required, but it is not clear yet how to state and exploit such a hypothesis. Hoffmann, Marmar and Shao  [9]  have carried out pioneering work in this area, but have dealt only with lock-free data structures and only with situations where the number of competing threads is fixed.
2 ms of processing per data point. By contrast, the most ecient of the proposed SCHEDA heuristics has an average processing time per point of only 2. 7 µs. In  [26] , a generic framework is proposed for realtime anomaly detection, addressing scalability and accuracy issues, but with little focus on the algorithms themselves. Once trained, recurrent neural networks such as long short-term memory networks can operate in real time  [27] , though the training phase has to be performed oine. Statistical approaches based on autoregressive moving average (ARMA and its derivatives, ARIMA, SARIMA. ) work completely online but require careful 2 https://github. com/etsy/skyline parameter tuning and do not take into account seasonality (i. e. what we refer to as periodicity)  [28, 29]. Typically, such methods are designed to work with a very low sampling rate (e.
Use case: Cloud and network monitoring In the world of IT infrastructure, monitoring can have dierent meanings for dierent communities. In particular, monitoring has spawned research communities in the elds of Cloud and network monitoring, with very dierent goals and methods. Still, many common points are to be found between these two very dierent contexts. In  [8] , the authors acknowledge the importance of monitoring and the fact that, despite this very importance, the area is still under-researched. They dene monitoring as a 3-step process: • Collection: data is rst polled from devices using standard tools: SNMP 3  or standard system utilities (top to monitor processes, df to monitor storage, uptime to detect reboots. ) • Analysis: from simplest to most complex: Graphing: the collected data is inserted into a database, so that a history may be retrieved and viewed for debugging and post-mortem analysis.
Data used The data used to benchmark our algorithm is extracted from a supervision system deployed in a datacentre. It consists of 31 time series representing the CPU load, memory usage, number of concurrent sessions and other indicators measured on networking devices, some of which containing anomalies while others only reect normal behaviour. Each series runs over 1 to 2 months, with a sampling rate of one point per minute. This dataset has been partially labeled: each series is hand-annotated with regions that either contain anomalies (and where detections are expected) or are strictly normal (and detections are errors). A region is simply a starting point and an end point. An anomalous region may cover multiple individual anomalies and some normal behaviour, and parts of the series may not be covered by any region.
Computational footprint The total CPU and memory usage are recorded using the standard UNIX time command. In particular, the cumulated CPU time and peak resident memory are recorded for the process of: • Opening and reading the time series The CPU time is divided by the number of points in the series to yield a processing time per point. From these two metrics, we can determine how many time series can be analyzed on a single server before it runs out of memory or becomes unable to process new data points as fast as they are collected.
Discussion In this section, we review the results of our experiments in the light of the requirements expressed in Section 2: • Low computational footprint: Interestingly, the real limitation to the number of time series that can be processed is the available memory, and not the available CPU power. This can be mitigated by either using smaller oat representations, compressing the data in memory or retrieving the relevant points from a time series database on disk. However, even without such optimizations, the SCHEDA heuristics, and especially SES, are scalable enough to be a valuable add-on to any monitoring system. The computational cost of SES is over 60,000 times lower than that of the euclidean anomaly score, yet its performance is superior when it comes to anomaly detection. • Real-time: All three heuristics are real-time by design, as they process data points without buering.
In the present work they are addressed by periodical checks of the response of the sensor boxes in laboratory conditions, and are not reported here. An Arduino board acquires the signals from the chemical sensors. A Raspberry Pi 3 manages the time synchronization and the real-time transfer of the data to a server with Ethernet or wireless technologies (WiFi, LoRa, Zigbee, Bluetooth), every 30 seconds. The Arduino and Raspberry programs have been developed within the laboratories members of the Apolline project. The server-side infrastructure of APOLLINE is a cloud software systems, named APISENSE® (https://apisense. io), that builds on a time-series database (TSDB) and a visualization dashboard. This solution delivers long-term storage capabilities with the ability to include new types of measurements according to the evolutions of the nodes.
More specifically, we build on the InfluxDB open source software, which offers a robust database to store all our measurements on a single virtual machine. The real-time visualization of these metrics is implemented as customizable dashboards on Grafana (figure  2 ). Beyond storage and visualization, this software architecture also supports the automated analysis of measurements, which are implemented in Python and can be run online from a Jupyter environment. We also consider the implementation of a 3D virtual representation of indoor environments, which are enriched with visual gauges reflecting current concentrations of monitored chemicals (figure  3 ).
A sensor box is permanently installed in the electronics laboratory, for ongoing development. Another sensor box is placed on the roof of one of the buildings of the University, collocated with many reference instruments dedicated to study atmospheric pollution, and in particular the particle concentration and composition. This sensor box therefore provides the characterization of outdoor air, necessary when studying indoor air quality. The diversity of environments where the sensors have been deployed has allowed us to test the robustness and limitations of the communication protocols. Unexpectedly, the major difficulties encountered in the deployment were not related to the sensor boxes themselves or to the Apolline infrastructure, but to the high security level of the Ethernet network inside the Lilliad Learning Center, which prevented us at first to upload the data onto the server database, as well as the low reliability of the eduroam WiFi network, with frequent interruptions of the connection.
Conclusions -possible applications and future developments Thanks to a close collaboration between several laboratories within the University of Lille, the Apolline network for the study of indoor air quality is fully operational. Sensor boxes have been assembled and validated for the quantification of gaseous and particulate air pollutants. The signals from the sensors are uploaded in real time to a server for offsite visualization and analysis. The sensors have been deployed in various buildings of the University. Their potential for the characterization of the indoor air quality, as well as for problems related to the management of the buildings, such as the determination of the occupancy, has been demonstrated. The future steps will consist in technical improvements to the present system, most particularly the automatization of the analysis procedure, and on the other hand in the deployment of the sensor boxes on a wider scale so as to construct a database of indoor air quality in various environments.
Acknowledgments The authors thankfully acknowledge the support from the  University of Lille , the  Institut de Recherches Pluridisciplinaires en Sciences de l'Environnement (IRePSE Fed 4129) , and the  IRCICA USR-3380 CNRS/University of Lille. This work is a contribution to the  CaPPA project (Chemical and Physical Properties of the Atmosphere) , funded by the  French National Research Agency (ANR)  through the  PIA (Programme d'Investissement d'Avenir)  under contract  ANR-11-LABX-005-01 , and a contribution to the CPER research project CLIMIBIO, with financial support from the  French Ministère de l'Enseignement Supérieur et de la Recherche , the  Hauts de France Region  and the  European Funds for Regional Economical Development. The authors thank the administrative and technical staff of the  Lilliad Learning Center of the University of Lille  for their involvement and support during the deployment phase of the project.
1  This tactic encodes the proof goal into the SMT-LIB language  [4]  and calls the SMT solver Z3  [14]. If Z3 is successful in finding a proof of the input problem, the generated proof is reconstructed inside Isabelle. The proof format, and hence the reconstruction process, is specific to Z3. If the reconstruction is successful, the initial proof goal holds in the Isabelle/HOL logic. The reconstruction, however, might fail due to errors (either due to a weakness in the reconstruction or due to errors to the solver) or timing out. We have previously developed  [2, 3]  a prototype to reconstruct proofs generated by the SMT solver veriT  [9]. In this paper we have extended these works with proper support of term sharing, tested it on a much larger scale, and present the reconstruction method in more detail.
Furthermore, we reworked the syntax of the proof output to adhere stronger to the SMT-LIB standard. Given the variety of capabilities between ATPs, a greater diversity in supported systems increases the number of proof goals which can be solved by automated tools. Moreover, the fine-grained proofs produced by veriT might allow for a higher success rate in reconstruction. Lastly, the reconstruction efforts provide valuable insights for the design of proof formats. Similar to the proofs generated by Z3, veriT's proofs are based on the SMT-LIB language, but are otherwise different. Proofs are a list of indexed steps which can reference steps appearing before them in the list. Steps without references are tautologies and assumptions. The last step is always the deduction of the empty clause. Furthermore, steps can be marked as subproofs, which are used for local assumptions and to reason about bound variables.
The Proofs Generated by veriT veriT is a CDCL(T )-based satisfiability modulo theories solver. It uses the SMT-LIB language as input and output language and also utilizes the many-sorted classical first-order logic defined by this language. If requested by the user, veriT outputs a proof if it can deduce that the input problem is unsatisfiable. In proof production mode, veriT supports the theory of uninterpreted functions, the theory of linear integer and real arithmetic, and quantifiers. We assume the reader is familiar with many-sorted classical first-order logic. To simplify the notation we will omit the sort of terms, except when absolutely needed. The available sorts depend on the selected SMT-LIB theory and can also be extended by the user, but a distinguished Bool sort is always available.
Sharing and Skolem Terms The proof output generated by veriT is generally large. One reason for this is that veriT can store terms internally much more efficiently. By utilizing a perfect sharing data structure, every term is stored in memory precisely once. When printing the proof this compact storage is unfolded. The user of veriT can optionally activate sharing  4  to print common subterms only once. This is realized using the standard naming mechanism of SMT-LIB. In the language of SMT-LIB it is possible to annotate every term t with a name n by writing (! t :named n ) where n is a symbol. After a term is annotated with a name, the name can be used in place of the term. This is a purely syntactical replacement. To limit the number of names introduced we use a simple approach: before printing the proof we iterate over all terms of the proof and recursively descend into the terms.
Generating calls with Sledgehammer Hammers, like Sledgehammer, select facts from the background theory, translate them to the input language of the provers, and then attempt to use the generated proof if a proof is found within a given timeout. The proof can be used in different ways. One approach is to gather the facts required to find a proof with one of the builtin tactics of the proof assistant. Another approach is to replay the proof within the core by an smt-like method or to translate it into the user-facing language of the assistant. Sledgehammer supports all of these approaches. By default, Sledgehammer uses the following strategy: first, it tries several Isabelle tactics, including detailed proof reconstruction by the Z3-powered smt tactic, with a timeout of 1 s. If this is successful, it returns the tactic that was the fastest to prove the goal in Isabelle.
This tactic can be inserted in the theory. If none of them is fast enough to find a proof, reconstruction of a proof in the user-facing language is attempted. We have changed Sledgehammer to additionally test the veriT-powered smt tactic. Sledgehammer tries to find a proof and to minimize the involved facts. Even when Z3 finds the proof, reconstruction with veriT can be faster. We tested this approach on two formalizations: an ordered resolution prover  [15, 16]  and the SSA language  [10, 19]. We tested all theories included in the formalization. We selected the first development because we knew that Sledgehammer was useful during the development. We selected the second formalization because it is a very different theme. Due to time constraints, we did not test more theories. The results are given in Table  2.
Related Work Reconstruction of proofs generated by external theorem provers has been implemented in various systems including CVC in HOL Light  [13] , Z3 in HOL4 and Isabelle/HOL  [8] , and SMTCoq reconstructs veriT  [1]  and CVC4  [12]   The reconstruction of Z3 proofs in HOL4 and Isabelle/HOL is one of the most advanced and well tested. It has been used to check proofs generated on problems from the SMT competition. Sadly, the code to read the SMT-LIB input problems was never included in the standard Isabelle distribution and is now lost. Proof reconstruction has been heavily tested and succeeds in more than 90% of the cases according to Sledgehammer benchmark [7, Section 9], and is very efficient. The SMT solver CVC4 follows a different philosophy from veriT and Z3: it produces proofs in a logical framework with side conditions  [18].
Conclusion and Future Work We presented the syntax and semantics of the proofs generated by veriT and the reconstruction of those proofs in Isabelle. During the development, the format was extended to ease reconstruction by printing more information like the instantiations. We hope to integrate our code in the next Isabelle release. Overall, having more details in the proofs helps to make the reconstruction more robust, because each step is simpler to check. For example, veriT detailed information on Skolemization, makes it easier to replay than the one from Z3: the reconstruction can call the ordered resolution prover metis. For now, the implicit simplifications prevents us from reconstructing proof more efficiently than Z3. Another challenge is to translate the proof to the more readable Isar format.
Acknowledgments. We thank  Alex Brick ,  Daniel El Ouraoui , and  Pascal Fontaine  for suggesting many textual improvements. The work has received funding from the  European Research Council (ERC)  under the European Union's  Horizon 2020 research and innovation program  (grant agreement No. 713999 , Matryoshka). Previous experiments were carried out using the Grid'5000 testbed (https: //www. grid5000. fr/),supported by a scientific interest group hosted by Inria and including CNRS, RENATER, and several universities as well as other organizations.
Introduction An ever increasing number of astronomical transients are discovered yearly in data from observatories around the world. Communicating information about these new detections quickly and efficiently is essential to facilitating multi-wavelength and multi-messenger transient science. Many transient discoveries are now transmitted publicly over the Virtual Observatory (VO) network through the use of xml messages called VOEvents  1. VOEvents offer several advantages in facilitating transient science: they are machine readable, can be generated by an open-source suite of software tools  2  , contain only the essential observables related to a detection, and are sub-divided into several elements that describe things like event time, sky location, and physical properties. The VO network and the VOEvent framework are developed and maintained by the International Virtual Observatory Alliance (IVOA).
A number of tools and libraries have been developed using the IVOA standard to interface with the network and facilitate use by the community such as the Comet broker system 3   [1]  and the 4 Pi Sky transient research project  4   [2]. These systems are currently used by many transient facilities, such as the Neil Gehrels Swift satellite which communicates new gamma ray burst (GRB) detections via VOEvent which can be subsequently followed up at other facilities  [3]. While VOEvents have been put to good use in the transient community, the focus of this workshop was to discuss possible improvements to the framework. In particular, this workshop focused on the topics of standardizing VOEvent messages, making VOEvents compatible with the FAIR data principles, facilitating easier querying of past events, and adding new fields to VOEvents to make them more useful for new types of transients.
FAIR Data principles The FAIR Data principles have been developed to better facilitate reuse of scientific data and focus on four key principles to which data should adhere  [6]. Specifically data should be Findable, Accessible, Interoperable, and Reusable. In this workshop we examined whether VOEvents currently meet these criteria and how they could be improved to better adhere to FAIR principles. The criterion on which VOEvents perform best is their interoperability. VOEvents already have standardized metadata and structure that adheres to a single system. VOEvents also perform fairly well in terms of accessibility; the What element in a VOEvent can contain a wealth of information on an event and the VOEvent metadata is understandable to humans and machines. However, there are some issues related to accessibility as well.
For example, the Why element of a VOEvent contains an importance value related to the judged validity of probability of the transient; this scoring is in no way standardized, either within transient community or more broadly over all VOEvent users. VOEvents perform more poorly on metrics related to reuse and findability. In terms of reuse, VOEvents often lack information on provenance (i. e. how was this event judged to be a 'fast radio burst') and terms of reuse such as a license or citation guideline can be unclear. The biggest issue, however, is related to the findability of VOEvents. At present, no robust system exists for querying past events and finding VOEvents in, i. e. a particular region of the sky, date range, or waveband. The specific issue of querying past events is addressed in the next section, but some discussion time in this workshop was given to making FAIR data principles a priority as we begin to develop new capabilities for VOEvents.
Querying past VOEvents In the context of the FAIR data principles discussed above, one topic of discussion at this workshop was the need for better tools to query past VOEvents including more organized archiving tools. A robust querying infrastructure would make VOEvents much more findable. Ideally, when a new transient event is found, you would like to know if other facilities detected a transient in the error circle of your detection either at the same time or in the past, if other facilities were observing the field at the same time, and if other observatories have looked at this field previously. Tools for querying should also take into account the observation error box, both of the new transient event and previous transients reported nearby. In this context, a successful system would require that facilities report their observing plans to be queried later.
Requested changes to VOEvents In addition to the discussion points raised above, the workshop organizers also asked the participants for feedback on what aspects of the VOEvent structure should be changed or if new parameters should be added. The following recommendations were made by the community: • Inclusion of non-standard error regions to describe irregular beam shapes, or multiple noncontiguous sky regions, e. g. , through the use of HEALPix Multi-Order Coverage localization skymaps 6. • A new entry in the Why element for 'source type' with standard entry options, e. g. FRB, sGRB, LGRB, LMXB,. • Some definition or flag in the VOEvent metadata to identify the name of the service and/or stream of transient alerts from which the event was generated.
Assessing chromatin profiles at single-cell resolution is now feasible thanks to recently published experimental methods such as single cell chromatin immunoprecipitation followed by sequencing (scChIP-seq)  (Grosselin et al. , 2019; Rotem et al. , 2015)  and single-cell assay for transposaseaccessibility chromatin (scATAC-seq)  (Buenrostro et al. , 2015; Chen et al. , 2018; Cusanovich et al. , 2015; Lareau et al. , 2019). With these methods, we can detect the heterogeneity of epigenomic profiles within complex biological samples. Yet, existing tools used to analyze bulk epigenomic experiments are not fit for the low coverage and sparsity of single-cell epigenomic datasets. Here, we present ChromSCape: a user-friendly Shiny/R application that processes single-cell epigenomic data to help the biological interpretation of epigenomic landscapes within cell populations.
, 2017) , Cicero  (Pliner et al. , 2018)  or Scasat  (Baker et al. , 2019). However these tools are dedicated to scATAC-seq and are not stand-alone applications, thus requiring some scripting skills. To the best of our knowledge, there has not been any stand-alone analytic tool destined to comprehensively analyze region-based scChIP-seq count data. With ChromSCape, we propose a user-friendly, step-by-step and customizable Shiny application to analyze sparse single-cell chromatin profiling datasets. The pipeline is designed for high-throughput single-cell datasets with samples containing as low as 100 cells and with a minimum of 1000 reads per cell. The interactive process includes filtering out cells with low coverage and regions with low cell count, dimensionality reduction by PCA, classifying cells in an unsupervised manner to identify subpopulations and find biologically relevant loci differentially enriched in each sub-populations.
To overcome the sparsity of matrices due to the current technical limitations of these technologies, reads mapped to the genome must be binned prior to the use of ChromSCape into successive bins of the genome. These bins range from 5,000bp (recommendation for H3K4me3 scChIP-seq datasets) up to 50,000bp (recommendation for H3K27me3 scChIP-seq datasets), depending on the modification studied, to increase signal with a resolution trade-off.