dataesr/scientific-paragraphs-categorization huggingface dataset:
However, ultimately we recognise that any way of specifying all elements of a computational experiment would be at least as complex as a fully featured programming language. We therefore simply allow users to define these aspects in Python, the same language used for defining the neural components, as this is already highly capable and readable. We made great efforts to ensure that the detailed work in designing and implementing new features should not interfere with the goal that the user script should be a readable description of the complete computational experiment, as we consider this to be an essential element of what makes a computational model valuable. Brian's approach to defining models leads to particularly concise code (Tikidji-Hamburyan et al. , 2017), as well as code whose syntax matches closely descriptions of models in papers.
Performance Running compiled code for arbitrary equations means that code generation must be used. This requirement leads to a problem: a simulator that makes use of a fixed set of models can provide hand-optimised implementations of them, whereas a fully flexible simulator must rely on automated techniques. By contrast, an advantage of automated techniques is that they can generate optimisations for specialisations of models. For example, using the CUBA benchmark  (Vogels and Abbott, 2005; Brette et al. , 2007)  in which all neurons have identical time constants, Brian 2 is dramatically faster than Brian 1,  NEURON and NEST (Figure 8, left). This happens because Brian 2 can generate a specialised optimisation of the code since the model definition states that time constants are the same. If instead we modify the benchmark to feature heterogeneous time constants (Figure  8 , right), then Brian 2 has to do much more work since it can no longer use these optimisations, while the run times for NEST and NEURON do not change.
We can make two additional observations based on this benchmark. Firstly, the benefits of parallelisation via multi-threading depend heavily on the model being simulated. For a large homogeneous population, the single threaded and multi-threaded standalone runs of Brian 2 take approximately the same time, and the single threaded run is actually faster at smaller network sizes. For the heterogeneous population, the opposite result holds: multi-threaded is always faster at all network sizes. The second observation is that the advantage of running a Brian 2 simulation in standalone mode is most significant for smaller networks, at least for the single threaded case (for the moment, multithreaded code is only available for standalone mode). It should be noted, however, that despite the fact that Brian 2 is the fastest simulator at large network sizes for this benchmark, this does not mean that Brian 2 is faster than other simulators such as NEURON or NEST in general.
Simulations were performed with NEST 2. 16 (blue,  Linssen et al. , 2018 , RRID:SCR_002963), NEURON 7. 6 (orange; RRID:SCR_ 005393), Brian 1. 4. 4 (red), and Brian 2. 2. 2. 1 (shades of green,  Stimberg et al. , 2019b, RRID:SCR_002998). Benchmarks were run under Python 2. 7. 16 on an Intel Core i9-7920X machine with 12 processor cores. For NEST and one of the Brian 2 simulations (light green), simulations made use of all processor cores by using 12 threads via the OpenMP framework. Brian 2 'runtime' simulations execute C++ code via the weave library, while 'standalone' code executes an independent binary file compiled from C++ code (see Appendix 1 for details). Simulation times do not include the one-off times to prepare the simulation and generate synaptic connections as these will become a vanishing fraction of the total time for runs with longer simulated times.
(2014). For larger networks, it can be wasteful to check a condition for each possible connection. Brian therefore also offers the possibility to use a mathematical expression to directly specify the projections of each neuron. In the eye movement example, each retinal neuron on the left hemifield (i. e. x neuron <0) should connect to the first motoneuron (index 0), while neurons on the right hemifield (i. e. x neuron >0) should connect to the second motoneuron (index 1). We can express this connection scheme by defining j, the postsynaptic target index, for each presynaptic neuron accordingly (with the int function converting a truth value into 0 or 1): sensorimotor_synapses. connect(j='int(x_neuron_pre>0)') This syntax can also be extended to generate more than one post-synaptic target per presynaptic neuron, using a syntax borrowed from Python's generator syntax  (Hettinger, 2002 , see the Brian 2 documentation at http://brian2.
Simulation flow In the case study 3, we use a specific simulation workflow, an iterative approach to finding a parameter value (Figure  4a ). Many other simulation protocols are regularly used. For example, a simulation might consist of several consecutive runs, where some model aspect such as the external stimulation changes between runs. Alternatively, several different types of models might be tested in a single script where each is run independently. Or, a non-deterministic simulation might be run repeatedly to sample its behaviour. Capturing all these potential protocols in a single descriptive framework is hopeless, we therefore need the flexibility of a programming language with its control structures such as loops and conditionals. Brian offers two main facilities to assist in implementing arbitrary simulation protocols.
Simulations can be continued at their last state, potentially after activating/deactivating model elements, or changing global or group-specific constants and variables as shown above. Additionally, simulations can revert back to a previous state using the functions store and restore provided by Brian. In the example script shown in Figure  5 , this mechanism is used to reset the network to an initial state after each iteration. The same mechanism allows for more complex protocols by referring to multiple states, for example to implement a train/test/ validate protocol in a synaptic plasticity setting. Providing explicit support for this functionality is not only a question of convenience; while the user could approximate this functionality by storing and resetting the systems state variables (membrane potentials, gating variables, etc.
It is important to note that the context is also given by its position in the program flow. For example, if we want to set the initial value for the gating variable m to its steady value, then this value will depend on the membrane potential v via the expressions for a m and b m. The order in which we set the values for v and m does therefore matter: neuron. v=0*mV neuron. m='1/(1 + betam/alpham)' While this might appear trivial, it shows how the procedural aspect of models, that is the order of operations, can be important. A purely descriptive approach, for example stating initial values for all variables as part of the model equations, would not always be sufficient (however, in this specific case, setting v to 0 mV is unnecessary, since Brian automatically assigns the value to all uninitialised variables).
Some Python statements are translated into code that is run immediately, for example initialising a variable or creating synapses. Others are translated into code that is run at a later time. For example, the code to numerically integrate differential equations is not run at the point where those equations are defined, but rather at the point when the simulation is run via a call to the run() function. In this case, any named constants referred to in the equations will use their value at the time that the run() function is called, and not the value at the time the equations are defined. This allows for that value to change between multiple calls to run(), which may be useful to switch between global behaviours. For example, a typical use case is running with no external input current for a certain time to allow a neuron to settle into its stationary state, and then running with the current switched on by just changing the value of a constant from zero to some nonzero value between two consecutive run() calls.
Code generation In order to combine the flexibility and ease-of-use of high-level descriptions with the execution speed of low-level programming languages such as C, we employ a code generation approach  (Goodman, 2010). This code generation consists of three steps. The textual model description will first be transformed into a 'code snippet'. The generation of such a code snippet requires various transformations of the provided model description: some syntax elements have to be translated (e. g. the use of the ** operator to denote the power operation to a call to the pow function for C/C++), variables that are specific to certain neurons or synapses have to be properly indexed (e. g. a reset statement v = -70*mV has to be translated into a statement along the lines of v[neuron_index] = -70*mV), and finally sequences of statements have to be expressed according to the target language syntax (e.
g. by adding a semicolon to the end of each statement for C/C++). In a second step, these code snippets will then be embedded into a predefined target-code template, specific to the respective computation performed by the code. For example, the user-provided description of an integrate-and-fire neuron's reset would be embedded into a loop that iterates over all the neurons that emitted an action potential during the current time step. Finally, the code has to be compiled and executed, giving it access to the memory location that the code has to read and modify. For further details on this approach, see Goodman (2010);  Stimberg et al. , 2014. for each neuron: x_new = sound + exp(-dt/tau_ear) * (sound -x_old) However, the expression that is calculated for every neuron contains exp(-dt /tau _ear) which is not only identical for all neurons but also relatively costly to evaluate.
Brian will identify such constant expressions, and calculate them only once outside of the loop: c = exp(-dt/tau_ear) for each neuron: x_new = sound + c * (sound -x_old) In addition to this type of optimisation, the Brian simulator will also simplify arithmetic expressions, such as replacing 0*x by 0, or x/x by 1. While all these optimizations could in principle also be performed by the programming-language compiler (e. g. gcc), we have found that performing these changes before handing over the code to the compiler led to bigger and more reliable performance benefits.
Code execution: runtime mode After the code generation process, each model component has been transformed into one or more 'code objects', each performing a specific computational task. For example, a group of integrate-and-fire neurons would typically result in three code objects. The first would be responsible for integrating the state variables over a single timestep, the second for checking the threshold condition to determine which neurons emit an action potential, and the third for applying the reset statements to those neurons. By default, these code objects will be executed in Brian's 'runtime mode', meaning that the simulation loop will be executed in Python and then call each of the code objects to perform the actual computation (in the order defined by the scheduling as described in the previous section).
Note that while the code objects will typically be based on generated C++ code, they can be compiled and executed from within Python using binding libraries such as weave (formerly part of SciPy;  Jones et al. , 2001)  or Cython  (Behnel et al. , 2011). This 'mixed' approach to model execution leaves the simulation control to the main Python process while the actual computations are performed in compiled code, operating on shared memory structures. This results in a considerable amount of flexibility: whenever Brian's model description formalism is not expressive enough for a task at hand, the researcher can interleave the execution of generated code with a hand-written function that can potentially access and modify any aspect of the model. In particular, such a function could intervene in the simulation process itself, for example by interrupting the simulation if certain criteria are met.
The Jupyter notebook at https://github. com/brian-team/brian2_paper_examples contains an interactive version of case study 2 (Figure  3 ). In this example, the aforementioned mechanism is used to allow the user to interactively control a running Brian simulation, as well as for providing a graphical representation of the results that updates continuously. While having all these advantages, the back-and-forth between the main loop in Python and the code objects also entails a performance overhead. This performance overhead takes a constant amount of time per code object and time step and does therefore matter less if the individual components perform long-running computations, such as for large networks (see also Figure  8 ). On the other hand, for simulations of small or medium-sized networks, such as the network presented in case study 4 (Figure  6 ), this overhead can be considerable and the alternative execution mode presented in the following section might provide a better alternative.
Code execution: standalone mode As an alternative to the mode of execution presented in the previous section, the Brian simulator offers the so-called 'standalone mode', currently implemented for the C++ programming language. In this mode, Brian generates code that performs the simulation loop itself and executes the operations according to the schedule. Additionally, it creates code to manages the memory for all state variables and other data structures such as the queuing mechanism used for applying synaptic effects with delays. This code, along with the code of the individual code objects, establishes a complete 'standalone' version of the simulation run. When the resulting binary file is executed, it will perform the simulation and write all the results to disk. Since the generated code does not depend on any non-standard libraries, it can be easily transferred to other machines or architectures (e.
g. for robotics applications). The generated code is free from any overhead related to Python or complex data structures and therefore executes with high performance. For many models, the use of this mode only requires the researcher to add a single line to the simulation script (declaring set_device('cpp_standalone')), all aspects of the model descriptions, including assignments to state variables and the order of operations will be faithfully conserved in the generated code. The Python script will transparently compile and execute the standalone code, and then read the results back from disk so that the researcher does not have to adapt their analysis routines. However, in contrast to the runtime execution mode presented earlier, it is not possible to interact with the simulation during its execution from within the Python script.
Synapses In the first release of Brian, synaptic connectivity was defined by the Connection class, which only allowed a single weight variable which was added to a target neuron variable when a presynaptic neuron fired. Later, a more general Synapses class was added which greatly expanded the flexibility, but was inefficient due to the lack of comprehensive support for code generation in Brian 1. This Synapses class is now the only mechanism in Brian 2, generalises the version from Brian 1 and adds code generation support. Synapses allows for a userspecified set of differential equations and parameters (exactly the same as for neurons) along with a specification of what operations should be calculated on the event of a pre-or postsynaptic spike. Multiple pathways with different delays are supported.
Synapses can modify pre-or post-synaptic neurons in a discrete or continuous manner (to allow for more complex synapse models or rate-based models). Synapses can also target other synapses (for models of astrocytes for example,  Stimberg et al. , 2019c). Multiple synapses per neuron pair are now supported. Brian 1's Connection supported defining connectivity by an explicit array, or by specifying full, random, or one-to-one connectivity. Brian 2's Synapses generalises these with string-based arguments, and adds support for conditional connectivity (a string based expression determining which pairs to connect) and a generator-based syntax that allows you to write code similar to a for loop but that gets converted into efficient low-level code.
Simulations were performed with NEST 2. 16 (blue, Linssen et al. , 2018 , RRID:SCR_002963), NEURON 7. 6 (orange; RRID:SCR_ 005393), Brian 1. 4. 4 (red), and Brian 2. 2. 2. 1 (shades of green,Stimberg et al. , 2019b, RRID:SCR_002998). Benchmarks were run under Python 2. 7. 16 on an Intel Core i9-7920X machine with 12 processor cores. For NEST and one of the Brian 2 simulations (light green), simulations made use of all processor cores by using 12 threads via the OpenMP framework. Brian 2 'runtime' simulations execute C++ code via the weave library, while 'standalone' code executes an independent binary file compiled from C++ code (see Appendix 1 for details). Simulation times do not include the one-off times to prepare the simulation and generate synaptic connections as these will become a vanishing fraction of the total time for runs with longer simulated times.
Acknowledgements We thank the following contributors for having made contributions, big or small, to the Brian 2 code or documentation:  Moritz Augustin ,  Victor Benichoux ,  Werner Beroux ,  Edward Betts ,  Daniel Bliss ,  Jacopo Bono ,  Paul Brodersen ,  Romain Caze, Meng Dong ,  Guillaume Dumas ,  Ben Evans ,  Charlee Fletterman ,  Dominik Krzemin ´ski ,  Kapil Kumar ,  Thomas McColgan ,  Matthieu Recugnat ,  Dylan Richard ,  Cyrille Rossant ,  Jan-Hendrik Schleimer ,  Alex Seeholzer ,  Martino Sorbaro ,  Daan Sprenkels ,  Teo Stocco ,  Mihir Vaidya ,  Adrien F Vincent ,  Konrad Wartke ,  Pierre Yger ,  Friedemann Zenke. Three of these contributors (CF, DK, KK) contributed while participating in Google's  Summer of Code program.
Development and availability Brian is released under the free and open CeCILL 2 license. Development takes place in a public code repository at https://github. com/brian-team/brian2 (Brian contributors, 2019). All examples in this article have been simulated with Brian 2 version 2. 2. 2. 1 (Stimberg et al. , 2019b). Brian has a permanent core team of three developers (the authors of this paper), and regularly receives substantial contributions from a number of students, postdocs and users (see Acknowledgements). Code is continuously and automatically checked against a comprehensive test suite run on all platforms, with almost complete coverage. Extensive documentation, including installation instructions, is hosted at http://brian2. readthedocs. org. Brian is available for Python 2 and 3, and for the operating systems Windows, OS X and Linux; our download statistics show that all these versions are in active use.
Data availability Source code to replicate Figures  1 2 3 4 5 6 7 , as well as the simulations shown in Appendix 4, are provided in a github repository (https://github. com/brian-team/brian2_paper_examples; copy archived at https://github. com/elifesciences-publications/brian2_paper_examples). Source code to run benchmarks as presented in Figure  8  is provided as a supplementary file together with this submission (Source code 1).
Therefore, the research approach is focusing on the analysis of the context of use and of the user's requirements, on the generation of evaluation protocols for each cabin item and on the state of the art of the tools and methods for HCD  [17]. Given the innovative nature of the project, Virtual Reality has been implemented in CASTLE in order to collect data on the human perception of both the cabin environment and the satisfaction of specific requirements set in the project from the user's point of view. In the next section the general approach of the HCD of Business Jet interiors implemented in CASTLE is described. Afterwards, in the materials and methods section information on the participants, the experimental procedure and the measurements methods are provided. Finally, the results and the discussion of results are presented.
Experimental set up The 3D surface model of the cabin has been provided by ACUMEN and has been processed by UNIBO through IC. IDO Software to create the experimental virtual scenario. IC. IDO. ® is a 3D immersive VR software, provided by ESI ® Group, supporting industrial decision making processes and digital mock-up verifications. Two different CMF (Color Material Finishing) options, referred to as "schemes", of the same cabin model are considered for the visual assessment of the modular lay-out in a comparative evaluation process. Thus, the virtual model has been completed with the materials and textures information indicated by the design team (Fig. 3 ). Figure  4  shows the textured mock ups and the differences between the two schemes, hereafter indicated as Scheme 1 and Scheme 2. Two Virtual Reality systems have been set up for the CASTLE Business Jet model at the Virtual Reality Laboratory of the University of Bologna located in Forlì, namely the Passive Stereo Theatre and the Microsoft™ Holo-lens™.
Acknowledgements The work presented in this paper has received funding from the  Clean Sky 2 Joint Undertaking  under the European Union's  Horizon 2020 research and innovation programme  under grant agreement No  807083 ". Authors Acknowledge the volunteers who took part in the experimental campaign. A special acknowledgement to  Sergio Piastra  and  Sandhya Santhosh  for the technical support provided during the test. Open Access This article is distributed under the terms of the Creative Commons Attribution 4. 0 International License (http://creat iveco mmons. org/licenses/by/4. 0/),which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.
INTRODUCTION Property-based testing (PBT) is a technique for validating code that successfully combines two old ideas: automatic test data generation trying to refute executable specifications. Pioneered by QuickCheck for functional programming  [16] , PBT tools are now available for most programming languages and are having a growing impact in industry  [31]. This idea now spread to several proof assistants  [8, 49]  to complement (interactive) theorem proving with a preliminary phase of conjecture testing. The collaboration of PBT with proof assistants is so accomplished that PBT is now a part of the Software Foundations's curriculum (https://softwarefoundations. cis. upenn. edu/qc-current). This tumultuous rate of growth is characterized, in our opinion, by a lack of common (logical) foundation.
For one, PBT comes in different flavors as far as data generation is concerned: while random generation is the most common one, other tools employ exhaustive generation (  [12, 54] ) or a combination thereof (  [19] ). At the same time, one could say that PBT is rediscovering logic and, in particular, logic programming: to begin with, QuickCheck's DSL is basically Horn clause logic; LazySmallCheck  [54]  has adopted narrowing to permit less redundant testing over partial rather than ground terms; PLT-Redex  [20]  contains a re-implementation of constraint logic programming in order to better generate well-typed λ-terms  [22]. Finally, PBT in Isabelle/HOL features now a notion of smart test generators  [11]  and this is achieved by turning the functional code into logic programs and inferring through mode analysis their data-flow behavior.