dataesr/scientific-paragraphs-categorization huggingface dataset:
The ovarian cancer treatment landscape dramatically changed in 2014, with the arrival of PARP inhibitors in high-grade serous carcinomas  15, 16. Deep learning is one of the most powerful AI methods in computer vision and is already widely studied in medical imaging and pathology  17. It is a machine learning method based on a specific neural network for image processing called convolutional neural networks (CNN). Models learn the relationship between input, like an image, and its output, such as cancer location, by minimizing a loss function. The loss function represents the error of the prediction made by the model. It is minimized at each iteration by adjusting the internal parameters during back-propagation. This method can discover complex structures in large datasets, where conventional machine learning algorithms typically fail due to their limited ability to process raw data  18.
Segmentation of nuclei or small repetitive structures like glands or glomerulus does not necessarily require large datasets because of their plurality in the whole slide image. For tumor segmentation, feature sizes vary (from emboli of a few micrometers to massive regions of several centimeters), making it challenging to identify small structures, especially if only massive structures are delineated in the training cohort and conversely. Tumor segmentation could save the pathologist time while increasing security by not missing any tumor spots. The predictions of segmentation models also have the advantage of being interpretable and therefore verifiable for a physician, unlike classification tools which only give the diagnosis in a WSI without further information. Here, we develop and validate a deep learning model for the segmentation of ovarian cancer on whole-slide images based on a small annotated training dataset.
External predictions We made the predictions on an external cohort, from another hospital, with WSI numerized on another brand of scanner. A sample of the predictions is presented in figure  4. The entire set of predictions is available in the supplementary data. The predictions made by the algorithm were reviewed by a gynecopathologist expert who assessed that the majority of the carcinomatous areas were accurately delineated. Nevertheless, it missed some small tumoral areas. As with the internal dataset, predictions are more refined than humans could have made. For this reason, we did not calculate a score for the external cohort, preferring a visual comparison.
Discussion Segmentation is a prerequisite for numerous pathology research projects. In deep learning projects, it can extract regions of interest to optimize learning by focusing on the relevant areas, like the tumor. Deep learning usually requires a large amount of data, which is sometimes incompatible with rare diseases and current practice in many pathology departments that are under-equipped with high-resolution slide scanners and computing resources. Moreover, some countries will not be able to equip themselves for years to come, further widening the gap in research between wealthy and emerging countries and leaving out specific diseases of these populations. In addition, the correct labeling of WSI (to the nearest pixel) is very time-consuming and challenging for human pathologists, making the constitution of a quality annotated database difficult.
Moreover, if we consider deep learning as assistance to delineation, the number of WSI labeled by the pathologist must be significantly lower than the total dataset. Here, we showed that obtaining a correct segmentation algorithm with only eight WSI is possible. The contours are not perfect but are similar to those made by the pathologist. It could be re-imported into visualization software to be corrected if needed. Once updated, it could even be reused for a new round of training. The learning process would be done in several steps, with a human-machine collaboration. Although expert pathologists can give a qualitative assessment, an accurate and reproducible assessment by a widely established metric would ideally be preferred. The evaluation of the model is made difficult here by the absence of perfect ground truth.
Patients The training and internal validation dataset are composed of eight and seventeen patients respectively, randomly selected from all the patients diagnosed with a high-grade ovarian carcinoma between January 2016 and December 2019 in the University Hospital of Nantes in France. To demonstrate the ability of the algorithm to generalize its results, we used an external validation dataset of eight patients selected from the pathology laboratory of the University Hospital of Rennes in France. All images were anonymized before the study, and no clinical data were collected. All slides were normalized by rescaling pixel values from 0-255 to 0-1. The mean and the standard deviation used for normalization were computed on each channel of the dataset. Instead of tiling the entire WSI as usually done, we opted for a memory-efficient sampling strategy combining two approaches.
Training The pipeline has been realized under Python (version 3. 7) using Pytorch framework and Scikit-learn, Fastai, and Deepflash2 libraries  32. All calculations have been made on an NVIDIA V100 Tensor Core GPU with 32 Gb of memory. We used a fully convolutional network pre-trained on ImageNet with a U-Net architecture and an EfficientNet-B6 as a backbone to perform semantic segmentation. We used Ranger as optimizer and a cross-entropy loss. Ranger combines a rectified version of Adam (RAdam) and a LookAhead optimizer for a faster convergence that is less dependent on the learning rate. We trained the model in mixed precision to allow a faster forward propagation with a 0. 01 weight decay. Twelve epochs with a batch size of 16 have been performed using the one-cycle policy with a 10-3 max learning rate.
All images used for training were HES-stained, Formalin-Fixed Paraffin-Embedded diagnostic sections from high-grade ovarian cancer. If several slides were available for a single patient, we selected for training the slide with visually the most tumor. The slides used for the training and the internal validation dataset were digitized at 40x magnification (0. 22µm/px) using the Hamamatsu Nanozoomer scanner in the Micropicell platform (IRS-UN unit, Nantes). The external validation dataset consists of eight WSIs digitized using a Philips scanner at 40x magnification (0. 25µm/px). The three datasets were anonymized and downscaled to 20x magnification (0. 5µm/px) to optimize memory. All WSIs from training and validation datasets were manually annotated on Qupath (version 0. 2. 3) by one experienced gynecopathologist, drawing for each WSI one tumor mask and one mask surrounding all the tissue to optimize sampling.
I. INTRODUCTION The building of exascale computing systems is a huge investment both financially and in terms of scientific effort. Therefore, it is beneficial to enable more applications to access these systems, or at least, promote their transition towards the exascale computing direction. Towards this end, advanced programming models and environments are needed that will assist developers in addressing critical challenges in terms of efficient application deployment, such as maintaining development productivity in the heterogeneous exascale computing environments. EXA2PRO is a framework developed in the context of the EXA2PRO H2020 EU project  [1]  and its goal is to allow the transition of more HPC applications to exascale computing, by focusing on development productivity. More specifically, the EXA2PRO framework allows developers to evaluate applications across a variety of different architectures and therefore, to efficiently exploit accelerators, such as GPUs and FPGAs.
Thus, EXA2PRO lowers the barrier of access and enables more HPC applications to exploit the exascale computing systems, by hiding their complexity from application developers. The EXA2PRO framework combines the skeleton programming model with a multi-backend approach to enable portability and programmability across a variety of architectures. It provides high-level software abstractions (skeletons, multivariant components), through the SkePU tool, that implement data parallel computational patterns commonly found in HPC applications (map, mapreduce, stencil, etc. ), which are automatically generated for various backends (OpenMP, CUDA, OpenCL, etc. ). The framework encapsulates all low-level tuning and optimization tasks to allow developers to focus on application programming and to automatically evaluate applications across different architectures, instead of manually optimizing and porting to accelerators, thus greatly increasing development productivity.
OpenACC, as well as SYCL and other programming models can be considered complementary to EXA2PRO. However, SkePU skeletons are more highlevel and more powerful, as their implementations are not constrained by the given loop nest structure in an OpenACC source program. Among libraries exposing a task-based programming model, OmpSs  [9]  PaRSEC  [10]  and DTD (Dynamic Task Discovery) also provide support for heterogeneous acceleratorbased and distributed systems, and support for dynamic task scheduling to some extent. In comparison, the EXA2PRO runtime, StarPU  [11] , reaches more advanced task scheduling, by achieving compromises between task acceleration, data transfer cost, and energy cost. Its pluggable task scheduling 1 A docker and a singularity container of the framework are available on the EXA2PRO website: https://exa2pro.
SkePU-3 is available as opensource under a modified BSD license  [16]. SkePU  [15] ,  [16]  provides a single, sequential-like programming interface extending modern C++ with data-parallel skeletons, see Tables I-II. For each skeleton, implementation variants (backends) for sequential C++, OpenMP, CUDA (for Nvidia GPUs) and OpenCL (for all GPUs) are available, and also multi-GPU and hybrid CPU-GPU code can be selected  [18]. In EXA2PRO, an additional backend for the MPI bindings of StarPU has been developed. (Access to further platforms such as FPGA accelerator cards can be achieved indirectly via SkePUs interoperability with multivariant components, which are described in Section III-C. ) Table  I  gives short descriptions of the current data-parallel skeletons in SkePU, and the interface properties (such as supported arity, dimensionality of operands and special operand access patterns) are summarized in Table  II ; for detailed descriptions and illustrations for all skeletons we refer to  [15].
In a co-design effort, based on feedback by project partners developing and porting HPC applications to the new programming model, SkePU has been extended with new skeletons such as MapPairs (generalized Cartesian-product style computation pattern, supporting a variadic number of vector operands in each dimension) and MapPairsReduce (fused MapPairs with subsequent row-wise or column-wise reduction), and its programming interface has been generalized and streamlined, such as multi-valued return from all Mapbased skeletons and user functions (as known from Python) and a streamlined interface for the MapOverlap (stencil pattern) skeleton. Minor improvements include optional dynamic scheduling in the OpenMP backend of most skeletons. User functions are problem-specific functions that can be plugged as code parameters into skeletons at instantiation.
Cluster support in SkePU comes in two different (mutually exclusive) flavors: • Outer MPI (also known as MPI+SkePU) applications use SkePU only at node-level and let the programmer use ordinary MPI calls for explicit inter-node communication, duly framed by skepu::external guards (explained later in this paragraph) to preserve sequential semantics and guarantee memory consistency for communicated operands that are managed by SkePU data-containers. For skeleton calls in outer MPI code, the MPI backend of the skeleton is disabled. • Inner MPI applications have MPI-free, plain sequentiallooking SkePU source code where all cluster-level parallelism is exploited by the SkePU MPI backend working on distributed data-containers, hence all communication is implicit. As an illustrating example, Fig.
3  shows an excerpt of a brain modeling simulation code in SkePU (see also Sect. IV-C). It is a time-driven simulator, in which each neuron accumulates the interaction of adjacent neurons and then updates its current state. The user function SimulateNeuron_Skepu is used in an instantiation (line 29) of the Map skeleton, here with no (<0>) element-wise accessed operands. The user function takes as its main operands a weight matrix m and the state vector, prepared for random access with the Mat access proxy (alternatively, row-wide random access with MatRow), resp. Vec access proxy in the user function; see Sect. III-D for SkePU data-container and access proxy types). The skeleton instance is called in line 48. By default, SkePU selects the most parallel backend, but here the user explicitly prescribes a backend (line 31) passed in as a command-line argument string, which is set in the spec object attached to the skeleton instance SimulateTimestepPerNeuron.
C. Multi-Variant Components Multi-variant components are modularized, user-provided functions that may have multiple, user-provided implementation variants written using different programming models such as C++, OpenMP, CUDA, OpenCL or MAXJ (i. e. the programming model of DFEs), and that are annotated with metadata in an XML based annotation framework to support target platform-specific code generation and deployment. EXA2PRO extends this concept from earlier work  [19]  by adding new target platform types (MPI, Maxeler DFE) and meta-modeling new function properties such as operand access patterns. The deployment toolchain for this is called ComPU. EXA2PRO multi-variant components are interoperable with SkePU skeleton instances as they work on the same datacontainer types (Sec. III-D), see also Fig.
SkePU automatically generates, from the skeleton-based application, a source code that leverages the StarPU interface to submit a task graph. For each task, it provides StarPU with the different implementation variants for the different architectures available on the target platform (CPU, GPU, DFE,. ), by gathering them in a codelet (i. e. the collection of functions which achieve the same computation, thus various implementations variants for the computation). Similarly, the different implementation variants provided by the application in the multi-variant components are exposed in StarPU codelets. From the description of the task graph by SkePU and the composition framework, the StarPU runtime system orchestrates the execution of tasks among the different execution units and memory locations.
The StarPU porting introduces a shared memory level of parallelization. It turns each block computation into a task and the runtime distributes them on the different cores within a node. Finally, the DFE implementation required to rethink completely the algorithm in order to match FPGA constraints. All initialisation and setup phases were left untouched, but the roughly 2K lines of C++ for the computationally intensive kernels have been rewritten in the MaxJ language, compiled with the Maxeler toolchain and linked with the original code as a dynamic library. These implementations have been evaluated on the test-case used in production in  [30]  that contains 42490 electrode atoms. In the context of material science for supercapacitors, this is a large test case. It is however small considering computing platform capabilities and is thus a limiting factor for extreme scalability.
A code snippet about how the Map skeleton was applied to the original brain modeling application, is shown in Fig. 3. The original application code is OpenMP-enabled and was used as performance baseline. The derived SkePU implementations were evaluated in terms of performance and scalability. Evaluation results of SkePU GPU and SkePU OpenMP under 80 threads, on a single node (Intel Xeon with 2x20 H/T cores) are shown in Fig. 10. SkePU GPU implementation significantly outperforms the corresponding OpenMP. Additionally, the SkePU OpenMP implementation provides slightly higher performance than the original for network  sizes 30K or higher, due to the fact that SkePU uses more aggressive defaults in OpenMP tuning parameters than the original implementation. Finally, experiments showed that CPU performance is lower when using less than 80 threads for the CPU implementation, for almost all input sizes.
Most skeleton calls for a time step are dependent on each other, and each time step depends on the previous one. Fig. 12  shows SkePU 3 performance results for the embedded ODE solver A from Libsolve solving the Brusselator 2D-MIX problem with 7 stage vectors for the above settings on the Tetralith cluster, using the MPI+OpenMP cluster backend of SkePU on up to 32 nodes with 32 cores each, with one MPI rank per node using 31 OpenMP threads per rank (one core is used by the StarPU-MPI management thread). For a novice SkePU programmer familiar with the application code base, we estimate about 2 weeks of training time and 1 week of SkePU-ization time. Overall, the solver core has about 200 LOC for the time step loop (and 320 LOC including initialization and function evaluation), which is about the same code size as the original sequential code (180 LOC).
E. Discussion In this subsection we summarize the main observations by the analysis of evaluation results. Application developers were able to explore a variety of heterogeneous architectures, by using the single-source multi-backend feature of EXA2PRO: CO 2 capture and Brain modeling were evaluated on CPU, GPU and MPI clusters, while Metalwalls on CPU, DFEs and MPI cluster. Therefore, developers were able to investigate application performance (and energy consumption in some cases, such as Metalwalls) on different computing systems and accelerators. For example, 3 Libsolve repository: https://github. com/UBT-AI2/rk the CO 2 capture application was deployed and evaluated for the first time on a GPU. The most interesting observations from the evaluation of each application on different architectures, having the corresponding native code as baseline, are shown on Table  IV.
ACKNOWLEDGMENTS The authors would like to thank the anonymous reviewers for their insightful comments and suggestions. We thank  Mahder Gebremedhin  for help with the implementation of the Mercurium extensions,  Suejb Memeti  and  Stavroula Zouzoula  for help with the implementation of the ComPU extensions and  Sotirios Panagiotou  for help with the brain modeling application. This work was supported by computational time granted from i) the  National Infrastructures for Research and Technology S. A. (GRNET)  in the National HPC facility -ARIS -under project  EXACO2 , ii) NSC Linköping and  SNIC (Tetralith)  under projects  SNIC 2016/5-6  and  SNIC 2020/13-113 , and iii)  PRACE (Piz-Daint)  under project  pr114  " EXA2PRO ". This work has received funding from the  European Union 's  Horizon 2020 research and innovation programme , under grant agreement No.
01). The most important features positively correlated with a high level of engagement are arm openness and smiles. To gain a better understanding of how novices behaved during the interaction, we automatically annotated the corpus in terms of dialog act using the DialogTag package  (Malik, 2022). 0. 03 % of NoXi's novice's dialog acts were annotated as questions, 96% as feedback, and 3,97% as informative statements. In this paper, we specifically investigate the evolution of the engagement score during interactions. First, we analyze how engagement evolves over time. The linear regression illustrated in Figure  2  shows a significant negative effect of time on engagement (Engagement = -6. 969e-05 * Time + 5. 480e-01 with p ≤ 2e -16 and adjusted R 2 = 0. 03), showing that novices slowly disengage themselves during the course of the interaction.
Simulated user's non-verbal behavior The simulated user also provides non-verbal behavior to the engagement detector module. This behavior must be representative of the level of user engagement. Non-verbal behaviors are sampled from the NoXi database  (Cafaro et al. , 2017). At each simulated turn, the simulated user randomly selects a speaking turn in NoXi where the novice shows the same level of engagement as the simulated user. The simulated user displays the same non-verbal behaviors as the novice in the selected turn.
Engagement estimator The engagement estimator is trained using the NoXi corpus  (Cafaro et al. , 2017). Based on  Sidner and Dzikovska (2002)  and  Dermouche and Pelachaud (2019)  and our Boruta analysis of NoXi (see Section 4), the inputs considered are nonverbal behaviors such as arm openness, arm closed, head nod, head shake, head touch, smile, look at/away, and whether the user is talking or not. First, we discretize the engagement annotation (initially ranging from 0 to 1) on a five items scale  (Yannakakis et al. , 2018). Then, we rebalance the data using random oversampling  (Menardi and Torelli, 2014)  to solve the engagement distribution issue in Noxi (70% of NoXi's speaking turns are annotated on the fourth scale, depicting high engagement). Non-verbal behaviors are annotated frame by frame in the NoXi corpus when our agent estimates an engagement score at each speaking turn.
Results and discussion We collect data from 120 participants (20 per condition) who are recruited using the Prolific crowd-sourcing platform. 20 participants from 2 conditions were removed due to an issue during data collection. We also remove outlier responses. Responses are considered outliers if they are out-of-the-box plots representing the third quartile. In the following, we consider 82 participants for six conditions. Forty-five percent of them were women, 53% were men and 1% other. 17% of them were between  18 and 25 years old, 32% between 26 and 35, 20% between 36 and 45, 26% between 46 and 55, and 4% between 56.
This paper makes the scientific case for publishing not only likelihood functions, but full statistical models -and for making this a standard practice. The preservation of the experimental results in a readily usable form is now widely accepted as important for the continued progress of particle physics. Indeed, all collaborations at the Large Hadron Collider (LHC) now either require, or strongly encourage, experimental physicists to make their results available in databases such as HEPData  [3] [4] [5]. Many particle theory groups are using this information for wider and/or more general interpretation of the experimental results, and have built public software frameworks for this purpose; see Ref. [6]  for an overview of approaches and public tools. These important initiatives build on a bedrock principle of publicly-funded science: the open exchange of scientific results as a way to enable scientific progress and empower those who are sufficiently motivated to contribute to the scientific enterprise.
It could be the result of an individual collision event, a set of events, or a collection of multiple datasets. The statistical nature of the data is quantified by ascribing to it a probability, as specified by a statistical model. Often members of a family of models can be labeled by a single or multi-dimensional parameter ω, which can be continuous or discrete. We write the probability of the data x under the assumption of ω as p(x|ω), with the understanding that this represents a probability density function (pdf) if x is continuous and a probability mass function (pmf) if the data are discrete. 1 tatistical methods fall into two broad categories depending on how the analyst chooses to interpret probability. In frequentist statistics, probability is associated only with the data, x, and is interpreted as a limiting frequency for repeated outcomes of the observation.