dataesr/scientific-paragraphs-categorization huggingface dataset:
The term benchmark is used in Avalanche to describe a recipe that specifies how the stream of data is created by defining the originating dataset(s), the contents of the stream, the amount of examples, task labels and boundaries  [2] , etc. When defining such elements, some degree of freedom is retained to allow obtaining different benchmark instances. For example, different instantiations of the SplitMNIST benchmark  [57]  can be obtained by setting different class assignments. Alternatively, distinct instances of the PermutedMNIST  [14]  benchmark can be obtained by choosing different pixel permutations. The benchmarks module is designed with the idea of providing an extensive set of out-of-the-box loaders covering the most common benchmarks (i. e. SplitCIFAR  [45] , PermutedMNIST  [14] , etc.
Loggers Text Logger, Interactive Logger, Tensorboard Logger  [1] , Weights and Biases (W&B) Logger  [3]  (in progress). Table  1 : Avalanche supported features for the Alpha release (v0. 0. 1). Classic Benchmarks  dataset implementation provided by the torchvision library. A proper implementation is provided for other datasets (such as CORe50  [32] , Stream-51  [47] , and Open-LORIS  [51] ). The benchmark preparation and data loading process can seamlessly handle memory-intensive benchmarks, such as Split-ImageNet  [45] , without the need to load the whole dataset into memory in advance. Further, the benchmarks module is entirely standalone, meaning that it can be used independently from the rest of Avalanche.
Benchmarks creation The benchmarks module exposes a uniform API that makes it easy to define a new continual learning benchmark. The classic package hosts an ever-growing set of common benchmarks and is expected to cover the usage requirements of the vast majority of researchers. However, there are situations in which implementing a novel benchmark is required. Avalanche offers a flexible API that can be used to easily handle this situation. Starting from the higher-level API, Avalanche offers explicit support for creating benchmarks that fit one of the ready-to-use scenarios. The concept of scenario is slightly different from that of 'benchmark' as it describes a more general recipe independent of a specific dataset. If the benchmark to be implemented fits either in the New Instances or New Classes scenarios  [35] , one can consider using one of the specific generators nc scenario or ni scenario.
Both generators take a pair of train and test datasets and produce a benchmark instance. The New Classes generator splits all the available classes in a number of subsets equal to the required number of experiences. Patterns are then allocated to each experience by assigning all patterns of the selected classes. This means that the New Classes generator can be used as a basis to set up Task or Class-incremental learning benchmarks  [54]. The New Instances generator splits the original training set by creating experiences containing an equal amount of patterns using a random allocation schema. The main intended usage for this generator is to help in setting up Domain-Incremental learning benchmarks  [54]. Most classic benchmarks are based on these generators. Fig. 4  shows a simple example of using nc scenario.
Avalanche leaves the semantic aspects regarding the definition and usage of each stream to the creator of the benchmark. A simple example showing the versatility of this design choice concerns the test stream: in order to allow for a proper evaluation of a continual learning strategy, benchmarks do not only need to describe the stream of training experiences but also need to properly describe a testing protocol. Such protocol is, in turn, based on one or more test datasets on which appropriate metrics can be computed. In many cases, the test data may need to be structured into a sequence of 'test experiences', analogously to what happens with the training data stream. For instance, in Class-Incremental learning the test set may be split into different experiences each containing only test patterns related to classes in the corresponding training experience.
Avalanche currently supports two different streams: train and test, while the support for arbitrary streams (for instance, out-of-distribution stream) will be implemented in the near future. Each experience can be obtained by iterating over one of the available streams. Fig. 5  shows how, starting from a benchmark instance, streams can be retrieved and used. Each experience carries a PyTorch dataset, task label(s) and other useful benchmark-specific information that can be used for introspection. An experience also carries a numerical identifier that defines its position in the originating stream. In fact, experiences in a stream can be also accessed by index. This functionality makes it easy to couple related experiences from different streams. module were designed with the intent of keeping Avalanche as neutral as possible with respect to the presence of task labels.
Training The training module implements both popular continual learning strategies and a set of abstractions that make it easy for a user to implement custom continual learning algorithms. Each strategy in Avalanche implements a method for training (train) and a method for evaluation (eval), which can work either on single experiences or on entire slices of the data stream. Currently, Avalanche provides 11 continual learning strategies (with many more to come), that can be used to train baselines in a few lines of code, as shown in Fig. 6. See Table  1     Under the hood, BaseStrategy deals with most of the boilerplate code. The generic loops are able to seamlessly handle common continual learning scenarios, independently of differences such as the presence or absence of task labels. Plugin System BaseStrategy provides a simple callback mechanism.
Evaluation The performance of a CL algorithm should be assessed by monitoring multiple aspects of the computation  [28]. The evaluation module offers a wide set of metrics to evaluate experiments. Avalanche's design principle is to separate the issues of what to monitor and how to monitor it: the evaluation module provides support for the former through the metrics, while the logging module fulfills the latter (Section 4. 4). Metrics do not specify in which format their output should be displayed, while loggers do not alter metrics logic. Metrics can work even without a logger: the strategy's train and eval methods return a dictionary with all the metrics logged during the experiment. Few lines of code are sufficient to monitor a vast set of metrics: accuracy, loss, catastrophic forgetting, confusion matrix, timing, ram/disk/CPU/GPU usage and Multiply and Accumulate  [22]  (which measures the computational cost of the model's forward pass in terms of floating point operations).
Each metric comes with a standalone class and a set of plugin classes aimed at emitting metric values on specific moments during training and evaluation. Stand-alone Metrics Stand-alone metrics are meant to be used independently of all Avalanche functionalities. Each metric can be instantiated as a simple Python object. The metric will keep an internal state to store metric values. The state can be reset, updated or returned to the user by calling the related reset, update and result methods, respectively. Plugin Metrics Plugin metrics are meant to be easily integrated into the Avalanche training and evaluation loops. Plugin metrics emit a curve composed by multiple values at different points in time. Usually, plugin metrics emit values after each training iteration, training epoch, evaluation experience or at the end of the entire evaluation stream.
Logging Nowadays, logging facilities are fundamental to monitor in real time the behavior of an ongoing experiment (which may last from minutes to days). The Avalanche logging module is in charge of displaying to the user the result of each plugin metric during the different experiment phases. Avalanche provides three different loggers: TextLogger, InteractiveLogger and TensorboardLogger  [1]. They provide reports on textual file, standard output and Tensorboard, respectively. As soon as a metric emits a value, the Text Logger prints the complete metric name followed by its value in the destination file. See Fig. 10    output. The InteractiveLogger reports the same output as TextLogger, but it also uses the tqdm package 2  to display a progress bar during training and evaluation. TensorboardLogger is able to show images and more complex outputs, which cannot be appropriately printed on standard output or textual file.
Models The Avalanche models module offers a set of simple machine learning architectures ready to be used in experiments. In particular, the module contains versions of feedforward and convolutional neural networks and a pretrained version of MobileNet (v1)  [18]. The main purpose of these models is to let the user focus on Avalanche features, rather than on writing lines of code to build a specific architecture. We plan to extend our model support with more advanced architectures, also tailored to specific CL.
In recent times, the continual learning community has put a lot of effort into addressing these problems, by providing code and libraries aimed to increase the reproducibility of continual learning experiments  [9, 20, 36, 50, 53, 54]. On the one hand, these first attempts lack the generality and the consistency of Avalanche, especially regarding the creation of different and complex benchmarks, and the continual support of a large community. On the other hand, they demonstrate, however, the growing interest of the entire community towards these issues. Another area other than continual learning which has recently seen a proliferation of libraries and tools similar in spirit to Avalanche is reinforcement learning (RL). One of the most popular such benchmark RL libraries is OpenAI Gym  [4] , within which a multitude of different RL environments is available.
A similar library is ViZDoom  [56] , in which an agent plays the famous computer game Doom. Other relevant projects in the field of reinforcement learning are Dopamine  [5] , which focuses on simplicity and easy prototyping, and project Malmo  [24] , which is based on the famous Minecraft game. Many of these libraries, however, only focus on the agent's interaction with the environment (which, in the continual learning domain, can be translated into the definition of benchmarks and scenarios), providing none or just a few base strategies or baselines. In the reinforcement learning field, this problem is addressed by other libraries that include standard implementations of baselines algorithms, such as OpenAI baselines  [10]  and stable baselines  [17]. Another prominent example of a collection of baseline training strategies and pretrained models is the natural language processing transformers library by Hugging Face  [55].
Many basic concepts upon which Avalanche is based (e. g. plugins, loggers, benchmarks) can also be found in more general machine learning libraries such as PyTorch Lighting  [12]  and fastai  [19]. Indeed, Avalanche is based on the same comprehensiveness and consistency principle, hence not only benchmarks but also strategies and metrics are included. This promotes consistency across the different parts of the library and simplifies the interaction between different modules. Moreover, Avalanche could be integrated with the mentioned deep learning libraries, thanks to the similarity regarding design principles and code structure. Another important problem in research is the bookkeeping of experiments. Having a tool that keeps track of any single run (hyper-parameters, model used, algorithm used, variants, inputs to the model, etc.
Conclusion and Future Work In the last decade, we have witnessed a significant effort towards making research in machine learning more transparent, reproducible and open-access. However, although research papers are increasingly accompanied by publicly hosted codebases, it is often difficult to run and integrate such software into environments which are typically different from the one within which it was originally designed. This not only hampers reproducibility but also inhibits scal-ability, for each research paper ends up creating its own implementation almost from scratch. Avalanche aims to provide a coherent, end-to-end, easily extendable library for continual learning research and development; a solid reference point and shared resource for researchers and practitioners working on continual learning and related areas.
As reported in Table  1 , the current Avalanche Alpha version focuses on continual supervised learning for vision tasks, as a significant amount of deep learning research in this area was designed and assessed in this context  [15]. However, being Avalanche a community-driven effort, we plan in both the near and medium terms to support the integration of additional learning paradigms (e. g. Reinforcement or Unsupervised Learning), tasks type (e. g. Detection, Segmentation) and application contexts (e. g. Natural Language Processing, Speech Recognition), depending on the research community demands and priorities. We hope that this library, as a powerful avalanche, may trigger a positive reinforcement loop within our community, nudging it to shift towards a more collaborative and inclusive research environment and helping all of us tackle together the grand research challenges presented by a frontier topic such as continual learning.
5, p > 0. 8, n = 746 particles, N = 4 cultures). Bias of particle locations toward the center or edge of the postsynaptic density in (d) was tested by comparing each group to a theoretical median of 0. 5 using one-sample two-tailed Wilcoxon signed-rank tests. See Supplementary Data Table  1  for full pairwise comparisons and summary statistics. Supplementary Fig. 3g, h )  4, 50. Of note, asynchronous fusion intermediates at 11 ms were strongly biased toward the center (Fig. 3a, b, d , median = 0. 1, p < 0. 001, and Supplementary Fig. 3a-d  for more example micrographs). Thus, the distribution of fusion events during asynchronous release is similar to that of NMDA receptors. To test the spatial relationship between fusion events and receptors, we measured the distance between receptors and docked vesicles or exocytic pits.
This process was repeated six times to achieve a full 360degree rotation of the sample. Ion flux was delivered to the sample from several different azimuthal directions to reduce textural artifacts generated during the ion milling. One full rotation of milling constituted a "z slice. " Second, the sample was tilted back to a stage tilt of zero degree to perform SEM imaging. Images were collected from multiple regions-of-interest. These two steps were automated with Autoscript software (ThermoFisher Scientific) and repeated until the desired volume of images was collected-similar to the serial block face imaging technique  77. The milling slice thickness was controlled to achieve 20 nm. Ten areas of interests were acquired in parallel with a X, Y pixel size of 1 nm. A total of ~40 slices was collected from each sample.
The resulting 3D data sets were aligned and visualized using the Amira software (ThermoFisher Scientific). Electron microscopy image analysis. All the images from a single experiment were shuffled for analysis as a single pool using a custom R (R Development Team, R Studio 1. 3, R version 3. 5. 1) script. Images that could not be reliably segmented, either because the image was not of a bona fide synapse or morphology was too poor, were excluded from segmentation; this was done only after randomizing the images. No other data were excluded. The plasma membrane, active zone, PSD, docked synaptic vesicles, synaptic vesicles close to the active zone, pits (putative fusion events), and gold particles were annotated in Fiji (version 1. 0) using a custom macro. The active zone was identified as the region of the presynaptic plasma membrane juxtaposed to the PSD.
A similar amount of overestimate is expected in this case. Features were then quantitated using custom MATLAB (MathWorks R2017-R2020a) scripts (available from: https://github. com/ shigekiwatanabe/SynapsEM). Location of pits, docked vesicles, and gold particles within the active zone/PSD from single sections was calculated from the distance from the center of the pit to the center and the edge of the active zone in 2D. Distance from the center was normalized by dividing the distance to the edge by the half-width of the active zone. For 3D data, the distance to the center of the active zone was calculated from serial sections. First, the location in 2D was calculated as above. Then, the 3D distance was calculated to the center of the active zone in the middle section of the series using the Pythagorean theorem with the assumption that each section is the same thickness and the center of the active zone aligns in each image.
Locations in 3D data were further corrected to be the density of vesicles/pits at each distance from the center of the active zone or PSD. To calculate density of vesicles, pits, and gold particles from the center to the edge in 3D reconstructions, the radial position of each vesicle/pit/gold particle was converted to the fractional area of a circle bounded by that radius. In the case of a unit circle (distance from center to edge is by definition 1 when data normalized to the size of the PSD), this is simply the square of the original normalized distance to the center. Example micrographs shown were adjusted in brightness and contrast to different degrees (depending on the varying brightness and contrast of the raw images), rotated, and cropped in Adobe Photoshop. Cluster analysis. Sequential annotated electron microscopy slices of gold-labeled NMDA and AMPA receptors were used to generate a 3D spatial map of receptors for each synapse (MATLAB 2019b, Mathworks).
2D scatter plots of SSD and synaptic sizes for the experimental and randomized condition for AMPA and NMDA receptors were generated, where low SSD indicates more tightly packed clusters. Linear regression analysis (Prism 7 and 8. 2. 0, GraphPad) was run for each set of conditions to determine whether the experimentally clustered receptors were significantly different than randomized clusters. Computer simulations. Computer modeling was performed using the MCell/ CellBlender simulation environment (mcell. org) version 3. 5. 0-9 for Linux. The realistic model of glutamatergic synaptic environment was constructed from 3D electron microscopy of hippocampal area CA1 neuropil  27, 78, 79. The kinetic scheme and kinetic rate constants for AMPAR (GluAR) activation and desensitization by glutamate were obtained from previously published reports (see ref.
After binding neurotransmitter, the flux of ionic current through activated NMDAR is voltage dependent due to channel blockade by Mg 2+ at hyperpolarized membrane potential  40. We simulated this voltage-dependent blockade with the following approach  27. The neural simulation program NEURON was used to simulate excitatory postsynaptic potentials of the desired timing and amplitude in the spine head located on the dendritic branch of a modeled pyramidal neuron. The time-varying voltages recorded at the spine during these stimuli were used to drive voltage-dependent transition rates in the model of NMDA receptor activation kinetics. The membrane potential waveform simulated following a single vesicle release is consistent with the previous estimate of voltage change in spines  80, 81. The voltage changes alter the kinetic constants for relief of the Mg 2+ block of the NMDA receptors and determine the ion current flux through open NMDA receptors.
Each individual NMDA receptor channel opens and fluxes current in the simulation only when glutamate is bound to the receptor at the time that the Mg 2+ block is relieved. MCell uses stochastic Monte Carlo methods and simulation results reflect the realistic behavior of stochastic channel fluctuations. For all computational experiments, 48 trials were performed, allowing estimation of the mean and standard deviation of the time course of channel activation. Data were analyzed using custom Python scripts using Python-3. 4, NumPy-1. 9. 2, SciPy-0. 15. 1, and matplotlib-1. 4. 3. Statistical analysis. All data showing distribution of receptors, vesicles, and pits are pooled from multiple experiments. The number data shown are per experiment. All data were initially examined on a per experiment basis (with all freezing done on the same day and all segmentation done in a single randomized batch); none of the pooled data show any result that was not found in each replicate individually.
Acknowledgements We are indebted to  Quan Gan ,  Kie Imoto , and  Chengxiu Zhang  for cell culture, help with gold labeling experiments, and stimulating discussions. We also thank  Mike Delanoy  and  Barbara Smith  for technical assistance with electron microscopy. We thank  Cveta Tomova ,  Chad Rue , and  Kenny Mani  at  ThermoFisher Scientific  for facilitating the collaboration on  Helios Hydra DualBeam , and  Christian Rosenmund  and  M. M. B. for sharing unpublished data. We also thank the  Marine Biological Laboratory  and their Neurobiology course for supporting the initial set of experiments (course supported by  National Institutes of Health  grant  R25NS063307 ). S. W. and this work were supported by start-up funds from the  Johns Hopkins University School of Medicine, Johns Hopkins Discovery funds , and the  National Science Foundation  ( 1727260 ), the  National Institutes of Health  ( 1DP2 NS111133-01  and  1R01 NS105810-01A1 ) awarded to S.
Data availability All data supporting the findings of this study are provided within the paper as sounce_data. xlsx and its Supplementary information. Full data tables underlying the figures are available at: https://figshare. com/projects/ Asynchronous_release_sites_are_aligned_with_NMDA_receptors_in_mouse_hippocam-pal_synapses/87923. Raw images and image analysis files are available upon request. Source data are provided with this paper.
Although FCRN gives good results, some factors, such as low contrast dermoscopic images, the presence of hairs and irregular lesion shapes degrade the segmentation results. There are also several U-Net based models proposed for skin lesion segmentation task. For instance, a self-ensemble U-Net model proposed in  (Li et al. , 2018)  with a transformation that improved the effects of regularization by using the unlabeled data, achieving an Intersection over Union (IoU) score 79. 87% on the ISBI 2017 test dataset. In  (Bissoto et al. , 2018) , the authors proposed to use image processing tools to remove noise from the input dermoscopic images, and then the refined image fed to a U-Net based model to segment skin lesions, achieving an IoU score of 72. 8% on the ISIC2018 dataset. In  (Vesal et al.
, 2018) , a network called SkinNet has been proposed. Where the densely connected convolution layers are the core of the layers of SkinNet, which yielded an IoU score of 76. 7% on the ISBI 2017 test dataset. In the SLSDeep model  (Sarker et al. , 2018) , a deep network has been proposed via using dilated residual convolution layers with a pyramid pooling network to extract contextual features from multiscale representations of a dermoscopic image. Besides, a combination of negative Log-likelihood and endpoint error functions has been used as a loss function to improve the boundaries of the segmented lesions. SLSDeep obtained an IoU score of 78. 2% on the ISBI 2017 dataset. In turn, several FCN-based approaches are also applied to skin lesion segmentation. For example, a skin segmentation model based on the FCN architecture has been presented in  (Bi et al.