dataesr/scientific-paragraphs-categorization huggingface dataset:
Data processing and analysis. Data Processing and Analysis were performed using MATLAB v. 2021a (The Mathworks Inc. ) with the EEGlab toolbox v. 2022. 0 (https://sccn. ucsd. edu/eeglab/index. php) and JASP v. Table  1. Table with the numbers and the tasks they refer to within the Notebook. The RMSSD is a measure that is often used for shorter time-windows as it reflects beat-to-beat variations while the SDNN is a metric more suited for long-term analysis, reflecting overall cardiac variation  42. Cerebral activity. The EEG data were processed with a usual pre-processing pipeline. Data were first down-sampled to 250 Hz. Next, a 1 Hz high-pass FIR filter was applied. An automatic channel rejection and interpolation, based on a two standard deviation criterion was then used. On average, 0. 34 channels were interpolated per task.
Here the data was first epoched before the pre-processing was applied to each epoch individually. The automatic epoch rejection was therefore not used. For the EEG analysis, the power in the theta (4-8 Hz) and alpha (8-13 Hz) bands were extracted at each electrode of the continuous data using the spectopo EEGLAB function and the absolute mean power was computed for each frequency band. Electrode clusters were selected to calculate the power by brain areas, identical to those of Simon et al. 45. For the frontal area, a cluster of 10 electrodes was averaged: F3, F1, Fz, F2, F4, FC3, FC1, FCz, FC2, FC4; for the central area, 10 electrodes were averaged: C3, C1, Cz, C2, C4, CP3, CP1, CPz, CP2, CP4; and for the parieto-occipital area, a cluster of 11 electrodes was averaged: P3, P1, Pz, P2, P4, PO3, POz, PO4, O1, Oz, O2.
For all analyses, a Greenhouse-Geisser correction was applied when the assumption of sphericity was violated. Cardiac data was analyzed using a GLM (Fixed factors: Session x Condition, TOT as a covariate) on the dependent variables of HRV (SDNN or RMSS) and HR (BPM). For the EEG analysis, the data were analyzed according to the difficulty of the task (Easy; Medium; Difficult), the cortical area (frontal and posterior) and the theta and alpha bands. A GLM (Fixed factors: Session x Difficulty) was performed on each ROI (frontal, central and posterior). N-Back task. A 3 × 3 × 3 RMANOVA (Session x Condition x Block) was performed on participants' error rates. A Greenhouse-Geisser correction was applied when the assumption of sphericity was violated. For reaction times, using the same factors the data was analyzed using a GLM (dependent variable: reaction time).
Cardiac data were analyzed in a similar way as was the cardiac data of the MATB task. A GLM (Fixed factors: Session x Condition x Block) on the dependent variables of HRV (SDNN or RMSS) and HR (BPM) was performed. Here Block was added as an additional factor. The EEG data were analyzed according to the difficulty (Easy; Medium; Difficult) of the N-back task, with a GLM (fixed factors: Session x Difficulty) on each ROI (frontal, central and posterior), and for both the alpha and theta band respectively. Flanker task. The behavioral results of the Flanker task were analyzed using GLMs and RMANOVAs. The first analysis (GLM) focused on reaction times as a dependent variable with congruency (congruent vs incongruent trial), session (1, 2 or 3) and response accuracy (error vs correct response) as fixed factors.
Then the average around this point was computed (±2 points for a 5-point average). To analyze the results a GLM with the Fixed factors of congruency, correctness, and the session was performed on the dependent variables of peak amplitudes of the P300, FRN and ERN components. Mental workload estimation. Mental Workload estimation was performed on both the N-Back and the MATB tasks, with three different mental workload levels each (0-back, 1-back, 2-back; and MATB Easy, MATB Medium, MATB Difficult). For both tasks, the same preprocessing, feature extraction and classification pipeline was used. To preprocess the data, the following steps were executed: First, 5-second non-overlapping epochs were created from the continuous data, which were then downsampled to 250 Hz. Next, FIR filters (eegfiltnew function from EEGLAB with default parameters) were applied to filter the data either in the theta or the alpha band (i.
To classify the data, the covariance matrix of a subset of 10 channels (F3, Fz, F4, FCz, C3, C4, CPz, P3, Pz, P4) was calculated for each epoch. The data were then divided into training and testing sets using a 5-fold cross-validation procedure. The data were trained and tested on a Riemannian Minimum Distance to Mean  (MDM) classifier  49, 50. Based on at least 60 trials in each of the 3 classes, the upper limit for the 33% chance level is 41. 7%  51. Accuracy was then evaluated using a RMANOVA with the factors of session (1 vs. 2 vs. 3), difficulty, and bandwidth (theta vs. alpha). Validation results. Here, we present the results obtained for each task independently, as well as the results for mental workload classification. RSME, as well as KSS scores, did not significantly change across sessions.
Conclusion of the dataset validation. In order to validate the acquired dataset, the tasks performed were assessed regarding their capability to elicit the well-known and expected effects on cognition. This validation occurred at three levels. Subjective levels of mental workload and vigilance decrement were assessed by the KSS and RSME subjective scales  28, 29. Behavioral performance for each task was obtained in the form of accuracies and reaction times. Physiological changes were assessed using cardiac (ECG) and cerebral (EEG) activity measurements. Regarding the Psychomotor Vigilance Task, it was expected that over its 10-minute duration the vigilance of participants would decrease  21, 32. This was shown as reflected by the increase in reaction times as well as the Fig. 25 Exemplary folder tree of the data in the BIDS structure.
The behavioral results show a decrease in accuracy as well as an increase in reaction times for incongruent trials, as compared to congruent trials  47, 55. Furthermore, it was shown that errors resulted in significantly longer reaction times. The difference between erroneous and correct trials was also significant at the physiological level, as represented by the sensitivity of the ERN, FRN, and P300 components to errors sessions and congruency. In addition to these measures of validation, the collected data was also tested in its ability to be used for mental workload estimation. On both the MATB and the N-Back task, an MDM Riemannian classifier was used to classify epochs of EEG data between three levels of mental workload. The obtained average accuracy of over 65% in this 3-class problem (more than 20% above the upper limit of a 95% CI for chance level) confirms that the COG-BCI database 18 may be of use for developing and testing classification pipelines.
A higher accuracy was reached on the MATB-II data, which may be the result of an increased activity of the sensory-motor areas depending on task difficulty. In the N-back task, it is expected, that all conditions result in the same amount of motor activity. Overall, the results presented here show that the COG-BCI database  18  is a useful asset for testing novel methods within passive BCI research or related fields. It should be noted that the analysis presented here does not in any form present an exhaustive analysis of all effects that may be present within the data as well as of all pipelines that may be designed to estimate users' cognitive state. The goal of the analyses performed here was to validate.
Usage Notes The behavioral output of the N-Back, Flanker and PVT tasks is saved in Tables. The behavioral output of the MATB is saved in a MATLAB structure, with individual substructures for each of the tasks. • TRACK: 2 columns with the X and Y coordinates of the tracking tasks (2 Hz sampling rate). • SYSMON: 2 columns referring to the onset of a specific alarm (column 1) and reaction time (column 2). • RESMAN: 2 columns with the amount of fuel in the relevant reservoirs (1 Hz sampling rate). • COMM: A table with 5 categories: • Target: Was the radio message a target (1 = yes) • TargetRadio: Which radio needed to be changed (1-4) • TargetFrequency: What was the target frequency • Reacted: Did the participant react to the radio message and change some radio frequency (1 = yes) • Correct Was the change in the radio frequency correct (1 = yes).
The colored circles shows the templates that detected during this study, colored with their number of detections. KKN and GKN of 6. 8s, identically to the Gorkha earthquake, suggesting that this foreshock happened at close distance from the epicentre (Fig. S1 ). We search more systematically for micro-seismic events near the hypocenter of the Gorkha earthquake using the template matching code Obspy (obspy. signal. cross correlation). We use about 1800 templates, occurring between December 2013 and May 2016 (grey circles in Fig. 1B ). We use the continuous signal from 2009 to the Gorkha earthquake to compute the correlation between templates and continuous signals in a frequency band of 2-15Hz, taking an 8-second window starting 1 second before the P-wave arrival time. We choose a correlation coefficient threshold of 0.
Acknowledgments. We acknowledge the cooperation of the  Department of Mines and Geology (DMG) -Nepal  and  CEA/DASE France  in the maintenance of the seismological stations used in this study. We are grateful to the team of analysts at  NEMRC/DMG , and to Section Chief  Bharat Koirala , for their involvement in the processing of the seismicity catalogue. This study was initiated during  Lok Bijaya Adhikari 's doctoral thesis on the aftershocks of the Gorkha earthquake. Funding: BG postdoctoral fellowship was supported by the  LRC Yves Rocard  ( Laboratoire de Recherche Conventionné CEA-ENS-CNRS). Author contributions: BG conceived the study. All authors participated to the writing of the manuscript.
SODES also deals with two generic programs which determine the type or types of a given ODE and provides the solution. In this paper we will also introduce a draft of a Graphical User Interface (GUI) for SODES in a local web application using programming in Python (using its CAS module SymPy) which is a more portable and free CAS. This draft can be used in English, French and Spanish, and can be easily extended to other languages. The code of SODES and the GUI are freely available so that it can be used by users who also will be able to adapt it to their needs.
Furthermore, with the stepwise option, SODES can be used as a self tutorial for researchers and students. SODES has been developed using a CAS, specifically Derive  [1]. A CAS is a mathematical software with two important differences from other mathematical software: 1. It deals with exact computations not with approximations. For example, the result of ∑ ∞ n=1 1 n 2 using a CAS would be π 2 6 , while using other mathematical software, an approximation of π 2 6 , would be provided. 2. A CAS can handle algebraic expressions without the need of instantiating the values of the parameters involved. For example, the expanded result of (abc) 4 using a CAS is a 4 -4a 3 bc + 6a 2 b 2 c 2 -4ab 3 c 3 + b 4 c 4 , while using other mathematical software the values of a, b and c should be provided in order to get the final result.
These two features of CAS allow us to deal with generic parameters and with exact computations which will lead to a more widely use of the developed solver SODES. In addition, using a CAS to develop SODES, we have been able to program the intermediate steps and add any text information on each step. This fact facilitates the use of SODES as a Pedagogical CAS (PeCAS  [2] ) since the solution can be obtained step by step and with information along all the process to reach the final result. We have chosen the CAS Derive to develop SODES. The CAS to use is very important for SODES since not all CAS can deal with the needed computations. Specifically, we need, among others, to deal with these very important two topics that not all CAS support: 1. Since all ODE need to compute integrals symbolically in the process of resolutions, we need to use a CAS which supports computing primitives of functions symbolically and not with approximations (as a numerical software would do).
• In addition, Derive is the CAS that the authors of this paper use in the computer lectures with engineering students because of its flexible syntax, which makes it easy for beginner students. The authors are experts in Derive in the development of new libraries to increase the capabilities of the CAS and in the development of applications to different fields in Engineering, Science and Education. In addition, the authors have also develop different applications using other CAS, such as Maple  [8] , Maxima  [9]  or CoCoA  [10, 11]  in combination with the development of Graphical User Interfaces (GUI) to display the results of the applications. The GUIs were developed using the programming language Java  [12]  or Php + Html [13] so that the applications can be run in different platforms. The previous works developed by the authors can be grouped in two different fields: 1.
Development of new libraries to improve the capabilities of the CAS. 2. Development of applications and GUIs to display the results. The work developed in this paper, the introduction of the new solver SODES, can be classified in both fields since it is a new library which provides stepwise solutions of different types of ODEs, increasing this way the capabilities of the CAS Derive, and a GUI is being developed to ease the user to work with SODES. This prototype of GUI works locally in a web browser and it is described in Section 4. It is important to remark that most of the previous developed works can be easily adapted to be used in different CAS, since in all cases we provide the code for the specific library or application developed. In addition, as we will remark in the future work Section 5, we are migrating the different libraries and applications using the programming language Python  [14, 15]  using its CAS library SymPy  [16, 17]  which will provide more portable applications since Python is a multi-platform programming language.
Applications combining CAS and GUI • In  [18]  we introduced for the first time the combination of using programming with a CAS (specifically, Derive) and the development of a GUI (using Java). In this work we provide a counterpoint for a given melody (cantus firmus) introduced by the user in a virtual keyboard using the GUI. • In  [19]  we developed the GRAM model to help in the control of traffic in a motorway. The model was implemented using the CAS Derive and a GUI developed in the program language Java, which shows graphically the accelerated-time simulations of the movement of vehicles in a motorway. • In  [20]  we introduced the model ATISMART, an accelerated-time simulator for traffic control in a smart city. ATISMART was developed using the CAS Maxima together with a GUI in Java. In  [21]  we introduced the improved model ATISMART + (also using Maxima + Java) including a new probabilistic extension of Dijkstra's algorithm, which provides more realistic simulations for traffic control in smart cities.
Online applications There are lots of online applications which deals with solving some ODE. The following is not an exhaustive list but a list of the most popular and most used ones: • WolframAlpha  [30]  which uses Wolfram Language  [31]  built initially for the CAS Mathematica  [32]. This is a very complete online site for different mathematics topics but for advanced uses and stepwise solutions requires the non-free pro version. • MapleCloud  [33]  is the online version of part of the CAS Maple  [8]. It does not provide stepwise solutions. • Symbolab  [34]  is also another interesting website which deals with different mathematics topics but it requires a non-free pro version for advanced and stepwise solutions. • MathDF  [35]  provides stepwise solutions for the different types of ODE that it can handle.
Free CAS Maxima  [9]  and SageMath  [43]  are probably the most widely used free CAS in Mathematics. The increasing use of Python  [15]  and its powerful CAS library Sympy  [17]  makes this combination be one of the best free option used nowadays. Even more, other applications are extending their capabilities by allowing using programming in Python in their systems. • Maxima deals with ordinary differential equations but it does not provide stepwise solutions. A tutorial on how to solve ODE can be found at  [44]  • The topics that the CAS library Sympy of Python can handle are continuously increasing. Specifically, it has a very important module for solving ODE. Its description and examples of use can be found at  [45]. It does not provide stepwise solutions. • SageMath also can solve differential equations but it uses the programs from Maxima.
Prototype of GUI for SODES In order to make SODES more portable and usable, we have developed a prototype of this new stepwise solver in Python  [14, 15] , a more portable and free programming language, using its CAS package Sympy  [16, 17]  and Html. Furthermore, we have developed a prototype of GUI to deal with the solver using a web browser locally. This prototype deals with the first order ODE considered in SODES and will be extended in future to deal with higher order linear equations with constant coefficients and Cauchy problems so that it will deal with all types included in SODES.
The code of all programs in SODES can freely available at http://u. uma. es/c4U/SODES/ where two different files can be downloaded:  1. SODES. mth which is a library with all the programs of SODES. Using this file, we increase the capabilities of the CAS Derive which was one of the main goals of the paper. In addition, since the code is freely available, the user can migrate SODES to any other CAS increasing this way the capabilities of the CAS. 2. SODES. dfw which is a tutorial of SODES with examples developed step by step. This can be used in the teaching and learning process of ODE which is a very important topic in advanced subjects aim to Math, Engineering and other Sciences students. Therefore, we achieve the other main goal of the paper: we provide an important tool for education. Note that users can adapt the code in order to get the stepwise solutions according with their expectations.
Future work The future work related with this paper can be enumerated in the following lines of continuation: 1. We will consider more types of ODE to include in SODES. 2. We will extend the prototype of GUI to these new types of SODES and will add more languages to the local GUI. 3. We will develop other stepwise solvers to deal with other mathematical topics as Complex analysis, Random variable generation and Automatic theorem provers. 4. In the long term, we will develop an online stepwise powerful math calculator considering the previously developed solvers for Partial differential equations (SFOPDES  [29] ), Multiple integration (SMIS  [28] ), Improper integrals computations  [5, 27]  together with the present work introduced in this paper: SODES. The calculator will be freely available online and will deal with different languages.
Experiments We compare the memory peaks obtained with previously known results. Our experimental setup is a regular laptop (In-tel® Core™ i5-8265U @1. 60GHz processor, 16 GB of RAM), with Linux Ubuntu 22. 04. We use Python 3. 10 with the graph library Networkx 2. 8. 8. Our implementation is available online 1. All the results presented here assume the PBC model. Concerning task graphs, most existing work focus on treeshaped graphs or SP-DAGs but do not provide benchmarks. 1 https://gitlab. inria. fr/spades-pub/mastag For such graphs, we always find the optimal memory peak very quickly, even for very large ones. 1  presents the results for satellite, one of the first SDF applications used to analyze the memory peak. We handle it as a task graph with 22 nodes (by analyzing only its flat SAS schedules), and as an SDF graph that is converted into a task graph with 4, 515 nodes.
Implementation and Further Examples We have implemented the algorithm described in this article (up to minor variations) using the SageMath computer algebra system. Our implementation is part of the ore algebra package  [31] , available at https://github. com/mkauers/ore_algebra/ under the GNU General Public License. The version described here corresponds to git revision 47e05a45  6. The examples were run under SageMath 9. 7. beta2  7. The documentation and test suite of ore algebra contain executable versions of all examples from this paper, sometimes with minor changes. The implementation builds on pre-existing code in ore algebra for computing the connection matrices of Definition 2. 10 (see  [37] ) and for computing bounds on tails of logarithmic series solutions of D-finite equations, as in Proposition 5.
1 (see  [38] ). Except for singularities and local exponents, which are algebraic numbers and are represented exactly, numeric coefficients are represented as elements of SageMath's ComplexBallField, based on the Arb library  [26]. We perform intermediate computations that lead to the coefficients of the output at a working precision selected by the user, with the occasional addition of some guard digits for steps where we expect a loss of accuracy, but do not attempt to provide any guarantees on the radius of the output intervals. For operations that only affect the error terms, we currently use a fixed, hardcoded working precision. Our code also relies on Sage-Math's AsymptoticRing  [18]  to represent the asymptotic expansion it outputs. The implemented algorithm deviates from the one described here in some minor ways.
• Sampling. Party 𝑃 1 privately draws using Protocol 2 a random number 𝑟 ′ distributed uniformly in [𝑀]. Then, 𝑃 1 sets 𝑟 = 𝐹 -1 D 2𝑟 ′ -1 2𝑀 , publishes commitments to 𝑟 ′ and 𝑟 , and publishes a ZKP that (𝑟 ′ , 𝑟 ) ∈ DB. In Protocol 5 a zero knowledge set membership proof is needed. There is a large body of work on this topic since in  [15]  the first method was shown that has a large preprocessing cost (linear in 𝑀) but only a unit communication cost for proving membership. Several improvements have been proposed which vary in their assumptions and efficiency,  [7]  discusses some lines of recent work. Only already storing the database DB may take a prohibitive amount of space if a high precision is needed, as 𝑀 is exponential in the number of desired correct digits. As a result, this technique can only be used when the needed precision is not too high.
For illustration, if we implement Pedersen commitments using the secp256k1 1 elliptic curve, we obtain 128 bit security and an element of G can be represented with 257 bits. One GEX using this 1 See https://www. secg. org/SEC2-Ver-1. 0. pdf and https://github. com/bitcoin-core/ secp256k1  curve takes no more than 30 microseconds on an Intel Core i7-6600U at 2. 60 GHz CPU. With BM, PolM and InvM-R, a sample with MSE < 2 -20 requires less than 900 Bytes of communication. With PolM, such sample takes less than 360 milliseconds (ms) to prove and 75 ms for its verification. While CLT quickly gets very expensive, if quality is less important and an MSE > 2 -13 is satisfactory, it is the most efficient approach. A proof of a sample using CLT with MSE 0. 01 can be generated in less than 10 ms, verified in 3 ms and has a size of 482 Bytes.