dataesr/scientific-paragraphs-categorization huggingface dataset:
Data Description We compiled multiple datasets using information extracted from the 33 meta-analyses, which were identified through a systematic literature review. Our database consists of three datasets ( Fig. 1  ): one containing general information (Dataset 1), one containing the effect sizes of biodi- versity (Dataset 2) and another one containing the effect sizes of yield (Dataset 3). The database has two accompanying tables: a list of primary studies (n = 1,967), including also the country of each study and a table with the quality assessment of each meta-analysis.
General information table Dataset 1 consists of general information regarding the meta-analyses. Each row represents one meta-analysis and the columns correspond to metadata, described in Table  1. Notably, 8 meta-analyses found publication bias in their data overall or at least in one subgroup, whereas 14 studies did not mention a test for publication bias. The number of primary studies ranged from 26 to 328, while, although we did not set any filter related to time, the publication year of the meta-analyses ranged from 2011 to 2022. Most meta-analyses (n = 22) were global and 2 were focusing on Africa, 5 in China, 3 in Europe, 1 in North America and 1 meta-analysis was specific in Brazil. Regarding the organismal groups, 19 meta-analyses were considering all organismal groups, 7 were about plants and pollinators, microbes, herbivores, fungi, earthworms, biocontrol species and bacteria were the main study groups in 1 meta-analysis each.
The meta-analyses included in our dataset used different effect size metrics to answer the question of how a particular management practice affects biodiversity and yield. The effect size metrics present in our database are:  We created one dataset for biodiversity and another one for yield, in order to facilitate interoperability and achieve a more flexible format. The two datasets can be merged, depending on the research question, by joining them based on the columns they have in common. (i) Standardized mean difference, N = 1 study [1] (ii) (Log) response ratio (weighted or unweighted), N = 21 studies [2-22] A comprehensive visualization of the effect sizes included in both datasets is given in Fig. 2  , categorized by effect size metric and management practice. We separated the effect size by metric because each metric has a different numeric range (hence the differences in the y axes).
Biodiversity dataset Dataset 2 consists of the meta-analytic estimates of the impact of management practices on various biodiversity measures (species richness, Shannon index etc. ). Each row is one estimate and refers to either the overall meta-analytic mean or a subgroup estimate. If the value refers to a specific taxonomic group, the name of the subgroup is indicated in the column "Taxonomic group". The column names and all abbreviations included in Dataset 2 ("biodiv_data_OSF. csv") are described below. • "ES_ID" is a unique identifier of each effect size. • "StudyID" is a unique identifier of each meta-analysis. • "Title", "Authors", "Year", "DOI" are the publication information of each meta-analysis. • "Biodiv_ES" is the value of the effect size. • "Biodiv_ESMetric" is the effect size metric: Hedges' D (HedgesD), Hedges' G (HedgesG), Cohens' D (CohensD), Response ratio (RR), Log response ratio (LRR), Standardized mean difference (StdMeanDiff), Percentage change.
Yield dataset Dataset 3 consists of the meta-analytic estimates of the impact of management practices on various yield measures (yield, biomass etc. ). Each row is one estimate and refers to either the overall meta-analytic mean or a subgroup estimate (name of subgroup is indicated in the column "Subgroup"). The column names and all abbreviations included in Dataset 3 ("yield_data_OSF. csv") are described below. • "ES_ID" is a unique identifier of each effect size. • "StudyID" is a unique identifier of each meta-analysis. • "Title", "Authors", "Year", "DOI" are the publication information of each meta-analysis. • "Prod_ES" is the value of the effect size. • "Prod_ESMetric" is the effect size metric: Hedges' D (HedgesD), weighted Hedges' D (HedgesD ++ ), Hedges' G (HedgesG), Cohens' D (CohensD), Response ratio (RR), weighted response ratio (RR ++ ), Log response ratio (LRR), Standardized mean difference (StdMean-Diff), Percentage change.
• "SE" is the standard error. • "SD" is the standard deviation. • "ConfidenceInterval" is the type of confidence interval (90 % or 95 %). • "Notes" is a column containing notes related to each effect size. Interestingly, two meta-analyses used the 90 % benchmark instead of 95 % for the confidence intervals of the effect sizes. In total, we extracted 205 estimates from the 33 meta-analyses. The data represent the responses of 30 crop types to 8 management practices over a period of 11 years ( Fig. 3  ).
Primary studies The empirical (observational or experimental) papers that are used in a meta-analysis are called primary studies. We compiled a list of all the primary studies that were used in 19 randomly selected studies out of the 33 meta-analyses in our database. From this list, we manually extracted the country (or countries) in which each primary study took place. The final table comprised of 1,967 unique primary studies, that took place in more than 100 countries ( Fig. 4  ), over multiple decades ( Fig. 5  ).
Description of meta-analyses included in the database All the meta-analyses in our database were designed by their authors in order to answer the same type of question: "What is the impact of management practice X on (among others) biodiversity and yield?". Therefore, each meta-analysis includes empirical studies that measure yield and/or biodiversity. At the analysis stage, authors would create subsets for each response variable; one subset for yield and one for biodiversity. These subsets would be then fitted in separate meta-analytic models and meta-regressions (where necessary) with different moderators. The model estimates would be then reported separately for each response variable. Our database consists of those model estimates. In most cases, meta-analyses provided more effect sizes for biodiversity and less for yield, hence we kept the two datasets separate.
Data collection and quality assessment Aiming to identify all relevant meta-analyses to build our database, we conducted a systematic literature review according to the PRISMA 2020 guidelines  [34]. We used three data sources: i) Web of Science, ii) two second order meta-analyses  [ 35 , 36 ]  and iii) a database provided by JB  [37]. We screened 1,086 titles and abstracts based on the inclusion criteria: i) the study should be a meta-analysis ii) the response variables of the meta-analytic models should be biodiversity and yield iii) the meta-analysis should examine the impact of some agricultural management practice on biodiversity and yield. The same inclusion criteria were used for the full-text screening of 220 publications. After the full-text screening stage, we identified 33 meta-analyses that met the inclusion criteria ( Fig.
6  ). We extracted all effect sizes, effect size metrics, sample sizes, error measures, response variable measures, management practices and study metadata. An ef- fect size is here defined as the meta-analytic model estimate of the effect of a management practice on biodiversity or yield. In 17 cases, we extracted the effect sizes from figures and plots, using the R package metaDigitise and the application shinyDigitise  [38]  , as well as the online tool WebPlotDigitizer  [39]. In the cases where a confidence interval was not provided in the text or in a table, we extracted the standard error from figures using the tools mentioned above and then converted it to a 95 % confidence interval using a customized function, provided in the R script that is located in the OSF folder. We used R software  [40]  (version 4.
3. 0) for all figures and plots shown here (ggplot2 3. 4. 2  [41]  , dplyr 1. 1. 2  [42]. During data extraction, we aggregated raw data in meaningful categories. For example, we aggregated the management practices in 14 levels. Organismal groups were aggregated at the level of taxon. In addition, we compiled all the primary studies from each meta-analysis, wherever possible. We manually extracted the location of each primary study took place, by reading the title, the abstract or the full-text. We evaluated the quality of each meta-analysis in our database using an assessment tool that is specific to meta-analyses in agronomy (  [43]  , as implemented in  [44]  ). This tool includes multiple criteria relative to the methodology of meta-analyses ( Fig. 7  ). After reading each full text, we indicated in the table "quality_assessment_OSF.
2023 The Authors. Published by Elsevier Inc. This is an open access article under the CC BY license ( http://creativecommons. org/licenses/by/4. 0/ ) Specifications Table Subject Agricultural Sciences / Agronomy and Crop Science Specific subject area Synthesis of evidence and spatial information to explore the impact of various agricultural measures. Data format Raw Type of data Table Data collection Data were collected through a systematic literature review. We screened titles and abstracts from different sources. The database consists of the effect sizes and relevant information of these meta-analyses. Data source location Global Data accessibility Repository name: Open Science Framework Direct URL to data: https://osf. io/7s9r4/.
• GoLive (https://nsidc. org/data/golive, accessed on 1 March 2023), or the Global Land Ice Velocity Extraction from Landsat (GoLIVE) project, was created by the National Snow and Ice Data Center thanks to NASA funding. GoLIVE is a processing and staging system for near-real-time global ice velocity data derived from Landsat 8 panchromatic imagery applied to image pairs covering all glaciers > 5 km 2 and both ice sheets. • ITS_LIVE (https://its-live. jpl. nasa. gov/, accessed on 1 March 2023), or the Intermission Time Series of Land Ice Velocity and Elevation (ITS_LIVE) project, part of NASA's MEaSUREs program, provides measurements of glacier and ice sheet surface velocity and elevation change at a high temporal resolution. The ITS_LIVE data product is a set of regional compilations of annual mean surface velocities for major glacier-covered regions, spanning the time period from 1985 to 2018, subject to image availability and quality, with a spatial resolution varying between 120 m × 120 m and 240 m × 240 m.
• The data set "glacier surface velocities derived from Sentinel-1"  [13]  contains glacier surface velocity data for 12 glacierized regions on Earth, including the European Alps. Sentinel-1 radar data acquired within a time interval ranging from 6 to 48 days have been processed over the period January 2015 to January 2021. The velocity product is available at a 200 m × 200 m spatial resolution. Regarding these products, the main weaknesses and gaps are as follows: (i) GoLIVE covers only those glaciers > 5 km 2 and has a low resolution (300 m). Only pairs of images with 16-day time intervals are treated, which is not appropriate for mountain glaciers  [10, 14] ; (ii) ITS_LIVE does not cover the Alps; (iii) the product derived by Dehecq et al. [12]  covers only the 2013-2015 period; and (iv) Sentinel-1-derived product, by  [13] , is limited for mountain glaciers owing to its coarse spatial resolution and because comprehensive velocity mapping can be hard to achieve for slow-moving glaciers such as in the Alps when using a short temporal cycle (i.
Data Format and Content The data presented in this manuscript are stored and shared in two different form netCDF (network common data form) and geoTIFF. The netCDF format consists, o one hand, of a set of software libraries and, on the other hand, of a "self-documen data format, independent of the hardware architecture, which allows the creation, a and sharing of scientific data stored in the form of tables. We follow the CF (climate forecast) metadata conventions, which have been designed to promote the processing For the quantification of the glacier surface flow velocity, Level 1C top of atmosphere reflectance data from Sentinel-2 A and B, with cloud cover lower than 80% have been used as input data. The Sentinel-2 satellite coverage encompasses 18 tiles over the European Alps (according to the UTM tiling grid proposed by ESA, Figure  1 ).
Data Format and Content The data presented in this manuscript are stored and shared in two different formats: netCDF (network common data form) and geoTIFF. The netCDF format consists, on the one hand, of a set of software libraries and, on the other hand, of a "self-documented" data format, independent of the hardware architecture, which allows the creation, access and sharing of scientific data stored in the form of tables. We follow the CF (climate and forecast) metadata conventions, which have been designed to promote the processing and sharing of files created with the netCDF API. The conventions define metadata that provide a definitive description of what the data in each variable represent and the spatial and temporal properties of the data. In the single netCDF file gathering all the glacier surface flow velocity products, the following architecture can be found:.
Methods The overall workflow for data processing is shown in Figure  9. It consists of four modules: (1) database creation and image preparation; (2) glacier surface displacement calculation; (3) data calibration and geodatabase creation; and (4) postprocessing with data filtering and averaging to obtain glacier surface velocity maps. All codes are written entirely in open-source programming languages: Python 3. 7 and Fortran. The processing chain is designed for massively parallel processing with SQL (structured query language). A full description of the first three steps can be found in Millan et al. [10] ; the last step is described in Mouginot et al. [14]. Hereafter, we provide only a synthesized description.
Methods The overall workflow for data processing is shown in Figure  9. It consists of four modules: (1) database creation and image preparation; (2) glacier surface displacement calculation; (3) data calibration and geodatabase creation; and (4) postprocessing with data filtering and averaging to obtain glacier surface velocity maps. All codes are written entirely in open-source programming languages: Python 3. 7 and Fortran. The processing chain is designed for massively parallel processing with SQL (structured query language). A full description of the first three steps can be found in Millan et al. [10] ; the last step is described in Mouginot et al. [14]. Hereafter, we provide only a synthesized description. All codes are written entirely in open-source programming languages: Python 3.
Step 1a: Database Initialization and Image Search First, a shapefile with the outline of the study region is generated from the European Alps glacier inventory  [25]. The perimeter includes both glaciers and stable ground off glaciers for calibration, but their extents are limited to reduce the computation time. An SQL-MariaDB database is initialized in which a list of all existing images and associated metadata is stored for the studied region. Existing Sentinel-2 images are searched by using the API from ESA and Google. When the images are paired to map the displacement, another database is initialized. This second SQL-MariaDB database is fully integrated into the rest of the workflow and used to monitor and update the status of the processing step for each individual image pair. The use of an SQL-MariaDB database to update the processing steps allows the massively processing of image pairs in parallel, hence taking advantage of the full capacity of the HPC infrastructure.
Step 2: Glacier Surface Displacement The workflow of the image correlation step used to derive the glacier surface displacement is detailed in Figure  11. We modified the algorithm ampcor, which was part of the Repeated Orbit Interferometry Package (ROI-PAC)  [29]. Our workflow uses the core of the cross-correlation algorithm written in Fortran-90. This algorithm is integrated into a Python environment to maintain both efficiency and flexibility with the rest of the workflow. The Python environment extracts the windows from the reference and secondary images and calls ampcor using the interface numpy. f2py. The Fortran-90 code of ampcor calculates a standardized cross-correlation map between the reference image window and the secondary image window. From this correlation map, a peak correlation value is determined.
The two image windows are deramped and oversampled by a factor of two by using a 2D fast Fourier transform. The correlation procedure is then repeated around the previously determined peak value. The resulting new correlation map is itself oversampled by a factor of two, and the location of the correlation peak is then determined. Finally, the outputs are returned to the Python procedure. the Repeated Orbit Interferometry Package (ROI-PAC)  [29]. Our workflow uses the core of the cross-correlation algorithm written in Fortran-90. This algorithm is integrated into a Python environment to maintain both efficiency and flexibility with the rest of the workflow. The Python environment extracts the windows from the reference and secondary images and calls ampcor using the interface numpy. f2py. The Fortran-90 code of ampcor calculates a standardized cross-correlation map between the reference image window and the secondary image window.
From this correlation map, a peak correlation value is determined. The two image windows are deramped and oversampled by a factor of two by using a 2D fast Fourier transform. The correlation procedure is then repeated around the previously determined peak value. The resulting new correlation map is itself oversampled by a factor of two, and the location of the correlation peak is then determined. Finally, the outputs are returned to the Python procedure. Thanks to the Python environment, new features can now be more easily implemented and added compared with using a Fortran-only code, such as the ability to restart a process in the event of a crash, the use of a mask to determine where to calculate the correlation or an initially guessed displacement map to guide cross correlation in a fastmoving region, thus reducing calculation time and avoiding correlation errors that are due to long-distance travel.
Because the window size is larger than the sampling resolution, each point on the offset map may not be completely independent of its direct neighbors. However, this approach provides better results than what the interpolation of a coarser grid at a resolution of 50 m could provide. The size of the windows is appropriate for monitoring mountain Thanks to the Python environment, new features can now be more easily implemented and added compared with using a Fortran-only code, such as the ability to restart a process in the event of a crash, the use of a mask to determine where to calculate the correlation or an initially guessed displacement map to guide cross correlation in a fast-moving region, thus reducing calculation time and avoiding correlation errors that are due to long-distance travel.
Step 3b: netCDF Geocubes Database To facilitate postprocessing, our region of interest is divided into areas of equal size, specifically 10 km × 10 km, with a resolution of 50 m (or 250 × 250 pixels). For each area, we extract and stack the velocity maps and associated metadata into "cubes" whose dimension z therefore corresponds to the number of calculated glacier surface flow velocity maps (Figures  12  and 13 ). The cubes overlap by 5 pixels, or 0. 25 km, to avoid edge problems during postprocessing. This standardized data set where all maps are stored on a common grid can be easily used to extract time series of the surface flow velocity or calculate timeaveraged maps. The cubes are stored in the GDAL-compatible netCDF format following the CF metadata conventions to allow for greater portability and facilitate distribution in the community.
Step 3b: netCDF Geocubes Database To facilitate postprocessing, our region of interest is divided into areas of equal size, specifically 10 km × 10 km, with a resolution of 50 m (or 250 × 250 pixels). For each area, we extract and stack the velocity maps and associated metadata into "cubes" whose dimension z therefore corresponds to the number of calculated glacier surface flow velocity maps (Figures  12  and 13 ). The cubes overlap by 5 pixels, or 0. 25 km, to avoid edge problems during postprocessing. This standardized data set where all maps are stored on a common grid can be easily used to extract time series of the surface flow velocity or calculate time-averaged maps. The cubes are stored in the GDAL-compatible netCDF format following the CF metadata conventions to allow for greater portability and facilitate distribution in the community.
Acknowledgments: In situ measurements of glacier surface flow velocity used to validate the satellitederived products were provided by the  French Service National d'Observation GLACIOCLIM  (https://glacioclim. osug. fr/, Univ. Grenoble Alpes-OSUG, CNRS-INSU, IRD, IPEV, INRAe). We are grateful to  Steven Plummer  ( ESA ESRIN , technical officer of the " Glacier Science in the Alps " project) and  Frank Paul  for fruitful discussions and comments on the manuscript. We thank the  OSUG-Data Center (V. Chaffard ,  C. Coussot ,  J. Schaeffer ,  B. Boutherin  and  F. Malbet)  for its support in the distribution of the glacier surface flow velocity product.
Funding: This research was funded by the  European Space Agency (ESA) , specifically its " Glacier Science in the Alps " project, coordinated by  Frank Paul  ( University of Zurich ), contract no. 4000133436/ 20/I-NB. This work has also been supported by a grant from  LabEx OSUG@2020  ( Investissements d'Avenir- ANR10 LABX56 ) and the programs MaISON (funded by the  French space agency: CNES) and SOSice  (funded by the  French research agency :  ANR-19-CE01-0011-01 ). Institutional Review Board Statement: Not applicable. Informed Consent Statement: Not applicable.
We implement the Quanvolutional Neural Networks (QNNs) on a quantum computer to recognize handwritten digits, and compare its performance to that of its classical counterpart, the Convolutional Neural Networks (CNNs). Additionally, we implement the QSVM on the breast cancer dataset and compare it to the classical SVM. Finally, we implement the Variational Quantum Classifier (VQC) and many classical classifiers on the Iris dataset to compare their accuracies.
As a result, quantum computers can handle and process large matrices, as well as accelerate various linear algebra operations, significantly improving traditional machine learning applications. Theoretically, it should solve problems that belong to classes of complexity that traditional computers, even large giant supercomputers, will never be able to solve. Grover's algorithm, for instance, has demonstrated a quadratic speedup for exploring unstructured databases  [1] , while Shor's technique  [2]  illustrates that quantum computing may provide an exponential speedup in solving the traditionally difficult problem of big integer factorization. These algorithms are anticipated to include some key characteristics of quantum computation, including quantum superposition, quantum measurement, and quantum entanglement.