dataesr/scientific-paragraphs-categorization huggingface dataset:
TemporalDataFrames, providing usual features of pandas DataFrames and subsetting mechanisms with an extra time dimension. Under the hood, TemporalDataFrames work on 2-dimensional datasets but store an extra hidden column for annotating rows with the timepoint they belong to. The dataset is only reorganized into 3 dimensions for display. Obtaining a subset of a TemporalDataFrame is done with the usual square brackets indexing mechanism, where the first index selects one or more timepoints, the second index selects rows (cells) and the third selects columns (genes) (see S1 Listing for an example). For interoperability with pandas, TemporalDataFrames can be created from pandas DataFrames or can be converted to them. VData can read from on-disk files to reduce the memory footprint Once a VData object has been created, it can be stored as an on-disk file using the hdf5 file format  [20]  (see  Fig 2)  similarly to how it can be done in AnnData.
Opening a VData from an hdf5 file is refered to as "backing" the object. When a VData object is backed -and as opposed to how it is done in AnnDataall of its contents are accessed in small chunks of configurable size only when required. This includes 'layers', 'obs', 'var', 'timepoints' but also all data in the 'uns' dictionary. This means that no object needlessly uses computer memory, except for the one currently being read or written to. To allow data of many different types to be backed, we wrote an other small Python library called Ch5mpy. Fig. 2  HDF5 file format. HDF5 files contain a tree of containers called groups (green boxes) and datasets that contain data of any dimension (blue boxes). The root of any HDF5 file is the "/" group. Groups can contain any number of sub-groups or of datasets.
VData is built on top of Ch5mpy for reading from hdf5 files Ch5mpy (pronounced "champy") is a small Python library built on top of the h5py library  [21]  that introduces user-friendly wrappers to handle objects and data stored in hdf5 files as more common Python objects. Most notably, Ch5mpy allows to : • explore an hdf5 file as if it were a Python dictionary, only loading in memory the groups or datasets names. The actual dataset will be loaded only when requested by the user. • interact with datasets as if they were numpy arrays  [22]. This includes subsetting, reshaping, data-type casting and applying numpy operations while ensuring the memory usage stays below a configurable threshold. It also defines a simple API for writing and reading any object to an hdf5 file as a collection of datasets and in some cases will guess on its own how to write simple objects to the file.
VData opens large datasets with low memory footprint To demonstrate VData's ability to load very large datasets, we built test VData and AnnData objects, each with 4 layers of random values with increasing numbers of genes and cells : • 1000 cells × 2000 genes (62. 8MB) • 10000 cells × 10000 genes (3. 1GB) • 50000 cells × 10000 genes (14. 7GB) • 50000 cells × 50000 genes (75. 1GB) • 100000 cells × 50000 genes (149. 8GB) accesses it only when necessary, it was able to load all datasets while maintaining the memory footprint to less than 100MB. This allowed VData to read datasets larger than the available amount of RAM on our computer and in less than 0. 1 seconds. On the other hand, AnnData required large amounts of RAM and was slow to load large datasets. This was expected since AnnData usually relies on sparse matrices to lower the memory footprint and load time, which is not the case in this test setup and often not true with simulated data.
VData objects are compatible with the scverse ecosystem We developped VData as an extension of Anndata objects, following its structure as closely as possible to make it easy for users to transitition to VData. Creating a VData object from an existing Anndata simply requires the user to initialize the VData from the Anndata as : 'VData(existing anndata)' or by calling the 'read from anndata("path/to/anndata")' method to create a VData from a saved AnnData file. If needed, VData objects can be converted back to Anndata by calling the 'to anndata()' method. To allow VData objects to be used directly by tools of the scverse  [23]  without first converting VData objects to AnnData and thus giving up on the efficient memory usage, VData objects can be wrapped into an 'AnnDataProxy'. AnnDataProxies inherit from AnnData and parse AnnData operations or method calls to produce valid VData operations.
Conclusions VData is an extension to AnnData written from scratch in Python. While the base structure remains the same, the supplementary time axis allows to easily deal with time-stamped data, often generated by simulation algorithms. When designing VData, focus was put on keeping the memory footprint low and on ease of integration with existing tools. For that, VData uses the Ch5mpy Python library (also made freely available) for backing all data on an hdf5 file and implements a wrapper that makes VData objects compatible with tools working on AnnData objects. This makes it possible to apply, on regular computers, widely used bioinformatics tools to datasets of sizes that would previously require enourmous amounts of RAM.
Availability of data and materials VData and Ch5mpy are available as Python libraries. They can be downloaded from github at https://github. com/Vidium/vdata and https://github. com/Vidium/ ch5mpy respectively. Libraries can also be installed with pip by running 'pip install vdata' which installs both VData and Ch5mpy, or by runninh 'pip install ch5mpy' which installs Ch5mpy alone.
In this paper we enhance the EasyCrypt proof assistant to reason about computational complexity of adversaries. The key technical tool is a Hoare logic for reasoning about computational complexity (execution time and oracle calls) of adversarial computations. Our Hoare logic is built on top of the module system used by EasyCrypt for modeling adversaries. We prove that our logic is sound w. r. t. the semantics of EasyCrypt programs -we also provide full semantics for the EasyCrypt module system, which was previously lacking. We showcase (for the first time in EasyCrypt and in other computer-aided cryptographic tools) how our approach can express precise relationships between the probability of adversarial success and their execution time. In particular, we can quantify existentially over adversaries in a complexity class, and express general composition statements in simulation-based frameworks.
This work overcomes this limitation and showcases the benefits of reasoning about computational complexity in EasyCrypt, through three broad contributions. Formal verification of complexity statements. We define a formal system for specifying and proving complexity claims. Our formal system is based on an expressive module system, which enriches the existing EasyCrypt module system with declarations of memory footprints (specifying what is read and written) and cost (specifying which oracles can be called and how often). This richer module system is the basis for modeling the cost of a program as a tuple. The first component of the tuple represents the intrinsic cost of the program, i. e. its cost in a model where oracle and adversary calls are free. The remaining components of the tuple represent the number of calls to oracles and adversaries.
Note that the statement is only meaningful because the cost of B is conditioned on the cost of A, as the advantage of an unbounded adversary is typically 1. The ability to prove and instantiate such ∀∃-statements is essential for capturing compositional reasoning principles. We show correctness of our formal system w. r. t. an interpretation of programs. Our interpretation provides the first complete semantics for the EasyCrypt module system, which was previously lacking. This semantics is of independent interest and could be used to prove soundness of the two program logics supported by Easy-Crypt: a Relational Hoare Logic  [8]  and a Union Bound logic  [7]. Implementation in the EasyCrypt proof assistant. We have implemented our formal system as an extension to the EasyCrypt proof assistant, which provides mechanisms for declaring the cost of operators and for helping users derive the cost of expressions and programs.
Our implementation brings several contributions of independent interest, including an improvement of the memory restriction system of EasyCrypt, and a library and automation support to reason about extended integers that are used for reasoning about cost. For the latter we follow  [31]  and reduce formulae about extended integers to integer formulae that can be sent to SMT solvers. Another key step is to embed our Hoare logic for cost into the ambient higher-order logic-similar to what is done for the other program logics of EasyCrypt. This allows us to combine judgments from different program logics, and it enhances the expressiveness of the approach. Implementation-wise, this extension required to add or rewrite around 8 kLoC of EasyCrypt. The implementation and examples (including those of the paper as well as classic examples from the EasyCrypt distribution, including Bellare and Rogaway BR93 Encryption, Hashed ElGamal encryption, Cramer-Shoup encryption, and hybrid arguments) are open source  [20].
We derive the complexity statement in the theorem, which shows only the intrinsic cost of Inv, by instantiating the complexity type of Inv with the cost of its module parameter A. This illustrates how our finer-grained notion of cost is useful for compositional reasoning. Comparison with EasyCrypt. Our formalization follows the same pattern as the BR93 formalization from the EasyCrypt library. However, the classic module system of EasyCrypt only tracks read-andwrite effects and lacks first-class support for bounding the number of oracle calls and for reasoning about the complexity of programs. To compensate for this first point, classic EasyCrypt proofs use wrappers to explicitly count the number of calls and to return dummy answers when the number of adversarial calls to an oracle exceeds a threshold.
The use of wrappers suffices for reasoning about adversarial advantage. However, no similar solution can be used for reasoning about the computational cost of adversaries. Therefore, the BR93 formalization from the EasyCrypt library makes use of the explicit definition of I, and users must analyze the complexity of I outside the tool. As a result, machine-checked security statements are partial (complexity analysis is missing), cluttered (existential quantification is replaced by explicit witnesses), and compositional reasoning is hard (existential quantification over module types cannot be used meaningfully).
ENRICHED EASYCRYPT MODULE SYSTEM We present a formalization of our extended module system for EasyCrypt. It is based on EasyCrypt current imperative probabilistic programming language and module system, which we enrich to track the read-and-write memory footprint and complexity cost of module components through module restrictions. These module restrictions are checked through a type system: memory footprint type-checking is fully automatic, while type-checking a complexity restriction generates a proof obligation that is discharged to the user -using the cost Hoare logic we present later, in Section 4.
λ c ::= ⊤ | compl[intr : k, x 1. f 1 : k 1 ,. , x l. f l : k l ] For example, we give in Figure  4  EasyCrypt code corresponding to an adversary against a hardware security module. In this scenario the goal of the adversary is to recover the secret key stored in the module Hsm. The example uses two types of restrictions. The module-level restriction {+all mem, -Hsm} states that such an adversary can access all the memory, except for the memory used by the module Hsm. The procedure-level restriction [intr : k 0 , H. enc : k] attached to guess, states that guess execution time is at most k 0 (excluding calls to H. enc), and that guess can make at most k queries to the procedure H. enc. Formally, a module restriction is a list of pairs comprising a procedure identifier f and a procedure restriction λ, and a procedure restriction λ is either ⊤ (no restriction), or the conjunction of a memory restriction λ m and a complexity restriction λ c : Memory.
Mechanized Formalization in EasyCrypt We propose a natural simplification of the UC execution model that is based on EasyCrypt modules and show that this opens the way for a lightweight formalization of UC proofs. This formalization has been conducted in our extension of EasyCrypt (the proofs of the lemmas and theorems of this section are fully mechanized). Protocols and Functionalities as EasyCrypt modules. The basic component in our UC execution model is a module of type PRO-TOCOL given in Figure  7. Inhabitants of this type represent a full real-world configuration-a distributed protocol executed by a fixed number of parties-or an ideal-world configuration-an ideal functionality executing a protocol as a trusted-third party. The type of a protocol has a fixed interface, but it is parametric on the types of values exchanged via this interface.
g. , blocking the computation to model a possible denial of service attack). 6   number of procedure calls. Hence the resources used by any subset of modules in our formalizations can be expressed as an expression on these type parameters. 6 Ideal-world backdoors are used to weaken the security requirements and are usually tailored to bring the security definition down to a level that can be met by real-world protocols. Note that the definition of meaningful ideal functionalities is a crucial aspect of UC security theory; here we just provide a mechanism that permits formalizing such definitions in EasyCrypt. Execution Model. The real-and ideal-world configurations are composed by a statically determined set of modules, which communicate with each-other using a set of hardwired interfaces.
An important design goal of EasyUC is to follow the UC execution model as closely as possible; this allows a more direct translation of protocols and ideal functionalities. In contrast, our goal is to take advantage of the EasyCrypt machinery to reduce proof effort and development size: our development (including complexity) takes 2300 lines of code and it includes general UC theorems that can be reused in future work; this compares to 18K lines of code for EasyUC. 9  The downside of our approach is the impact in the way one specifies protocols and ideal functionalities: message passing corresponds to procedure calls, and these must adhere to the EasyCrypt tree-based procedure call semantics. For example, we do not allow an execution environment where a party communicates with an ideal functionality arbitrarily without relying on the environment for scheduling; one could of course formalize a message passing mechanism on top of EasyCrypt as in  [19]  to allow for this, but this would then fall out of the scope of our general composition theorems.
CryptoVerif  [12]  is an automated tool for computational security proofs. CryptoVerif uses approximate equivalences to find (or check) cryptographic reductions, and keeps track of the complexity of adversaries. Most other tools for computational security proofs, including CertiCrypt  [8] , Foundational Cryptography Framework  [29] , and CryptHOL  [10] , share their foundations and overall approach with EasyCrypt. However, these tools offer limited support for complexity reasoning and they do not support the use of modules for defining cryptographic schemes and notions. This is not a fundamental limitation, since these tools are embedded in a general-purpose proof assistant. However, extending these tools to achieve similar effects as our typeand-effect module system and program logic for complexity would represent a significant endeavor.
Our module system is inspired from EasyCrypt  [6, 9]. However, the EasyCrypt module system lacks complexity restrictions, which hampers the use of compositional approaches. Beyond EasyCrypt, several other tools and approaches use structures similar to modules for formalizing cryptographic schemes and their security. Computational Indistinguishability Logic (CIL)  [5]  rely on oracle systems, which are very closely related to our modules. Interestingly, the main judgment of CIL establishes the approximate equivalence of two oracle systems, and is explicitly quantified by the resources of an adversary. State-separating proofs  [14]  pursue similar goals, using a notion of package. Packages have the expressivity of modules, but additionally support private functions. Our modules can emulate private functions using restrictions.
CONCLUSION We have developed an extension of the EasyCrypt proof assistant to support reasoning complexity claims. The extension captures reductionist statements that faithfully match the cryptographic literature and supports compositional reasoning. As a main example, we have shown how to formalize key results from Universal Composability, a long-standing goal of computer-aided cryptography. Appendix Outline. We quickly outline the structure of the appendix. We show that the standard dummy adversary theorem holds in our UC modeling in Appendix A. We present the type system for our programming language and module system in Appendix B. Then, we present the semantics of our module system. This module semantics takes the form of a module resolution mechanism, which describe how module expressions are evaluated, and is given in Appendix C.
Functor are typed by the Func rule. Note that the functor body is typed in an extended typing environment, where the module parameter x has been declared as an abstract module with kind param. The typing judgment for module structures Γ ⊢ p,θ st : S is annotated by both the module path of the structure being typed, and the module restriction θ that the structure must verify. Remark that when we type a procedure using ProcDecl, we check that the procedure f body satisfies the module restriction θ [f ] by requiring that the restriction checking judgment Γ ⊢ body ▷ θ [f ] holds.
Study Sites, Experimental Layout, and Data Collection The study considered two pastoral farms (Figure  2 ) located at different altitudes in the Tuscan Apennines (Table  1 ), both managed under continuous grazing system of Limousin cattle (Table  2 ). The Marradi study site (M) covers more than 5 ha of upland sown pasture that tends towards a re-naturalization, usually grazed from May to July. The Borgo San Lorenzo study site (B) covers 30 ha of lowland sown pasture. For the purpose of the trial, Site B was divided in 2020 into two differently managed sub-areas, B1 (approx. 10 ha) and B2 (approx. 20 ha). Specifically, in sub-area B1 the pasture was grazed by Limousin cattle from April until the end of October, while sub-area B2 was managed under a mixed utilization: mowed in May and grazed from June until the end of October.
Field data were collected in 16 randomly arranged samples in an area of 1 m 2 each (eight in M, four in B1, and four in B2). The sampling position was changed from time to time, taking care to choose areas that represented the general situation. The AccuPAR PAR/LAI Ceptometer Model LP-80 (Decagon Devices, 2017) was used to measure LAI in each plot.
The Grassland Model The Pasture Simulation model (PaSim) was chosen for this study because it can describe in detail the dynamic biogeochemical responses of a grassland system under altered climate and management. Originally developed by Riedo et al. [48] , PaSim simulates the cycling of water, C, and N in grassland systems at a sub-daily time step (1/50th of a day) or, as in this work, at a daily time step. Microclimate, soil biophysics, vegetation, herbivores, and management practices are interacting modules. The simulations are not spatially resolved (e. g. , inhomogeneity is not taken into account) and input/output data are assumed to be representative of the entire field. The assimilated photosynthetic C is dynamically allocated to a root and three shoot compartments (each composed of four age classes) or lost through animal metabolism (ecosystem respiration).
Simulation Design The modeling work was performed in four simulation suites: Suite 1 with observational data (calibration), Suite 2 with projected climate change scenarios with CO 2 fertilization effect (impact projections), Suite 3 with projected climate change scenarios without CO 2 fertilization effect (sensitivity), and Suite 4 with modified management under projected climate change scenarios with CO 2 fertilization effect (adaptation assessment). For Suite 1, the simulations setup included weather, soil, vegetation variables and management implementation in the studied years (2020 and 2021). The weather variables included daily minimum and maximum air temperatures, precipitation, and solar radiation. Temperature, precipitation, and wind speed data for 2020 and 2021 were collected from the regional weather stations of Tuscany Region (SIR, Servizio Idrologico Regionale, https://www.
sir. toscana. it/index. php, accessed on 20 January 2023) located near the study sites. Daily global solar radiation data were generated from the R package "sirad", developed by Bojanowski et al. [63] , based on the model of Bristow and Campbell  [54]. The soil data were extracted from the SoilgridsTM dataset (https://soilgrids. org, accessed on 20 January 2023), described in Poggio et al. [64]. The actual management practices (grazing intensity and periods) are described in Table  2. Model calibration was not applied separately to each site. The model was calibrated on all datasets to obtain more realistic and robust parameter values for application on a larger scale, as in Ma et al. [59]. The availability of detailed LAI and AGB data from two grassland sites offered the possibility of a genuine (multi-location and multi-output) calibration of the model, on the assumption that a unique calibration across sites is appropriate under these conditions.
The sets of parameter values resulting from the model calibration were used to compare the PaSim outputs (AGB and LAI) with the observations in each study site. The agreement between simulated and observed AGB and LAI was assessed by inspection of time-series plots (fluctuations of output variables over time) and numerically, through two performance metrics commonly used in model evaluation  [65] : relative root mean square error (best, 0 ≤ RRMSE < +∞, worst) and coefficient of determination (worst, 0 ≤ R 2 ≤ 1, best). For Suites 2, 3, and 4, simulated pastoral outputs were obtained by forcing the calibrated PaSim with the downscaled (bias-corrected) daily weather data described in Section 2. 2, Climate Scenarios and Models. Projected PaSim responses to climate change forcing options were calculated on changes in a set of agro-ecosystem outputs related to growing season length, fodder production, water cycle, and C-N fluxes (Table  3 ).
This correlation is founded on the principle that, during cooling operation, higher outdoor air temperature proportional to a higher HVAC energy consumption. Hence, when a GTA is actuated in the building, higher HVAC energy consumption would lead to a larger magnitude shed. The combination of these two observations led to the proposal of load shedding potential models that use OAT as a predictor variable and are actuated through GTA inputs  [37]. In particular, these models often rely on simplified estimation frameworks, such as a linear model, to satisfy the scalability requirement mentioned earlier. Notably, the authors of  [51]  proposed a surrogate modeling approach to predict the flexibility of commercial buildings using a large dataset of events generated in EnergyPlus. In this work, individual piecewise linear regression models were fitted with more than 300 M data points achieving between 80-90% accuracy for more than 90% of the events.