dataesr/scientific-paragraphs-categorization huggingface dataset:
Using this design, all one-to-many and many-to-many relationships become either vectors (e. g. , hashtags, at tags) or nested documents (e. g. , words, named entities). Where the information is not present, these vectors and nested documents may be missing thanks to the flexibility of schemaless database design. A problem that arises is duplication, as multiple records can bear the same metadata, since all the information for a document is stored in one single record. The vocabulary entity is constructed as a separate collection. This entity is constructed dynamically, taking user input constraints into account, e. g. date, tags, search words, named-entities. Interaction with the database is achieved through CRUD operations, aggregation functions and views. We use read operations for information extraction and data visualization.
Text Preprocessing The data cleaning module serves three functions: 1) corpus standardization, 2) text preprocessing using NLP to enrich data, and 3) entity creation and information insertion into the database. The entire corpus is standardized by determining all the fields of a document, including metadata and the labels of documents. Then, during the preprocessing step, the following techniques are applied: 1) text cleaning by removing HTML/XML tags and scripts; 2) language identification; 3) expanding contractions; 4) extracting features, e. g. , PoS, lemmas and named entities; 5) removing stop words and punctuation; 6) computing term weights. We use a multithreading architecture for data cleaning to cope with large data volumes and scale up vertically. At the end of each thread, the information is stored in a dictionary, together with other metadata.
We choose to use asynchronous threads because, after a worker thread finishes, a new job can be assigned to it without waiting for the other worker threads to finish. This is made possible because each task is independent. At the end of this step, a record of the documents collection is created and inserted into the database. The record contains all labels from the first step and the information extracted using NLP from the second one. In the DODBMS implementation, a record stores all the information because its attributes are created dynamically. In contrast, the RDBMS architecture can only store predefined fields due to its rigid schema. Thus, undefined fields are omitted. The RDBMS approach merges the data cleaning step with the index construction step, because many-to-many relationships between entities, translated as bridge tables, are indexes as well.
There are no integrity constraints between these collections to improve query response time. Moreover, the structure proposed for the vocabulary facilitates query response time, aggregation and search (Figure  3 ). MapReduce is used to construct all indexes. It is also central in aggregation queries needed by the search algorithms. To improve index construction and query response times, we horizontally scale the database, and by doing so add more MapReduce worker. In the RDBMS architecture, indexes are the bridge tables translating manyto-many relationships between entities. The vocabulary is the bridge table between the documents table and the words table. The PoS index is the bridge table between the vocabulary table and the pos table. In this case, the index also contains the TF and IDF of each term.
Updating indexes in the DODBMS is based on document insertion date. The update method we use constructs an intermediary index for new documents, and then it updates the primary index by appending the new documents' ID and TF to existing labels. Then, the IDF of each term is updated for the whole index. When documents are deleted, we apply a bulk delete operation. In this case, a list of deleted document IDs is stored, which helps update the index structure by removing the deleted documents and then updating the IDF of each term. Updating indexes in the RDBMS implementation is easier thanks to the database's structure. When documents are added, indexes are automatically updated based on the insertion date of the last added documents. When documents are removed, the corresponding index entries are also removed.
News Articles Corpus Experiments The first set of experiments are done using two computers with the same hardware configuration: 4 GB RAM and 1 CPU with two 2. 2 GHz cores. We choose this hardware architecture to show that our method gives good results on simple computers. Using the initial news articles corpus, seven corpora are created consisting of 100 to 110,000 documents. They are referred to as Corpus i, i ∈ {1, 2,. , 7}. For comparison reasons, experiments are done using a single-thread approach. Figure  4a  presents the average time (in seconds) for populating the databases. Duplicate documents are removed in this step. This is done by checking whether an article already exists in the database based on its title. If the document does not exist, then a new record is added. Otherwise, tags are verified so that metadata are not omitted, as the same article could have more tags for different instances found in the corpus.
The second set of tests evaluates the efficiency of text cleaning and index construction (Figure  4b ). Figure  4c  shows the total storage space (in MB) for all corpora. To respect database normalization in PostgreSQL, bridge tables materializing many-tomany relations have to be added. In MongoDB, such relationships translate into vectors or nested documents inside collections. For example, the documents collection contains the authors table as an array of nested documents and the tags table as an array. This brings the issue of duplicates, as we may have the same tags for different document that would be stored in each element of the collection. However, it is a small cost to pay as, using this structure, joins are removed, whereas join is the costliest operation in RDBMSs. Experimental results show that MongoDB efficiently stores the data, minimizing storage space by 30% with respect to PostgreSQL.
Moreover, based on  the number of records in each collection, from a computational point of view, a select operation performed on a smaller entity shows faster response times than one performed on an entity with a lot of records. For example, it is faster to query the vocabulary collection than to interrogate the vocabulary table, because the table contains more records than the collection. Figure  4d  presents the mean time for extracting the top-k documents. Tests are performed on Corpus 7 with k = 20. After each search, the database cache and buffers are cleared so that the comparison is accurate. MongoDB is from 86% faster than PostgreSQL for one term-search to over 50% faster for five terms. Table  1a  presents mean text cleaning and index construction times, as index construction is done separately in MongoDB.
Conclusion In this paper, we present a new, complete architecture for text analysis that improves search performance, minimizes storage cost through efficient documentoriented storage, and scales up horizontally and vertically. Moreover, exploiting MapReduce to parallelize index construction and by designing new structures for indexing and decreasing the number of records stored in the database, we minimize the number of CRUD operations and further enhance performance. Finally, the algorithm we propose for extracting top-k documents for a given search phrase also considerably improves query response time. Our experimental results show that a document-oriented architecture is bestsuited and improves performances when working with large volumes of text when adding documents into the database, cleaning text and constructing indexes.
The General Unified Threshold model of Survival (GUTS) provides a consistent mathematical framework for survival analysis. However, the calibration of GUTS models is computationally challenging. We present a novel algorithm and its fast implementation in our R package, GUTS, that help to overcome these challenges. We show a step-by-step application example consisting of model calibration and uncertainty estimation as well as making probabilistic predictions and validating the model with new data. Using self-defined wrapper functions, we show how to produce informative text printouts and plots without effort, for the inexperienced as well as the advanced user. The complete ready-to-run script is available as supplemental material. We expect that our software facilitates novel re-analysis of existing survival data as well as asking new research questions in a wide range of sciences.
Thus to enable the wider application of GUTS we present the first software package that allows this computationally non-trivial uncertainty quantification to be completed within a matter of minutes. The software is computationally efficient because we developed a novel algorithm, for the likelihood evaluation, and coded the underlying engine in C++. Further, our R package can be used for all three flavours of GUTS: GUTS proper, GUTS-SD and GUTS-IT.
If f θ (z) is the lognormal distribution, we recommend using a log-uniform distribution covering the highest probability region of f θ (z), and replacing the sample by a grid. More precisely, we set z j ¼ e x j , where {x j } describes an equidistant grid on the interval [μ -4σ, μ+4σ], where m ¼ lnðmÞ À 1 2 s 2 ; s 2 ¼ ln 1 þ s 2 m 2 ; ð15Þ with m and s 2 , respectively, the mean and variance of the lognormal distribution. The weights become, up to an irrelevant θ-independent term, lnðf θ ðz j Þ=g θ ðz j ÞÞ ¼ À 1 2 ðm À lnðz j ÞÞ 2 s 2 : ð16Þ Implementation in the R Package GUTS The GUTS algorithm is implemented in the R package GUTS  [29, 30] , current version 1. 0. 0). R  [31]  is an open source software environment for statistical computing that provides a wide range of procedures for data manipulation, data analysis, simulation, modelling and producing graphics.
R packages are extensions contributed by members of the R community to add functionality to the R environment. The R package GUTS is such an extension, and it contains a setup function and functions to calculate the survival probabilities and the associated logarithm of the likelihood, respectively. In order to achieve high speed, the actual engine for the calculation of the survival probabilities and the associated logarithm of the likelihood is written in C++ and exposed to R through the deployment of Rcpp  [32, 33]. The engine cannot be called directly but through the use of two wrapper functions. The function for the calculation of the log-likelihood is typically used in a parameter estimation routine, while the function for the survival probabilities can be used to make predictions. Both functions update the GUTS object directly, but also return the logarithm of the likelihood or the vector of survival probabilities, respectively.
The help file of the package contains a detailed description of the package functions, their arguments and use (R command help("GUTS")). The R package GUTS allows for the realisation of two models, the full model (GUTS Proper) and the individual tolerance model (GUTS-IT). In addition, the stochastic death model (GUTS-SD) can be achieved through the use of the delta distribution with model GUTS Proper. If the thresholds are sampled from the lognormal distribution (the default) and the full model (GUTS Proper, also default) is applied, 5 parameters are required: • hb: background mortality rate For the delta distribution, no standard deviation must be provided, and for the model GUTS-IT, the killing rate must be omitted. The number of parameters is checked according to the distribution and model.
A wrong number of parameters invokes an error. However, improper parameter values (e. g. , negative values) invoke a warning resulting in the vector of parameters and the vector of survival probabilities being set to NA, and the logarithm of the likelihood being set to -Inf. For testing and demonstration purposes, the package also provides a data set, "diazinon". Pulsed toxicity tests with the freshwater crustacean Gammarus pulex and diazinon, an organophosphate insecticide, were carried out to measure survival through time under repeated pulsed exposure with variable recovery phases between pulses. Exposure concentrations were measured frequently and survival was observed daily. The dataset contains the results from three different experiments (exposure scenarios), where each experiment started off with 70 alive individuals.
Practical Application Example A typical application scenario of the R package GUTS comprises creating proper GUTS objects from data, performing the parameter estimation, computing the parameter uncertainty, and making probabilistic predictions as well as validations with new data. We present such a scenario using example data to model GUTS Proper with thresholds from the lognormal distribution. During our presentation we make use of self-defined wrapper functions, which serve to keep the actual workflow clear and simple. A complete ready-to-run script containing a detailed explanation of the code and functions can be found in the supplementary information.
The Ct and yt vectors denote the time points at which these vectors are measured [day]. As our algorithm assumes a linear interpolation between concentrations, the values have been chosen such that pulses of approximately rectangular shape are achieved. Having such a plain text file created in the working directory under the file name, say, Data_Gp_Diazinon. txt, it can then be read in: However, for testing and demonstration purposes, the diazinon data is included in the R package GUTS. We can load this data directly and create a list of 3 GUTS objects: Note, that all other arguments of the setup function (guts_setup()) already default to modelling GUTS-Proper (i. e. , dist = "lognormal", model = "Proper", N = 1000, M = 10000) and are therefore omitted. However, for modelling GUTS-SD, set dist = "delta" and model = "Proper", and for modelling GUTS-IT, set dist = "lognormal" and model = "IT".
The posterior of parameter k k , however, seems to exhibit a fat tail, which occasionally leads to divergent Markov chains. For this parameter, we specify a prior upper bound k k < 30l/(day nmol) that is large enough to be practically indistinguishable from the IT regime k k = 1. The function logposterior() takes a vector of parameters as its only argument. If the parameter vector lies outside the prior range, logposterior() returns -Inf; otherwise it applies a vector-wise calculation of the logarithm of the likelihood to the GUTS objects (sapply()) and returns the sum. To find good starting parameters, we use an R implementation of the "Hooke-Jeeves derivative-free minimisation algorithm". The optimiser hjkb() is included in the package dfoptim  [35]. We then define a start vector as well as its lower and upper bounds needed during the optimisation.
Warnings invoked by the GUTS package functions can be inspected using the command warnings() (for their meaning, see the help file and section Implementation in the R Package GUTS). However, these warnings do not affect the optimisation and can, therefore, be safely ignored. The result of the optimisation routine is inspected using the print function (for an in-depth description of the output consult the manual page of hjkb()): Note that choosing reasonable parameter bounds can hardly be automatised and thus relies on the expert knowledge about common parameters, for the respective types of data and experiment. If expert knowledge suggest different parameters and bounds, the vectors above need to be adjusted  [26]. The posterior parameter distribution is sampled using the robust adaptive Metropolis sampler implemented in the R package adaptMCMC  [36]  with the parameters from the optimisation serving as starting values.
The function MCMC() automatically adapts the covariance of the jump distribution to achieve a user-defined acceptance rate (here: 0. 4). As a starting value, for the covariance of the jump distribution, we simply use a diagonal one with 10% of the initial parameter values as standard deviations. In order to prevent degeneracy of the matrix (in case the optimiser returns zero, for certain parameters), the matrix is altered by adding a small positive number to the diagonal. Note that, although the R package GUTS is very fast, the MCMC may take some minutes depending on the number of iterations chosen (argument n of the function MCMC()) and the hardware used (on our testing MacBook Pro with a 4 core Intel i7 processor 50,000 iterations took about 3 minutes). Like in the optimisation routine, warnings can occur and can be ignored (see above).
Visualisation of the Posterior Distribution After the MCMC has finished without errors, it is necessary to inspect the chains and check whether they have converged. Automatised checks are available (e. g. , through using CODA After cutting off the first 10,000 sample points, the chains show a reasonable mixing and no signs of burn-in or the adaptation phase of the algorithm. We have chosen the function MCMC() from package adaptMCMC because it is largely self-tuning and therefore easy to use. An adaptation phase of 20,000 sample points seems to be sufficient in most cases. Nevertheless, it is important to keep in mind that MCMC() calls a stochastic algorithm, which may fail to adapt, even for the data set we are using. If that happens, running the algorithm a second time usually suffices. If not, the adaptation phase might have to be enlarged and the chain might have to be run for a longer time.
Discussion and Future Directions We discuss the modelling of survival under chemical stress using GUTS  [4]. GUTS places the assumptions underlying survival modelling in a consistent mathematical framework, but the calibration has been a challenge. In particular the calibration of toxicodynamic parameters, and the estimation of parametric and predictive uncertainty was still a problem as it required much computational power and time. GUTS is a survival analysis tool specifically designed to account for time-varying stressors. It is also possible to integrate multiple, independently acting stressors by adding hazard rates  [25, 26]. However, most intriguing are the possibilities to better understand underlying mechanisms my meaningful interpretation of the GUTS parameters. We expect that our software facilitates re-analyses of existing survival data as well as asking new research questions in a wide range of sciences.
ABSTRACT How do people appropriate their virtual hand representation when interacting in virtual environments? In order to answer this question, we conducted an experiment studying the sense of embodiment when interacting with three different virtual hand representations, each one providing a different degree of visual realism but keeping the same control mechanism. The main experimental task was a Pick-and-Place task in which participants had to grasp a virtual cube and place it to an indicated position while avoiding an obstacle (brick, barbed wire or fire). An additional task was considered in which participants had to perform a potentially dangerous operation towards their virtual hand: place their virtual hand close to a virtual spinning saw. Both qualitative measures and questionnaire data were gathered in order to assess the sense of agency and ownership towards each virtual hand.
II. MCTL Predictive Modeling Method Advanced electronic packages are consisted of multiple layers in order to reduce the parasites of the PDN (e. g. , to reduce the inductance of the planes), these layers can be allocated to power and ground in an alternating manner so that multiple plane pairs can exist in a package or board. Fig. 1  shows a typical Power/ Ground planes structure. This structure can be discretized into multilayered squared unit cells. For a good accuracy, the unit cell size must be about twenty times less than the wavelength of the highest frequency of interest, otherwise refection errors may occur. To avoid confusion, there should be no conflict regarding a common global reference terminal for the definition of voltages at the interconnection of the unit cells. The MCTL matrix model overcomes this practical problem by defining multilayered unit cell models that have the same ground reference such that interconnection of the unit cells becomes straightforward.
II. MCTL PREDICTIVE MODELING METHOD Advanced electronic packages are consisted of multiple layers in order to reduce the parasites of the PDN (e. g. , to reduce the inductance of the planes), these layers can be allocated to power and ground in an alternating manner so that multiple plane pairs can exist in a package or board. Fig. 1  shows a typical Power/Ground planes structure. This structure can be discretized into multilayered squared unit cells. For a good accuracy, the unit cell size must be about twenty times less than the wavelength of the highest frequency of interest, otherwise refection errors may occur. To avoid confusion, there should be no conflict regarding a common global reference terminal for the definition of voltages at the interconnection of the unit cells. The MCTL matrix model overcomes this practical problem by defining multilayered unit cell models that have the same ground reference such that interconnection of the unit cells becomes straightforward.
MCTL Matrix Modeling Flow At this stage, it is important to note that our goal from this study is to provide a predictive model for Power/Ground planes without the need of a representative layout. In other words, only some key information about PDN geometry (planes 'length, width, and thickness, port locations, etc. ) and stack-up technology (dielectric constant, loss tangent, etc. ) are needed to construct a MCTL-based grid as described. As a consequence, we can get our package or PCB model as early as the specification phase, thing that other models cannot provide. The modeling flow is described in Fig. 4. Being based on the chip design constraints, we start by fixing the geometrical parameters (length, width, thickness, port locations, number of layers, shape of Power/Ground planes, etc.
) and technological ones (dielectric constant, loss tangent, etc. ). Given the PDN size and with the maximum frequency of interest, we can conclude the size of the unit cell, L u , and then we can deduce the total number of unit cells required to construct the PDN predictive model. The technological parameters of the PDN (conductor and dielectric properties) will determine the substrate to which the unit MCTL will be associated. Once these parameters are fixed, we define a MCTL line with L u as length, associated to the substrate. A W-Element Extraction can be then performed to provide RLGC lossy matrices, but thanks to our approach we can obtain these matrices with simple calculations, which will be developed in the next section. In order to reduce the time for building the equivalent circuit for the entire PDN's Planes, which is time consuming for organizing millions of nodes and elements manually, a software program in Perl was developed to generate the Power/Ground grid model automatically.
The program takes conductor. However, especially when the planes resonate, substantial coupling between the plane layers can occur through the magnetic fields penetrating the solid conductor. As a result, each plane assigns the plane below it as its local reference plane. In other words, considering a current on the bottom of the i th plane, the return path for the same current is considered to exist on the top of the (i+1) th plane below, regardless its nature. This can be proven in Fig. 3  which represents a 3D visualization of forward current on the top layer and the return current on the plane just below. This structure was simulated using FEM EMPro 3D simulator. It is clear that when exciting the top plane, we get nearly the same intensity for the return currents on the plane just below, despite the ground reference was assigned to the bottom plane.