dataesr/scientific-paragraphs-categorization huggingface dataset:
Then, how can we do something original using tools that are provided in public? In this short chapter, we define several terms describing the world of bioimage analysis software, which are "workflows", "components", and "collections", and explain their relationships. We believe that clarifying the definition of these terms can contribute largely to those who want to learn bioimage analysis, as well as to those who need to design the teaching of bioimage analysis. The reason is that these terms link the generality of software packages provided in public, with the specificity and the originality of the analysis that one needs to achieve.
Types of Bioimage Analysis Software Software packages such as ImageJ  (Schneider et al. 2012 ), 1  MATLAB, 2  CellProfiler  (Carpenter et al. 2006)   3  or ICY  (de Chaumont et al. 2012)   4  are often used to analyze image data in life sciences. These software packages are "collections" of implementation of image processing and analysis algorithms. Libraries such as ImgLib2 (Pietzsch et al. 2012), 5 OpenCV  (Bradski 2000) , 6 ITK  (Johnson et al. 2015a,b) , 7 VTK  (Schroeder et al. 2006 ), 8 and Scikit-Image (van der Walt et al. 2014) 9 are also packages of image processing and analysis algorithms, although with a different type of user interface that is not graphical. We invariably refer to them as "collections". To scientifically analyze and address an underlying biological problem, one needs to hand-pick some algorithms from these 1 collections, carefully adjust their functional parameters to the problem and assemble them in a meaningful order.
Such a sequence of image processing algorithms with a specified parameter set is what we call a "workflow". The implementations of the algorithms that are used in the workflows are the "components" constituting that workflow (or "workflow components"). From the point of view of the expert who needs to assemble a workflow, a collection is a package bundling many different components. As an example, many plugins offered for ImageJ are mostly also collections (e. g. Trackmate  (Tinevez et al. 2016 ), 10 3D Suite  (Ollion et al. 2013 ), 11 MosaicSuite 12 …), as they bundle multiple components. On the other hand, some plugins, such as Linear Kuwahara filter plugin, 13 are a single component implemented as a single plugin. Each workflow is uniquely associated with a specific biological research project because the question asked therein as well as the acquired image quality are often unique.
e. a computer program, with documented parameter sets for clarity and reproducibility of analysis and results. In our opinion, the best format is a version-tracked script because the version 1 used for the published results can be clearly stated and reused by others. A script embedded in a Docker image is even better for avoiding problems associated with a difference in execution environments. Towards a more efficient designing of workflows, The Network of European Bioimage Analysts (NEUBIAS) has been developing a searchable index named Bioimage Informatics Search Engine (BISE). This service is accessible online at 7 https://biii. eu and hosts the manually curated registry of collections, workflows and components. Two ontologies are used for annotating resources registered to BISE: The BISE ontology for properties of resources e.
g. programming language; and the EDAM Bioimaging Ontology  (Kalaš et al. 2019 )-an extension of the EDAM ontology  (Ison et al. 2013 ) developed together with ELIXIR 15 -for applications of these resources, e. g. image processing step and imaging modality. "Component", "Workflow" and "Collections" are implemented as part of the BISE ontology for classifying the type of software, for more distinctive filtering of search results. While BISE allows researchers to search for bioimage analysis resources at all these levels, general web search engines, such as Google, typically return hits of collections but not to the details of their components. In addition, workflows are in many cases hidden in biological papers and difficult to be discovered. BISE is also designed to feature users impressions on the usability of components and workflows so that individual experiences can be swiftly shared within the community.
Take Home Message Within the world of bioimage analysis software, various types of tools, which can be classified as "collections", "components", or "workflows", coexist and are flatly provided to the public as "software tools". Clear definition of these types and recognition of the role of each is a foundation for learning and teaching bioimage analysis. k Further Readings 1. Miura and Tosi (2016)  discusses the general challenges of bioimage analysis. 2. Miura and Tosi (2017)  provides more details on the structure and designing of bioimage analysis workflows. 3. Details about NEUBIAS can be found at the following web pages: 5 7 http://neubias. org 5 7 https://www. cost. eu/actions/CA15124: The Memorandum of Understanding describes the objectives of the network, that includes the motivation to create the registry 7 http://biii.
That proof, however, is generally not a proof in normal form. The steps involved to normalize such a proof (as described by, for example, Prawitz in  [92] ) are similar to β -reductions in typed λ -calculi. In that way, a proof of B ⊃ C can be seen as a function that takes a proof of B to a proof of C (employing modus ponens and normalization). This computational perspective of (natural deduction) proofs is often used as a formal model of functional programming. Proof search: Formulas can be used to encode both programs and goals (think to rules and queries in database theory). Sequents are used to encode the state of a computation and (cut-free) proof search is used to provide traces in computation: changes in sequents denote the dynamics of computation. Cut-elimination is not part of computation but can be used to reason about computation.
Of course, many situations need such permanence: for example, once a (sub)proof establishes that the atomic formula (plus 2 3 5) holds (encoding the fact that 2 + 3 is equal to 5) then this fact is, of course, always true. On the other hand, computing needs to deal with situations where a memory cell contains one value now, but in the future, it contains another value. Modeling such memory cells in classical logic cannot be done as simply as by using a predicate of the form "the memory location l contains value x". Resolving this tension has generally gone along two different avenues. The first avenue added various features to a programming language, such as Prolog, that were difficult or impossible to provide a logical description. In these cases, the resulting features can be useful but the underlying programming language drifts more and more from its basis in logic.
A quick primer: terms and formulas of predicate logic We shall assume that the reader has at least some familiarity with first-order predicate logic. In this section, we simply review a few concepts that will help to anchor our later discussions. In order to define term and formula structures, we need to know which symbols denote predicates and function symbols and what is their arity. Many first-order logic systems (including most Prolog languages) only declare the arity of such symbols. For example, the constructors for natural numbers and lists of natural numbers can be written as {z/0, s/1, nil/0, cons/2, append/3} Thus, cons (the non-empty list constructor) takes two arguments while append (the relation between two lists and the result of appending them) takes three arguments. Some first-order logics are sorted: that is, there are primitive sorts, say, nat (for natural numbers) and list (for lists of natural numbers), and constructors are declared to take their arguments from certain sorts.
Using the predicate symbol append introduced in Section 4, the above two facts about concatenation can be encoded as the two formulas ∀L(append nil L L) and ∀X∀L∀K∀M[(append L K M) ⊃ (append (cons X L) K (cons X M))] (Here, the type of X is nat and of L, K, and M is list. ) Following standard Prologinspired conventions, we shall write variables as tokens with an initial capital letter and we shall drop all quantifiers assuming that all variables are universally quantified around such formulas. Another convention used by Prolog is to reverse the direction of the implication and to use an ASCII approximate :-to a turnstile ( ). Following these conventions, we have the following Prolog-style program definition. 1 ppend nil L L. append (cons X L) K (cons X M) :-append L K M. For a second example of a declarative specification written using Prolog syntax, Figure  1  contains a small graph along with the specification of both the adjacency relation of that graph and a specification of the notion of a path between two points in that graph.
In the last line of that specification, another Prolog convention is used: the comma denotes conjunction. That last line can be read as follows: if there is a step from X to Z and a path from Z to Y then there is a path from X to Y. We have also assumed that the signature for these formulas contains the following items a : node, b : node, c : node, d : node, step : node → node → o, path : node → node → o where node is a primitive type denoting nodes in the graph. In general, the logical formulas that underlie the Prolog programming language are formulas generally referred to as Horn clauses. These formulas are of the form ∀x 1. ∀x n [(A 1 ∧ • • • ∧ A m ) ⊃ A 0 ], (n, m ≥ 0) where the formulas A 0 , A 1 ,. , A m are atomic formulas all of whose free variables are in the set {x 1 ,. , x n }.
While some extensions, such as HiLoG  [14] , proved useful in some circles, they often exerted no influence on the topics of logic and proof theory. There are, however, many downsides of using resolution as the core explanation of how logic programming languages should work. -Refuting is an odd choice in a setting where proving seems more natural. -In order to present formulas as Horn clauses, one may need to transform a formula into its conjunction normal form, and this can cause an exponential increase in formula sizes or require the introduction of new predicate constants in order to keep that size from exploding. -First-order unification maintains the normal form of clauses while this is not the case with higher-order quantification since predicate substitutions can transform a formula in normal form into one that is not in normal form.
By the mid-1980s, intuitionistic logic and its proof theory had had a long development, much of that was in the general area of the Curry-Howard Isomorphism (proofs-as-programs). As it turns out, at about this same time, there was nearly simultaneous development of computational uses of large parts of intuitionistic logic that fell outside the Curry-Howard Isomorphism and more squarely in the proofsearch framework. These various developments include the following. -The N-Prolog language of Gabbay and Reyle  [25, 26]  was designed to allow hypothetical implications in a Prolog-like setting. -McCarty  [58, 59]  explored using intuitionistic logic to extend the expressiveness of logic programs. -Miller, Nadathur, Pfenning, and Scedrov  [74, 75]  developed a higher-order version of hereditary Harrop formulas in order to support within logic programming rich notions of abstractions, such as modules, abstract datatypes, and higher-order programming.
As in the case of Horn clauses, proof search with hereditary Harrop formulas yields uniform proofs that are organized into alternating phases: one phase reduces goal formulas (using right-introduction rules), and one phase performs backchaining steps (using left-introduction rules and the initial rule)  [64, 74]. The λ Prolog programming language was designed to implement most of the intuitionistic theory of higher-order hereditary Harrop formulas: a key design goal of that language was to demonstrate the abstraction mechanisms that those formulas provide  [73, 83]. Since there is a significant gap between having a description of a logic programming language in a sequent calculus and an actual implementation of that language, there were a number of significant developments that needed to be made prior to having comprehensive implementations of that language, of which there are two currently, namely Teyjus  [85, 94]  and ELPI  [19].
Influence: Logic programming on proof theory One approach to writing logic programs that manipulate bindings with data allows bindings to move from terms, to formulas, to proofs. Proof theory can account for this mobility of binders by identifying eigenvariables as proof-level binders. λ Prolog was the first programming language to embraced this notion of binder mobility  [70, 72]  although this notion is also present in specification languages based on dependently typed λ -calculus  [18, 37, 90]. The Isabelle theorem prover  [89]  also supports binder mobility using the technical device of ∀-lifting to link proof-level bindings to formula-level quantification.
A more recent systematic review added 30 papers  [4]  and showed the diversity in the countries at the origin of the publications. The retained studies were either general or more specific of some International Nonproprietary Names (INN) and medication categories, such as anti-infectives, inotropics, surfactant, nitric oxide, narcotics-sedatives, caffeine, histamine-2 receptor antagonists and proton pump inhibitors. This list can be completed by recent papers focused on corticosteroids  [7] , antihypertensives  [8]  and paralyzers  [9]. This study is the first part of a benchmarking program on prescription in neonatology, based on a single database of all electronic prescriptions performed over a 2-year period in 29 French Level 3 neonatal wards (i. e. with neonatal intensive care, intermediate care and neonatal medicine).
The Level 3 Neonatal Wards of the study From January 1, 2017 to December 31, 2018, twenty-nine L3NW engaged in a benchmarking program of neonatal medication prescribing practices (B-PEN program). Seventeen L3NW have been involved since the beginning, while another 12 have progressively joined the program. Prescription data were collected in the L3NW through a computerized order-entry system (CPOE) associated with a Clinical Decision Support System (CDS) (Logipren comp. ). The study is limited to two years of data collection (2017-2018) to limit heterogeneity due to the progressive recruitment of neonatal services and changes in prescribing practice over a longer period, such as have already reported others  [10].
National data about newborns < 32 WG admitted in L3NW were obtained from the French medico-administrative database PMSI (Programme de Médicalisation des Systèmes d'Information) which provides information on neonatal care in all public and private French hospitals. The representativeness (% of the total number of national admissions in L3NW) was calculated at each annual quarter of the study since the number of included level 3 hospitals increased gradually from 17 to 29 over the two years of the study. Results are presented using frequency and proportion for discontinuous variables, and using the mean, standard deviation and extreme values for continuous variables. Khi-square tests and Spearman correlation coefficient are used. Statistical analysis was conducted using SAS 1 software (Version 9.
Level 3 Neonatal Wards Neonates were included in this retrospective research as soon as their respective L3NW begun to use the CPOE/CDS system of the B-PEN network (Table  1 ). The mean contribution of each L3NW to the population of the database was 3. 4% (min = 0. 4; max = 8. 7). Due to the progressive increase in L3NW all along the study period the national representativeness of the study population progressively increased for preterm infants below 32 weeks (Fig  2).
The database fits well with the setting up of a neonatal prescriptions registry as a witness of evidence in the real world practice. Moreover the constant recording of prescriptions is the prerequisite of a long term benchmarking of neonatal wards. Large representation of the population also offers possibilities for public health surveys. The question of representativeness is important but will need further specific approaches. Indeed it can be suggested that hospitalized patients in the 68 French L3NW are effectively mirrored by the 29 L3NW (42. 6%) of the B-PEN program that includes about 40% of the French newborns under 32 WG. The overall French population was identified via a national medico-administrative database (Programme de Médicalisation des Systèmes d'Information, PMSI) whose validity for GA has been previously shown satisfactory  [33].
Conclusion This study shows the feasibility of a continuous record of all medications prescribed in L3NW. It arises the question of polypharmacy and potential increased medication-medication interactions in NICU, particularly in the most immature neonates  [17]. The intense exposition of the preterm infants to pharmacological agents will require sufficient consideration in future studies on their short-and long-term consequences. Since neonates remain therapeutic orphans, in depth therapeutic database represents a major challenge for the health of the most immature neonates.
Task For children with epilepsy and /or ADHD, the experiment was done during regular clinical followup requiring a video-electroencephalogram (EEG). An EEG was also performed in healthy children for a separate study. For healthy controls, the task was conducted at the Lyon Neuroscience Research Center (CRNL). The paradigm was adapted for children from the original BLAST  [21]. Participants were seated in front of a computer screen, in a quiet room with minimal distraction. They were informed that they were going to play a game, with the aim to find a balance between speed and accuracy. The experiment started after a 1-minute training period: there were three blocks of 3 minutes interspersed by a 30 seconds (s) break. The complete experiment took approximately 15 minutes. Visual BLAST stimuli were presented on a PC running the Presentation Ⓡ stimulus delivery software  [25]  synchronized with the EEG acquisition system.
Behavioural analysis First, an ANOVA was conducted with a single explanatory factor (block factor) to assess the influence of the order of each block on BLAST measures (to rule out a potential influence of fatigue). Since no effect of the block factor was shown, we used trials from the three blocks for subsequent statistical analyses. To assess the factors influencing the attentional performance during BLAST paradigm, we used an ANOVA applied on a linear mixed effect model (R-lme4 package)  [29]  taking into account the heterogeneity, heteroscedasticity and non-normality of data. These models were used because they take intersubject and inter-age heterogeneity into account. The choice of the best model was made according to criteria reflecting its parsimony (AIC and BIC values). Type II variance analyses (car package version 3.
0-2)  [30]  were performed using a Wald Chi2 test. Post-hoc tests, adjusted for the number of comparisons, were performed using the Lsmeans package (Lsmean version 2. 27-61)  [32]  with the Tukey method. Two analyses were performed: (a) the first analysis included the four groups (epilepsy with ADHD and without ADHD, ADHD and controls) considering the group and the age as explanatory variable. (b) the second analysis focused on the epilepsy groups by taking the age of seizure onset, the seizure frequency during the last 12 months (none, 1-5 seizures, 5-12 seizures, 13-50 seizures, 1 seizure per week or one seizure per day), the type of epilepsy (focal or generalized), the duration of epilepsy (duration in months between the age of the first seizure and the age at the test) and the number of anti-seizure drugs (none, monotherapy or polytherapy) as explanatory variables.
For each analysis, variables to be explained were RT, error rate, variability, Stability and Intensity. A complementary analysis was performed to describe behavioural responses of children with epilepsy with attentional complaints but who did not fully meet the DSM-V criteria (i. e. 4 to 5 inattention criteria and less than 6 hyperactivity criteria) (n = 17). To this end, we established age-dependant normative values for the different BLAST scores in the control group using the R-lme4 package  [29]. A polynomial fit was used to model the relationship between BLAST variables and age of the subject with a 95% confidence interval. A cut-off was established (95% confidence interval) and allowed to categorize the performance for each BLAST variable as pathological or not pathological as compared to the norm derived from the control group.
Acknowledgements We thank all children and their parents for their participation in the study and gratefully acknowledge the medical staff and fellows involved in this project for their help in recruiting participants :  Dr. P. Keo-Kosal ,  Dr. K. Ostrowsky-Coste ,  Dr. E. Panagiotakaki ,  Dr. A. Montavont ,  Dr. J. Toulouse ,  Dr. C. Milleret ,  Dr. Z. Gokce ,  Mrs. F. Ilsky-Lecoanet ,  Mrs. A. Marcastel.
We then briefly review the organization of the Tinker-HP code and identify the computational hotspots which require Intel AVX-512 optimization and we propose a general and optimal strategy to vectorize those particular parts of the code. We present our optimization strategy in a pedagogical way so it can benefit other researchers interested in improving performances of their own software. Finally we compare the performance enhancements obtained to unoptimized code, both sequentially and at the scaling limit in parallel for classical non-polarizable (CHARMM) and polarizable force fields (AMOEBA). This paper will be updated as we accumulate new data available on the associated Github repository between versions of this living document.
Introduction Tinker-HP is a massively MPI parallel package dedicated to classical molecular dynamics (MD) and to multiscale simulations, especially using advanced polarizable force fields (PFF) encompassing distributed multipoles electrostatics  [1]. It is an evolution of the popular Tinker package code  [2]  which conserves Tinker's simplicity of use and its developerfriendliness, allowing for the rapid development of new algorithms. Tinker-HP offers the possibility to perform large scale simulations while retaining the Tinker reference double precision implementation dedicated to CPU-based (Central Processing Unit) petascale architectures. The parallel scalability of the software is demonstrated via benchmark calculations. Overall, a several thousand-fold acceleration over a single-core computation is observed for the largest molecular systems, thus allowing long reference polarizable MD simulations on large molecular systems containing up to millions of atoms.
Despite this strong acceleration, and due to the development model of the Tinker software suite (now version 8  [2] ), which favours new scientific development over optimization, no attempt has previoustly been made to adapt the Tinker-HP code to a particular CPU architecture. Each execution of the existing code took little or no advantage of the underlying capabilities of the CPU it was running on. The deployment of numerous processors with SIMD (Single Instruction/Multiple Data) capabilities that in principle allow substantial speedups leads us to address this issue. The existence of strong vector capabilities on modern Intel ® architectures, and particularly the Intel ® Advanced Vector Extensions 512 (Intel AVX-512) on Intel ® Xeon ® Scalable and Intel Xeon ® Phi ™ processors, combined with the excellent support from the Intel ® Fortran Compiler, motivates us to change the overall design of the code, while trying to keep its simplicity and readability.