dataesr/scientific-paragraphs-categorization huggingface dataset:
Quality measure One way to validate the quality of such translations is to consult a pathologist, however this is expensive and time consuming. Preliminary validation by a pathologist confirms that the translations are indistinguishable from real images. One of the most widely used measures for validating the quality of generated natural images is the Frechet Inception Distance (FID)  [18]. FID measures the distance between features of the generated and real images extracted from the Inception network. Since this network is trained on natural images, it is not directly applicable to the medical domain. Instead, a new network could be trained on histpathological data and used as a feature extractor. However, due to (relatively) limited available data (in comparison to the ImageNet database which contains $14 million training images), it is likely that the trained network will capture dataset specific features (as confirmed by the experiments presented in this discussion), and thus will not reflect the accuracy of translated patches.
This shows that not all target stain translators encode information in the same way. For example, adding noise with a standard deviation of 0:5 to the CD68 intermediate stain results in a higher reconstruction error than adding the same noise in the Jones H&E intermediate stain. We suspect that the level of noise in each target staining correlates with the difficulty of translation i. e. harder translations require more noise. StarGAN appears to be more sensitive to the additive noise than CycleGAN. Potentially because it performs the much harder task of multi-stain translation. In order to properly reconstruct its input, more information may need to be hidden and thus it may be more sensitive to additive noise. In order to quantify this sensitivity to noise, Bashkirova et al. [1]  propose the following measure: the mean pixel difference d between the translations with and without noise is measured and is repeated for a range of standard deviations r.
The area under the resulting rd curve summarises the translator's sensitivity (lower is better, i. e. less sensitive). This is calculated here using the target-to-source translations of 100 random PAS patches from each class and r 2 ½0; 0:025; 0:05; 0:075; 0:1, see Table  5. These were derived from the same PAS source patches but the generators were trained on different target data. Some caution should therefore be taken when comparing between stains, however, these are as close as possible to being comparable. The orders of sensitivity correlate with both the MDS1 and MDS*1 F 1 scores presented in Table  1. It is impossible to do the same analysis for MDS2, i. e. Target ! PAS ! Target, as the target datasets are different. The relatively high sensitivity to noise (therefore potentially high levels of noise present in the translation) offers an explanation for UDA-CGAN's relatively low precision in CD68 and CD34, and UDA-*GAN's relatively low precision overall.
The dataset was divided into 4 training, 2 validation, and 4 test patients. The number of glomeruli in each staining dataset was: PAS -662 (train. ), 588 (valid. ), 1092 (test); Jones H&E -1043 (test); H&E -1151 (test); Sirius Red -1049 (test); CD34 -1019 (test); CD68 -1046 (test); CD3 -1083(test). The training set comprised all glomeruli from the source staining training patients (662) plus 4634 tissue (i. e. non-glomeruli) patches (to account for the variance observed in non-glomeruli tissue).
Acknowledgements This work was supported by: ERACoSysMed and e:Med initiatives by the  German Ministry of Research and Education (BMBF) ;  SysMIFTA  (project management PTJ, FKZ  031L-0085A ;  Agence National de la Recherche ,  ANR , project number  ANR-15-CMED-0004 );  SYSIMIT  (project management  DLR ,  FKZ 01ZX1608A ); and the  French Government  through co-tutelle PhD funding. We thank  Nvidia Corporation  for donating a Quadro  P6000 GPU  and the  Centre de Calcul de l'Université de Strasbourg  for access to the GPUs used for this research. We also thank the  MHH team  for providing highquality images and annotations, specifically  Nicole Kroenke  for excellent technical assistance,  Nadine Schaadt  for image management and quality control, and  Valery Volk  and  Jessica Schmitz  for annotations under the supervision of domain experts.
Background: Although the past decade has witnessed the development of many self-management mobile health (mHealth) apps that enable users to monitor their health and activities independently, there is a general lack of empirical evidence on the functional and technical aspects of self-management mHealth apps from a software engineering perspective. Objective: This study aims to systematically identify the characteristics and challenges of self-management mHealth apps, focusing on functionalities, design, development, and evaluation methods, as well as to specify the differences and similarities between published research papers and commercial and open-source apps. Methods: This research was divided into 3 main phases to achieve the expected goal. The first phase involved reviewing peer-reviewed academic research papers from 7 digital libraries, and the second phase involved reviewing and evaluating apps available on Android and iOS app stores using the Mobile Application Rating Scale.
Finally, the third phase involved analyzing and evaluating open-source apps from GitHub. Results: In total, 52 research papers, 42 app store apps, and 24 open-source apps were analyzed, synthesized, and reported. We found that the development of self-management mHealth apps requires significant time, effort, and cost because of their complexity and specific requirements, such as the use of machine learning algorithms, external services, and built-in technologies. In general, self-management mHealth apps are similar in their focus, user interface components, navigation and structure, services and technologies, authentication features, and architecture and patterns. However, they differ in terms of the use of machine learning, processing techniques, key functionalities, inference of machine learning knowledge, logging mechanisms, evaluation techniques, and challenges.
Although several SLRs on mHealth apps have been previously conducted, our SLR is distinguished by providing engineering perspectives on 3 different sources: research papers, app stores, and GitHub repositories. The SLR involved the analysis and synthesis of empirical evidence by software engineering researchers to help researchers and developers in three main aspects:  (1)  to identify the characteristics and challenges of existing self-management mHealth apps,  (2)  to understand the differences and similarities of existing self-management mHealth apps and find the gap between research papers and commercial and open-source apps, and (3) to suggest future research directions based on gaps identified in the domain. The main contributions of this study are as follows: • The definition of an SLR protocol following the SLR guidelines by Kitchenham and Charters  [1] , which is based on a wide range of literature and the selection of 52 research papers, 42 app store apps, and 24 open-source apps as primary studies.
Data Sources To find studies related to phase 1, we followed an automatic search using the following digital libraries: IEEE Xplore, ScienceDirect, ACM Digital library, SpringerLink, MEDLINE, PubMed, and Sage. To complement the automatic search, a manual search was conducted on relevant journals, including Pervasive and Mobile Computing and Mobile Networks and Mobile Networks and Applications. To find as many studies as possible, we used the snowballing strategy to gather additional studies from the reviewed studies. We used Google Scholar to search for further studies identified from snowballing. In phase 2, we used an automatic and manual search within the following official digital British app stores: Apple iPhone (App Store) and Android (Google Play). In the third phase, we applied an automatic search on GitHub to download open-source apps.
Search Process in Data Sources To identify all related studies, search strings were applied to the selected digital libraries. (3/48) of apps from each store were removed as they were not used for self-health care management. Therefore, of the 42 apps, the final number of apps included on each platform was 21 (50%). In phase 3, the systematic search process was applied to GitHub to identify self-management mHealth apps for the general population using the Swift and Kotlin programming languages. Initially, 491 apps were retrieved with the chosen search strategy as follows: 370 (75. 4%) apps with Swift programming language and 121 (24. 6%) apps with Kotlin language. After removing duplicates and unrelated titles, of the 491 apps, we obtained 64 (13%). These apps were downloaded and analyzed based on the inclusion and exclusion criteria.
Overview of the Selected Studies In phase 1, of 52 studies, 27 (52%) were from IEEE, 18 (34%) from SpringerLink, 3 (6%) from ACM, 2 (4%) from PubMed, 1 (2%) from ScienceDirect, and 1 (2%) from Sage. MEDLINE digital data sources were not included as the downloaded papers focused on analyzing user behavior rather than app development, which was outside the scope of this study. In phase 2, we reviewed 21 apps on each platform, each of which had 2 versions: 1 in the Apple App Store and 1 in Android Google Play. In phase 3, a group of 24 open-source apps was reviewed manually and automatically, including 11 (46%) Android and 13 (54%) iOS apps. In total, we reviewed 41 iOS and 77 Android apps, including 7 (17%) iOS and 45 (58%) Android apps in phase 1, 21 (51%) iOS and 21 (27%) Android apps in phase 2, and 13 (54%) iOS and 11 (46%) Android apps in phase 3.
Architectures and Patterns In phase 1, some studies involved the development of mobile apps to collect real data; however, they analyzed these data on a physical computer, server, or specific tool (eg, Waikato Environment for Knowledge Analysis or MATLAB) to extract features and identify the most accurate ML algorithm. Most of these studies focused on building a suitable model using ML algorithms without providing real information about the mHealth app, which integrates the final model with implementation or architecture. These apps stored the automatically-collected data remotely on a server (2/52, 4%) using a client-server architecture (a web-based mechanism) or locally (7/52, 13%) on a mobile device (an offline mechanism). Approximately 2% (1/52) of studies used pre-existing data sets for processing on a physical computer to build the model.
In phase 2, manual logging was used in 62% (26/42) of apps and could be performed through barcode scanning, input of personal information, or searching the app's internal database. Approximately 24% (10/42) of the apps supported automatic logging through built-in technologies or synchronization with other apps. Approximately 14% (6/42) of the apps supported both automatic and manual logging. Most apps (18/24, 75%) in phase 3 supported manual logging of data such as personal information, food and water consumption, sleep, and emotion. Approximately 17% (4/24) of the apps supported manual logging and synchronization. One of the apps presented real-time information from an external server, and another app supported the automatic collection of data.
Each app in phase 3 was analyzed and evaluated using SonarCloud, as shown in Multimedia Appendix 4. Of the 24 apps, bugs existed in 7 (29%)-1 (4%) in Android and 6 (25%) in iOS. Approximately 17% (4/24) of apps on iOS had vulnerability issues. Of the 24 apps, 23 (96%) on both platforms had code smells. The highest number of code smells was 181, whereas the lowest was 3. Most apps (18/24, 75%) had duplications, ranging from 0. 3% to 14%. Furthermore, we tried to run the apps, and of the 24 apps, only 11 (46%) worked, including 7 (29%) Android and 4 (17%) iOS.
other models. As switching from standard to IM simulation is 1 The invTool can be found on GitHub: https://github. com/ oehlinscher/InvolutionTool in(t) t out(t) t T δ (T ) Figure  2 : The input pulse is so short that the transitions at the output appear in reverse order (dashed lines), i. e. , cancel. Note that here T < 0 and δ(T ) < 0. essentially achieved by loading a different library, existing infrastructure, such as test scripts and input vectors, can be reused without modification. In more detail: (i) We provide an overview of the features and some details of the implementation of the invTool, which facilitates digital timing simulation and power analysis of circuits composed of arbitrary Boolean functions connected via involution channels. We also describe the three variants of involution channels currently supported by our tool, namely, Exp-channels based on simple exponential switching waveforms, Hill-channels based on Hill functions that more closely match real switching waveforms, and SumExp-channels that were identified as a promising alternative thanks to the results of the earlier PATMOS'19 version  [13]  of this paper.
Incorporating IM in Questa in Practice One of the main reasons for developing the invTool was our desire to perform circuit simulations using the IM without the need to install and utilize some non-standard software tool. For that reason, we used VHDL Vital as our guidance for the development of the invTool. As a result, changing between our IM implementation and the former is achieved simply by switching libraries, which facilitates code and test setup re-using. Consequently, our solution not only has the same structure as VHDL Vital, but also responds to the same variables and is also written in VHDL. Simulations in the invTool are completely controlled by Questa, which makes it possible to use all its features without restrictions: Based on the next input transition time at the channel input, the algorithm determines T and the resulting δ(T ), and adds the transition to the channel's output.
By grouping multiple inputs, the user can increase the probability for transitions in a short period of time for the signals of the group, which can be useful for multi-input gates. All these choices can be saved, together with the parameters (µ, σ), in a configuration file, which is finally read by a Python script that ultimately determines the actual transition times. Analog Simulation. To evaluate the accuracy of our predictions, we need a "golden reference", which are currently analog simulations using HSPICE or Spectre. Initially, the randomly generated input transition times are transformed to an analog curve using a piecewise linear (PWL) source with a rise/fall time of 1 ps. This source is then added to a template file, which also imports the circuit under test and is used for the subsequent analog simulations.
Since the input transitions are very steep (mostly likely too steep for certain circuits), it is possible to employ inverter chains in front of each input to shape the signal. For the technologies used in our experiments, two inverters proved to be sufficient to generate realistic signals. Note that we provided a separate supply voltage source to these shaping circuits to prevent any effect on our power measurements. Our analog simulations provide us with both (i) a reference for the actual power consumption and (ii) reference switching traces (i. e. , threshold crossings) at different nodes within the circuit. In the next step of our tool chain, these SPICE switching traces are fed to a Python script (termed V th Crossings in Fig. 6 ), which generates input files that can be interpreted by the succeeding digital simulation tool, in our case, Questa.
$ This research was partially funded by the  Austrian Science Fund (FWF)  projects  DMAC  ( P32431 ),  SIC  ( P26436 ), and  RiSE  ( S11405 ), projects  FREDDA  ( ANR-17-CE40-0013 ) and  DEPEC MODE (Departement STIC ), and by  DigiCosme  (working group HicDiesMeus).
The only exception is Xnet  [17] , which makes it a unique literature reference for algorithmic and low-level comparisons. In addition, Xnet is the most recently published algorithm, and it displays interesting performances on a benchmark dataset. In a nutshell, Xnet is a Bayesian algorithm which aims to cluster elution profiles into isotopic envelopes. More precisely, it starts from the construction of a network with chromatograms as nodes. Then, the network is decomposed into preliminary clusters. The edges within each cluster are scored by estimating the likelihood of two parameters: the correlation between chromatograms and their m/z separation. Finally, the edge validation is carried out using the scores and a chromatogram apex match verification. This leads to the final isotopic envelope construction.
In addition to be time consuming, it can arguably be considered that excluding the trace construction from the algorithm amounts to transferring a bottleneck question to another preliminary processing, or to a human annotator. Second, it strongly relies on the envelope assumption simplification, making it impossible to group elution profiles which m/z difference exceeds a predefined threshold. The third weakness is related to the generalization capabilities: As acknowledged in  [17] , there is not enough data to accurately train the probability model underlying Xnet, making it necessary to complement it with a Bayesian prior. This obviously questions the applicability to datasets that significantly differ from the ones that served to tune the prior. Finally, Xnet does not provide a consensus chromatogram for each cluster: Its output is a CSV file that only assigns a cluster index to each line of the input CSV file.
Materials To conduct our study, we have relied on three datasets. The first one, hereafter referred to as UPS2GT, is a publicly available dataset  [23]. To be used as a benchmark for Xnet, this dataset had been preprocessed and manually annotated with isotopic envelopes that can serve as ground truth  [47]. Moreover, the data had been converted into centroid mode, i. e. a compressed version of the original profile data. In the profile mode, each peak of the mass spectrum is represented by intensities reported for several consecutive m/z values, so as to account for the measurement imprecision. In contrast, the centroid mode summarises all the values of the profile mode into a single m/z value, located at the center of the measurement distribution. It leads to significantly smaller memory footprint, at the price of blurring the differences between true signal and noise.
The second dataset, hereafter referred to as Ecoli-DIA, is the raw output of a DIA analysis of an Escherichia Coli sample (containing over 15,000 peptides 1  which signals are multiplexed). To avoid any distortion or information loss, it was stored using the profile mode. The resulting file has an important memory footprint of 3. 6 GB. Thus, even though chromatogram clustering operates on fraction of the data only (the so-called MS1 acquisitions, see Ecoli datasets: Data preparation section), it requires adapted software tools and methods. Finally, to account for the rapid increment of data size in proteomics (resulting from using ever longer LC and ever more resoluted MS acquisitions), we have considered a third dataset, exactly similar to the Ecoli-DIA dataset, but acquired as Full-MS instead of as DIA.
This means that 100% of the acquisition time was dedicated to MS1 signals, so as to mimick the extraction of a much larger DIA dataset resulting from more time-and m/z-resoluted acquisitions. This so-called Ecoli-FMS dataset has a memory footprint of 3. 2 GB. Even though of equivalent size, this dataset is in fact 16 bigger than Ecoli-DIA (four times more MS1 spectra which are four times more resoluted), see Ecoli datasets: Data preparation section.
UPS2GT benchmark dataset The UPS2GT dataset  [47]  resulted from the liquid chromatography coupled to mass spectrometry analysis of 48 human proteins of the Proteomics Dynamic Range Standard (UPS2) on a AB Sciex TripleTOF 5600 instrument using data dependent acquisition with an MS1 ion accumulation time of 250 ms  [23]. The 28, 568, 990  detected points in the resulting LC-MS map were annotated according to their intensity value, either as informative or as noisy. Over 1,2 million informative points were segmented into 57,140 extracted ion chromatograms referred to as traces. Then, the traces were grouped into 14,076 isotopic envelopes. These envelopes constitute the dataset ground truth (therefore, the objective of the clustering task would be to re-build the envelopes from the traces). The final fully annotated data were stored in a CSV file, where each row depicts one LC-MS point with four pieces of information: its mass to charge ratio, retention time, intensity, trace label and envelope label.
The points that were assumed noise were given -1 or 0 as trace label. The dried extracted peptides were resuspended in 5% acetonitrile and 0. 1% trifluoroacetic acid and 500ng were analyzed by online nanoliquid chromatography coupled to tandem mass spectrometry (LC-MS/MS) (Ultimate 3000 RSLCnano and the Q-Exactive HF, Thermo Fisher Scientific). Peptides were sampled on a 300 µm 5mm PepMap C18 precolumn (Thermo Fisher Scientific) and separated on a 75 µm 250 mm C18 column (Reprosil-Pur 120 C18-AQ, 1. 9 µm, Dr. Maisch HPLC GmbH). The nano-LC method consisted of a 120 minute multilinear gradient at a flow rate of 300 nl/min, ranging from 5 to 41% acetonitrile in 0. 1% formic acid. The spray voltage was set at 2 kV and the heated capillary was adjusted to 270 • C. For the Ecoli-FMS dataset, survey full-scan MS spectra (m/z from 400 to 1,400) were acquired with a resolution of 240,000 after the accumulation of 3 • 10 6 ions (maximum filling time 200 ms).
For the Ecoli-DIA dataset, survey full-scan MS spectra (m/z from 400 to 1,400) were acquired with a resolution of 60,000 after the accumulation of 3 • 10 6 ions (maximum filling time 200 ms) and 30 successive DIA scans were acquired with a 33Th width and a resolution of 30,000 after the accumulation of 2 • 10 5 ions (maximum filling time set to auto). The HCD collision energy was set to 30%. MS data were acquired using the software Xcalibur (Thermo Fisher Scientific).
Ecoli datasets: Data preparation The output of the LC-MS/MS experiments were converted from the proprietary RAW format into mzXML files using ProteoWizard  [48]. It led to files of 11. 4 GB (Ecoli-DIA) and of 10. 2 GB (Ecoli-FMS), containing several pieces of information: discretized spectra under the form of coupled lists of m/z and intensity values; as well as metadata about the experiment (number of spectra, retention time range, etc). In the case of the Ecoli-FMS dataset, all the spectra are peptide mass spectra, also termed MS1. However, the Ecoli-DIA datasets contains two types of spectra: precursor spectra (MS1) and fragmentation spectra (MS2). Thus, to work on the elution profiles, we have extracted the MS1 signals from the Ecoli-DIA file. Then, for both files, we have reconstructed chromatographic signals from MS1 spectrum intensities.
Data compression: Applying the kernel trick can be rather computationally demanding: For a dataset of size N , it requires the computation of a kernel (or similarity) matrix of size N × N. Thus, with between 10 5 and 10 6 chromatograms in the Ecoli datasets, computing and storing the kernel matrix is simply not tractable. The purpose of Nyström method  [53]  (see Nyström approximation section) is to replace the kernel matrix by a low rank approximation, as illustrated in Figure  1B. By relying only on the similarities between each data element and a randomly selected subset, it provides a dramatic reduction of the computational burden at the price of a small and controlled loss of accuracy. Even though Nyström approximation allows for an efficient computation of the kernel matrix, it does not accelerate the clustering algorithm itself, which requires multiple traversing of the entire dataset (i.