dataesr/scientific-paragraphs-categorization huggingface dataset:
R> data$snpX A SnpMatrix with 429 rows and 209 columns Row names: H97. RA345 Col names: rs10510123. rs4328262 Since the use of stringent filters could lead to the elimination of all SNPs within a gene, care has to be taken during the filtering step. However, in such a situation a gene without SNPs is removed from the dataset and a warning message is provided for the user. In other situations, the user might be interested in performing the analysis on a predefined subset of SNPs. For that purpose, the selectSnps function provides three options to extract a collection of SNPs by specifying the argument select that should be one of the following: • a numeric vector with only the column number in the 'snpMatrix' (or row number for genes. info) of each selected SNP. The following code line allows the extraction of the 10 first SNPs: R> selec <-selectSnps(data$snpX, data$genes.
Genotype imputation Since our pipeline of analysis does not handle missing values, SNPs filtering as well as SNPs selection can help removing missing data. As described in the previous section, this can be done easily by applying the snpMatrixScour function with argument call. rate = 1. However, in this case, SNPs with an acceptable call rate are also removed and the lost information is likely to be critical. Genotype imputation is then commonly performed to keep most of the informative SNPs in the dataset. Since our genotype data are stored into a 'SnpMatrix' object, we implement the imputeSnpMatrix function that wraps functions snp. imputation and impute. snps from package snpStats. Our imputeSnpMatrix function mimics a leave-one-out process where missing SNPs are imputed for an individual based on a model trained on all other individuals.
In our example, the following code lines show that after the filtering step, 844 missing values still remain in the dataset. R> sum(is. na(data$snpX)) [1] 844 To impute those missing values, we used our imputeSnpMatrix function as follows: R> data <-imputeSnpMatrix(data$snpX, data$genes. info) |------------------------------------------------------------------| 100% A simple check of the dataset shows that all missing values have been imputed: R> sum(is. na(data$snpX)) [1] 0 When the amount of missing values is so large that snp. imputation is not able to find a rule of imputation, some missing values may remain. In this case, the user can specify the action to be done thanks to the om. rem argument: • om. rem = "none": leave the dataset as it is, • om. rem = "SNP": remove all SNPs with remaining missing values, • om.
rem = "ind": remove all individuals with remaining missing values. It is noteworthy that removing all SNPs is often more parsimonious than removing individuals and allows to get a dataset without any missing values with minimum information loss. Although, function snp. imputation can calculate accurate rules for imputation, we encourage the user to first impute missing genotypes with an external software (such as IMPUTE2;  Howie, Donnelly, and Marchini 2009)  prior to the importation step.
Statistical analysis The statistical analysis of a set of genes, as implemented in the GGI function, consists in performing all possible pairwise tests between two genes. Pairwise tests are conducted by using the method argument with one of the 10 methods detailed in Section 3. The GGI function takes two further mandatory arguments: Y the vector of case-control status and snpX, a 'SnpMatrix' object that stores the genotypes for all SNPs. It is assumed that SNPs within the same gene are consecutive in the snpX argument. Furthermore, gene information, such as gene ordering and the number of SNPs within each gene, has to be provided either in the genes. length or in the gene. info argument. The following code line allows the computation of all pairwise tests between the 17 genes of our example dataset with the PCA-based method.
R> GGI. res <-GGI(Y = Y, snpX = data$snpX, genes. info = data$genes. info, + method = "PCA") The output of the GGI function is a an object of class 'GGInetwork'. R> class(GGI. res) [1] "GGInetwork" The class 'GGInetwork' is an S3 class based on a list of 4 elements statistic, p. value, method and parameter. When method = "PCA", a fifth element, called df, is added to the 'GGInetwork'. R> names(GGI. res) [1] "statistic" "p. value" "df" "method" "parameter" Elements statistic, p. value and statistic, df are square matrices with M rows and M columns where M is the number of genes in the dataset. The elements of each matrix are the statistic, the p value and the degrees of freedom of the likelihood ratio test, respectively. The element method is the name of the method used to perform the pairwise interaction tests.
Finally, the element parameter is a list of the parameters used to perform the pairwise interaction tests. As example, the GGI. res object generated in the previous example is a list of 5 elements. Each cell of the output p. value matrix is the p value of the corresponding pairwise test. The pairwise p values obtained for the 4 first genes (bub3, CA1, CDSN, DNAH9) of our dataset can be observed as follows: R> round(GGI. res$p. value[1:4, 1:4], digits = 4) bub3 CA1 CDSN DNAH9 bub3 0. 0000 0. 1684 0. 3179 0. 1851 CA1 0. 1684 0. 0000 0. 0697 0. 0000 CDSN 0. 3179 0. 0697 0. 0000 0. 4539 DNAH9 0. 1851 0. 0000 0. 4539 0. 0000 Significant results can be summarized using the S3 method summary for class 'GGInetwork'. The method summary prints out the pairs of genes with an interaction p value lower than 0.
Discussion This article presents the R package GeneGeneInteR dedicated to the detection of an interaction between SNP sets in case-control genome-wide association studies. The package includes the GGI function performing all pairwise tests between two SNP sets and producing output of the class 'GGInetwork'. The GGI function takes two main arguments: method and snpX, a 'SnpMatrix' object. The method argument allows the user to specify the statistical procedure used for pairwise interaction testing as one of the ten methods implemented in GeneGeneInteR. Furthermore, several methods have been implemented in Gene-GeneInteR to import, manipulate and impute missing values for the snpX objects. Methods summary and plot, associated with objects of the class 'GGInetwork', are also proposed. The plot method allows the production of heatmap or network visualization of the statistical interaction between SNP sets.
The R package GeneGeneInteR is available from Bioconductor (https://bioconductor. org/packages/GeneGeneInteR/) and from GitHub (https://github. com/MathieuEmily/GeneGeneInteR). Since our implementation relies on 'SnpMatrix' objects, GeneGeneInteR could in principle handle large datasets. However, in practice, testing for pairwise interaction remains a combinatorial burden and highly computationally efficient methods are needed to perform largescale analysis. In GeneGeneInteR, some methods are still computationally intensive (KCCA, PLSPM, GBIGM for example) so that their use is not recommended for large datasets. Possible extensions of GeneGeneInteR could consist in speeding up the execution time either by using parallel processing with the package parallel (R Core Team 2020) or by porting existing R code to C++ with Rcpp  (Eddelbuettel and François 2011).
Another limitation raised by the analysis of large scale datasets is the visualization of the results. However, we proposed several options to the user in order to focus on specific parts of a big network. Furthermore, the visualization of a big network provides information regarding a global pattern of relationships between SNP sets. Since the main purpose of the package GeneGeneInteR is to search for pairwise interactions, the detection of specific patterns in a network is beyond the scope of this work. Finally, one of the main advantages of the GeneGeneInteR package lies in the use of a common pipeline of analysis for a collection of statistical procedures. Thus, GeneGeneInteR can easily be extended with the inclusion of novel statistical procedures to detect pairwise interaction between SNP sets.
The dataset gene. pair is a case-control dataset containing the genotypes of 8 SNPs within GC gene (object G1 of class 'SnpMatrix') and 4 SNPs within PADI2 gene (object G2 of class 'SnpMatrix'). The dataset gene. pair further includes the disease status in a factor variable Y. In more details, gene. pair contains 247 individuals affected by rheumatoid arthritis (RA).
The dataset gene. pair is a case-control dataset containing the genotypes of 8 SNPs within GC gene (object G1 of class 'SnpMatrix') and 4 SNPs within PADI2 gene (object G2 of class 'SnpMatrix'). The dataset gene. pair further includes the disease status in a factor variable Y. In more details, gene. pair contains 247 individuals affected by rheumatoid arthritis (RA) Length Class Mode Y 453 factor numeric G1 3624 SnpMatrix raw G2 1812 SnpMatrix raw (Y = 1) and 206 individuals not affected by RA (Y = 0). The contents of the dataset gene. pair are summarized by the following command lines: R> library("GeneGeneInteR") R> data("gene. pair", package = "GeneGeneInteR") R> summary(gene. pair).
Our algorithms are implemented in Maple 1  and Reduce 2   [43, 42]  and systematically applied to the steady state varieties of 129 models from the BioModels repository 3. Our objective was to build on robust, off-the-shelf software, which has a chance to be accepted by scientific communities outside symbolic computation in the foreseeable future. As a consequence, our proposed algorithms must rely on existing implementations. Over C we use Gröbner bases  [8, 25, 26] , and over R we use real quantifier elimination techniques. Gröbner bases and real quantifier elimination mentioned above come with high intrinsic complexity. The former are complete for exponential space  [50]. The latter are double exponential  [18, 38, 69]. From a more theoretical point of view we study the intrinsic complexity of the problems actually addressed.
Algorithmic Classification of Biomodels We want to apply our concept of shifted toricity to biomodels focusing on the BioModels 4  repository of mathematical models of biological and biomedical systems  [9]. The BioModels repository uses the Systems Biology Markup Language (SBML)  [45, 30]. SBML is a representation format, based on XML, for communicating and storing computational models of biological processes. It is a free and open standard with widespread software support and a community of users and developers. SBML models have been typically created in the context of numerical computations or simulations and must be processed carefully with symbolic computation. For instance, numerical values, like reaction rate constants, contained in the models are often represented as truncated fixed point floats, and the available SBML parsers possibly introduce further rounding errors when implicitly performing substitutions with those values.
In Appendix A. 2 we discuss practical aspects of our computations and give in Table  3  classification results using Algorithm 3 on the 129 models introduced at the beginning of this section. We succeed on 105 out of the 129 models within a time limit of 6 hours per model. This yields 3426 prime components to test altogether. We obtain 2 G, 22 C, and 1085 c, which can be summarized as V C ( Pi ) * forming a coset. Furthermore, we have 2242 o, i. e. , V C ( Pi ) * = ∅. The rest is only 34 X and 41 x. Again we visualize these results in terms of percentages of the total of 3426 prime components: Recall that our selection from the BioModels repository presented here is essentially complete with respect to polynomial examples. This comes with the disadvantage that our data is somewhat dominated by BIOMD0000000281, which contributes 1008 c and 2136 o.
Experimental computations on the complete dataset considered here have confirmed that formulation (5) is clearly preferable. Example 24 (BIOMD0000000159). Consider F ⊆ Q[X], where X = {x 1 ,. , x 3 }: F = {-32x 1 x 2 + 3, -x 2 + x 3 , 4x 1 -x 3 }. In lines 3-8 of Algorithm 4 we consecutively apply real quantifier elimination to the following formulas: ∀x 1 ∀x 2 ∀x 3 (-32x 1 x 2 + 3 = 0 ∧ -x 2 + x 3 = 0 ∧ 4x 1 -x 3 = 0 -→ x i = 0), i = 1,. , 3. Neither of them holds in R so that in line 9 we enter Algorithm 5 with X = X and F = F. In line 2 of Algorithm 5 we test ∃x 1 ∃x 2 ∃x 3 (x 1 = 0 ∧ x 2 = 0 ∧ x 3 = 0 ∧ -32x 1 x 2 + 3 = 0 ∧ -x 2 + x 3 = 0 ∧ 4x 1 -x 3 = 0). ( 7 ) Real quantifier elimination  [48]  confirms that  (7)  holds in R, and extended quantifier elimination  [49]  even gives us a witness (x 1 , x 2 , x 3 ) = √ 3 8 √ 2 , √ 3 2 √ 2 , √ 3 2 √ 2 ∈ V R (F ) *.
Conclusions and Future Work We have taken a geometric approach to studying steady state varieties, which-besides significant theoretical results-generated comprehensive empirical data from computations on 129 networks from BioModels repository. We are not aware of any comparable systematic large scale symbolic computations on those data in the literature. We were indeed surprised by the success rate of Gröbner basis and real quantifier elimination techniques with input sizes up to 71 variables. We find this most encouraging and believe that robust and supported software tools for systems biology and medicine that include symbolic computation components are not out of reach. It was important to learn that real methods do not significantly fall behind complex methods efficiency-wise. After all, chemical reaction network theory takes place in the interior of the positive first orthant.
Acknowledgments This work has been supported by the  bilateral  project  ANR-17-CE40-0036/DFG-391322026  SYMBIONT [5,6]. The first author is grateful to grant  RSF-16-11-10075  and to MCCME for the inspiring atmosphere. Stephen Forrest at Maplesoft and  Arthur Norman  at the  University of Cambridge  greatly helped with Maple-and Reduce-related technical issues, respectively. Christoph Lüders at the  University of Bonn  greatly supported the project with discussions around and generation of suitable input data.
Research Methodology This research is based on a smart monitoring of three apartments in a social housing residence in the North of France, which includes (i) use of smart sensors to record the indoor temperature and humidity in the different rooms of each apartment and (ii) and a questionnaire for the volunteer occupants to estimate energy production related to their presence in the apartment. Due to the old equipment of this residence and the complexity of the heating system, the energy consumption was not recorded at short time interval. It was obtained from the manager of the social housing for the period of heating. To estimate energy savings, the software ArchiWIZARD was used for establishing a numerical model for each apartment  [7, 8]. The parameters of the thermal model were determined from the records of indoor and outdoor temperatures as well as from the global heating consumption provided by the social housing manager.
Monitoring Program and Data Collection The social housing residence was built in 1973 and renovated in 2012. The residence is composed of 15 apartments distributed in 5 floors. The monitoring program concerned three occupied apartments. The first one is located on the 1st floor, while the others are located on the 4th floor. The residence is heated by a central heating system. Heating regulation is conducted by manual valves at the radiator level. The monitoring system is composed of a central unit, wireless sensors, and user interface. The central unit consists of a Raspberry Pi, which uses the open-source Linux operating system and a SD Card for data storage. Figure  1  illustrates the architecture of monitoring system. Indoor temperature and humidity were recorded using SI7021 sensors. Table  1  provides the characteristics of these sensors.
Numerical Modeling Estimation of the heating energy savings in the apartments was conducted using the software ArchiWIZARD. This software allows determination of energy need for given indoor and outdoor temperatures. It requires physical characteristics of the building and appliances as well as the occupant activity. The building's installations and technical equipment were provided by the residence manager. The occupant activity was obtained through a questionnaire. Global energy consumption was provided by the residence manager. Over the heating period, the heating energy consumption for the apartment of the first floor was equal to 95 kwh/(m². an). A trial-by-trial data analysis using ArchiWIZARD software was conducted for the estimation of the overall loss coefficient of the apartment envelope.
This analysis was based on the indoor and outdoor recorded temperatures, the thermal characteristics of the building and energy consumption. It gave an overall loss coefficient of the envelope Ubat = 0. 7. ArchiWIZARD software was then used with the overall loss coefficient of the envelope (Ubat = 0. 7) to estimate energy need for the recorded indoor and outdoor temperatures. It gave an energy need of 101 kwh/(m². an), which is about 6% higher than that provided by the manager. According to  Yan et al. ,  this difference between estimated energy need and energy consumption is acceptable  [9].
Numerical Modeling Estimation of the heating energy savings in the apartments was conducted using the software ArchiWIZARD. This software allows determination of energy need for given indoor and outdoor temperatures. It requires physical characteristics of the building and appliances as well as the occupant activity. The building's installations and technical equipment were provided by the residence manager. The occupant activity was obtained through a questionnaire. Global energy consumption was provided by the residence manager. Over the heating period, the heating energy consumption for the apartment of the first floor was equal to 95 kwh/(m 2 •an). A trial-by-trial data analysis using ArchiWIZARD software was conducted for the estimation of the overall loss coefficient of the apartment envelope.
This analysis was based on the indoor and outdoor recorded temperatures, the thermal characteristics of the building and energy consumption. It gave an overall loss coefficient of the envelope Ubat = 0. 7. ArchiWIZARD software was then used with the overall loss coefficient of the envelope (Ubat = 0. 7) to estimate energy need for the recorded indoor and outdoor temperatures. It gave an energy need of 101 kwh/(m 2 •an), which is about 6% higher than that provided by the manager. According to  Yan et al. ,  this difference between estimated energy need and energy consumption is acceptable  [9].
Conclusions This paper presented an investigation of potential heating energy savings in a social housing residence. This issue is of high concern, because the social housing sector suffers generally from low energy performance, which lead to high energy consumption and high pressure on the budget of low-income occupants. The study was conducted using a smart monitoring of some apartments in a social housing residence and a thermal modeling of these apartments by ArchiWIZARD software. Indoor temperature was recorded for the period December 2016-April 2017. The recorded temperature was generally high with an average value of 23. 8 • C and some peaks close to 29 • C. Energy savings were estimated using the software ArchiWIZARD with regard to the application of two thermal regulations: the social landlord's regulations and the French thermal regulations RT 2012.
e. , CCAmL2  [GPPS19a] ), the TETSponge mode has the significant advantage of being single-pass in encryption and in decryption, which we believe is essential for lightweight implementations. 2  Concretely, TETSponge encourages so-called leveled implementations, where (expensive) protections against side-channel attacks are used in a limited way and independent of the message size, while the bulk of the computation is executed by cheap and weakly protected components. As exhibited in [BGP + 20] and [BBC + 20] for software (resp. , hardware) implementations, leveled implementations allow significant energy gains when side-channel protections must be activated. The second ingredient is the adoption of regular symmetric primitives to operate the TETSponge mode of operation, namely the Clyde-128 Tweakable Block Cipher (TBC) and the Shadow-512 permutation, both based on simple extensions of the LS-design framework, which aims at efficient bitslice implementations  [GLSV14].
Eventually, and besides these main features, Spook inherits other interesting properties from the TETSponge mode of operation: (i) it is secure beyond the birthday bound (with respect to the size n of the TBC), and (ii) it can provide n-bit multi-user security at low cost with a public tweak. We additionally note that an important aspect of our security claims is that we consider security definitions that allow all the computations (including the computation of the "challenge ciphertext") to leak, which we denote as leakage-resistance (following the terminology in  [GPPS19a, Sta19] ). This is in contrast with alternative definitions of leakage-resilience excluding the leakage of the challenge ciphertext (e. g. ,  [BMOS17] ). Besides specifications and design rationale for the mode and primitives, we provide first software and hardware implementation results of (unprotected) Spook and confirm the limited overheads that our use of two primitives with shared S-boxes and L-boxes imply.
Rationale: design trade-offs, advantages & limitations Spook is an AEAD algorithm with state-of-the-art guarantees in the black box setting. Namely, it ensures beyond-birthday security with respect to the block size of its underlying TBC, can be extended to multi-user security with a public tweak, and provides nonce misuseresilience in the sense of Ashur et al  [ADL17]. Thanks to its one-pass structure, Spook should allow efficient implementations on a wide range of platforms. Its design is in particular well-suited to 32-bit software implementations (thanks to an intensive exploitation of 32-bit word-level operations), and to dedicated hardware and FPGA implementations (thanks to the low gate complexity and limited depth of its different components). Spook provides excellent opportunities to mitigate physical attacks efficiently thanks to its leakage-resistant features.
In particular, the general rationale behind its design enables leveled implementations, where the Clyde-128 TBC is well protected against side-channel attacks and the Shadow-512 (or Shadow-384) permutation is implemented with cheaper protections (or even no protections at all). It is in the specific contexts where physical attacks are an important concern that Spook is expected to exhibit significant performance (e. g. , energy) gains compared to modes without leakage-resistant (or resilient) features. Concretely, protecting the TBC can be achieved thanks to the masking countermeasure, both in hardware  [CGLS20]  and in software  [GR17]. For this purpose, Clyde-128 is designed both with low AND complexity (as previous LS-designs) and low AND depth (which is important to limit the latency of so-called glitch-resistant implementations [NRS11, FGP + 18]).
As for the permutation, low-latency / low-energy implementations in the sense of [KDH + 12] are natural candidates in hardware, while some minimum countermeasures to prevent SPA (e. g. , low-order masking, or time randomization  [VMKS12] ) should be sufficient in software. For this purpose, the Shadow-512 (or Shadow-384) permutation is designed with low-latency components. Leveled implementations of Spook can also benefit from pre-computing the (expensive) generation of fresh seeds if needed. The main price to pay for the leakage-resistant features of Spook is that it suffers from some overheads in case of short messages. This seems unavoidable in any mode leveraging a re-keying process. However, and as evaluated in [BGP + 20, BBC + 20], these overheads are amortized as soon as the data to process is a few blocks long, and the gains of leveled implementations can reach factors 10 to 100 (e.