dataesr/scientific-paragraphs-categorization huggingface dataset:
For example, when pasting a letter from a drawing into a script chart, one can more easily preserve the relationship of a letter to the scribal guide line by using various guides and measuring tools available within Adobe Illustrator (Fig. 9. 18). Also, one can easily document the precise location from which a script chart letter example came (e. g. , which inscription, which line of the inscription, or which example of the letter from that particular line). This can be done on a designated layer within an Illustrator file. The ability to 'copy and paste' letters from a drawing also facilitates the illustration of palaeographical discussions by enabling a scholar to paste letter examples (in the margins) directly alongside written letter descriptions (Fig. 9. 19).
All it takes is verbatim reproduction in some sections, for searches on randomly-selected excerpts to produce positive results. We might therefore hope that one day, as digitization projects continue and OCR technology improves, whenever someone approaches an academic with a fragment of papyrus that they claim to have found, this could be followed on the spot by a Google search, which might fairly quickly suggest that the work too precisely matches another fragment or an online edition of a text, or reveal something else that should give a scholar pause. Of course, Google and most other widely-used search engines are commercial enterprises, and the results they provide may not be what are needed for these sorts of undertakings, even if OCR technology is developed that can accurately recognize ancient scripts, and even if the digitized manuscripts or transcriptions are online and not behind a paywall.
We saw in the case of the Gospel of Jesus' Wife that the forger drew heavily on known texts, making relatively minor modifications so as to make the contents more sensational. Just like students who plagiarize but change a few words, submitting the Gospel of Jesus' Wife to something like TurnItIn might have raised red flags immediately -if that database had included or searched online sources such as Grondin's Gospel of Thomas website. Once again, the point is not that this particular commercial tool would be the best one to rely on in such instances. But the same or a similar approach to maintaining and searching databases of texts might nonetheless prove useful in detecting some instances of forgery, just as tools like TurnItIn or even a Google search can detect some but by no means all instances of academic dishonesty.
To give an example of how a photogrammetric model and orthophoto are generated, I will use my work at Beth Alpha as an example. The photogrammetry project at Beth Alpha began with the taking of a series of 200 photographs of the synagogue's architectural remains and mosaic floor using a DSLR camera. Once all required photos were taken, each image was loaded into the photogrammetry program Agisoft PhotoScan. 10 Once in Agisoft PhotoScan, all necessary parameters were set and the model was processed. To create models, Agisoft PhotoScan uses a set of algorithms that examines and compares every portion of each picture to every other portion of every other picture. The program detects and traces identical features of an object from photo-to-photo, such as the corners of a door. After identifying and tracing points often numbering in the thousands between photos, the software begins to combine those points in three dimensions, creating a 3D modeled object or environment.
Game Engine Video game engines are programs that aid game developers by taking care of large portions of needed computer code to create video games. So instead of having to program the effects of gravity or how light will reflect off objects in each model, Unity3D comes with a full suite of physics and environments preprogrammed into its system that saves developers time and effort. For this portion of the project, the photogrammetric model and suggested reconstruction of each synagogue was imported into Unity3D. 13 Once loaded into Unity3D, a series of features were added to the model of each synagogue, including (1) a menu screen that allowed users to choose features for the character that they would embody in the virtual environment (e. g. height and walking speed); (2) a programmed sun to rotate around the model so that users could experience different lighting conditions within the synagogue through the model's day-night cycle; and (3) an option to toggle a collection of non-playable characters to fill the synagogue so that users could gain a sense of comparative scale.
3D visualizations can often give the false impression of free, uninhibited experience. It is important to remember that designers are required to make decisions at every juncture of a modeling project. These decisions often establish boundaries to a player's experience. For example, concerning the playable character, a designer must input a number of pre-set features for the character, such as the character's height. In the synagogue models, I chose to make the basic, pre-altered avatar 1. 6 m tall, which equates to roughly 5 ft. 7 in. This height setting might limit users wanting to experience the synagogue as someone taller or shorter. In order to combat my decision of a user's height as having an effect on his or her experience, I included a short computer script to allow the user to alter his or her avatar's height.
Some students even created Portuguese subtitled versions of the lecture, which they posted on youtube, to help fellow students. The conversation was also more age-diverse than other HarvardX MOOCs. Our median student age was 35, while other HarvardX courses have a median age of 28, with a majority of students aged 20-30. The number of registrants of the Early Christianity: The Letters of Paul for the age categories 71+ represent more than 10% of total registrants in those age categories for all other HarvardX courses combined. 35 Many of these older students had never participated in 31 <http://harvardx. harvard. edu/research>, accessed on 10. 04. 19. 32 <https://div. hds. harvard. edu/lettersofpaul/course_report. pdf>, accessed on 10. 04. 19. 33 These numbers differ from those contained in the official course report, which captured The Colonized Apostle: Paul Through Postcolonial Eyes, Minneapolis: Fortress, 2011, 161-174; data several months later, indicating that students continued to take the course beyond Marchal, Joseph, ed.
Brian 2 allows scientists to simply and efficiently simulate spiking neural network models. These models can feature novel dynamical equations, their interactions with the environment, and experimental protocols. To preserve high performance when defining new models, most simulators offer two options: low-level programming or description languages. The first option requires expertise, is prone to errors, and is problematic for reproducibility. The second option cannot describe all aspects of a computational experiment, such as the potentially complex logic of a stimulation protocol. Brian addresses these issues using runtime code generation. Scientists write code with simple and concise high-level descriptions, and Brian transforms them into efficient low-level code that can run interleaved with their code.
Popular tools for simulating spiking neurons and networks of such neurons are NEURON  (Carnevale and Hines, 2006) , GENESIS  (Bower and Beeman, 1998) , NEST  (Gewaltig and Diesmann, 2007) , and Brian  (Goodman and Brette, 2008; Goodman and Brette, 2009; Goodman and Brette, 2013). Most of these simulators come with a library of standard models that the user can choose from. However, we argue that to be maximally useful for research, a simulator should also be designed to facilitate work that goes beyond what is known at the time that the tool is created, and therefore enable the user to investigate new mechanisms. Simulators take widely different approaches to this issue. For some simulators, adding new mechanisms requires specifying them in a low-level programming language such as C++, and integrating them with the simulator code (e.
g. NEST). Amongst these, some provide domain-specific languages, for example NMODL  (Hines and Carnevale, 2000, for NEURON)  or NESTML  (Plotnikov et al. , 2016, for NEST) , and tools to transform these descriptions into compiled modules that can then be used in simulation scripts. Finally, the Brian simulator has been built around mathematical model descriptions that are part of the simulation script itself. Another approach to model definitions has been established by the development of simulatorindependent markup languages, for example NeuroML/LEMS  (Gleeson et al. , 2010; Cannon et al. , 2014)  and NineML  (Raikov et al. , 2011). However, markup languages address only part of the problem. A computational experiment is not fully specified by a neural model: it also includes a particular experimental protocol (set of rules defining the experiment), for example a sequence of visual stimuli.
Capturing the full range of potential protocols cannot be done with a purely declarative markup language, but is straightforward in a general purpose programming language. For this reason, the Brian simulator combines the model descriptions with a procedural, computational experiment approach: a simulation is a user script written in Python, with models described in their mathematical form, without any reference to predefined models. This script may implement arbitrary protocols by loading data, defining models, running simulations and analysing results. Due to Python's expressiveness, there is no limit on the structure of the computational experiment: stimuli can be changed in a loop, or presented conditionally based on the results of the simulation, etc. This flexibility can only be obtained with a general-purpose programming language and is necessary to specify the full range of computational experiments that scientists are interested in.
An approach to increase the range of models simulators can express is to use socalled 'model description languages'. These languages describe each element within a model and the relationships between them, but only among a limited set of possibilities, which does not include the environment. This is a problem when attempting to simulate the brain, because a brain is precisely supposed to interact with the outside world. Stimberg et al. set out to develop a simulator that allows neuroscientists to express several neural models in a simple way, while preserving high performance, without using model description languages. Instead of describing each element within a specific model, the simulator generates code derived from equations provided in the model. This code is then inserted into the computational experiments.
This means that the simulator generates code specific to each model, allowing it to perform well across a range of models. The result, Brian 2, is a neural simulator designed to overcome the rigidity of other simulators while maintaining performance. Stimberg et al. illustrate the performance of Brian 2 with a series of computational experiments, showing how Brian 2 can test unconventional models, and demonstrating how users can extend the code to use Brian 2 beyond its built-in capabilities. small neural circuit (case study 1, Figure  1 , Figure  2 ); running a model of a sensorimotor loop (case study 2, Figure  3 ); determining the spiking threshold of a complex model by bisection (case study 3, Figure  4 , Figure  5 ); and running an auditory model with real-time input from a microphone (case study 4, Figure  6 , Figure  7 ).
Brian 2 solves the performance-flexibility trade-off using the technique of code generation (Goodman, 2010;  Stimberg et al. , 2014; Blundell et al. , 2018). The term code generation here refers to the process of automatically transforming a high-level user-defined model into executable code in a computationally efficient low-level language, compiling it in the background and running it without requiring any actions from the user. This generated code is inserted within the flow of the simulation script, which makes it compatible with the procedural approach. Code generation is not only used to run the models but also to build them, and therefore also accelerates stages such as synapse creation. The code generation framework has been designed to be extensible on several levels. On a general level, code generation targets can be added to generate code for other architectures, for example graphical processing units, from the same simulation description.
Design and implementation We will explain the key design decisions by starting from the requirements that motivated them. Note that from now on we will use the term 'Brian' as referring to its latest version, that is Brian 2, and only use 'Brian 1' and 'Brian 2' when discussing differences between them. Before discussing the requirements, we start by motivating the choice of programming language. Python is a high-level language, that is, it is abstracted from machine level details and highly readable (indeed, it is often described as 'executable pseudocode'). In this sense, it is higher level than C++, for example, which in this article we will refer to as a low-level language (since we will not need to refer to even lower level languages such as assembly language). The use of a high-level language is important for scientific software because the majority of scientists are not trained programmers, and high-level languages are generally easier to learn and use, and lead to shorter code that is easier to debug.
In this section, we give a high level overview of the major decisions. A detailed analysis of the case studies and the features of Brian they use can be found in Appendix 1. Source code for the case studies has been deposited in a repository at https://github. com/brian-team/brian2_paper_ examples  (Stimberg et al. , 2019a ; copy archived at https://github. com/elifesciences-publications/ brian2_paper_examples).
An excerpt of this code is shown in Appendix 3-figure  1c. Note that unless great care is taken, this approach may lead to a very specific implementation of the model that is not straightforward to adapt for other purposes. With such long source code (3510 lines in this case) it is also difficult to check that there are no errors in the code, or implicit assumptions that deviate from the description (as in, for example  Hathway and Goodman, 2018; Pauli et al. , 2018). Another approach for describing model components such as graded synapses is to use a description language such as LEMS/NeuroML2. If the specific model has already been added as a 'core type', then it can be readily referenced in the description of the model (Appendix 3-figure  2a ). If not, then the LEMS description can be used to describe it (Appendix 3-figure  2a ).
Such a description is on a similar level of abstraction as the Brian description, but somewhat more verbose (although this may be reduced by using a library such as PyLEMS to create the description;  Vella et al. , 2014). If the user chooses to use the NEURON simulator to simulate the model, then a new synaptic mechanism can be added using the NMODL language (Appendix 3-figure  2b ). However, for the user this requires learning a new, idiosyncratic language, and detailed knowledge about simulator internals, for example the numerical solution of equations. Other simulators, such as NEST, are focussed on discrete spike-based interactions and currently do not come with models of graded synapses, and such models are not yet supported by its description language NESTML. Leveraging the infrastructure added for gap-junctions  (Hahne et al.
Comparison to other approaches The remarks we made earlier regarding the graded synapse in case study one mostly apply here as well. For LEMS/NeuroML2, both motor neurons and the environment could be modelled with a LEMS description. Similarly, a simulation with NEURON would require NMODL specifications of both models, using its POINTER mechanism (see Appendix 3-figure  2 ) to link them together. Since NEST's modelling language NESTML does not allow for the necessary continuous interaction between a single environment and multiple neurons, implementing this model would be a major effort and require writing code in C++ and detailed knowledge of NEST's internal architecture.
g. Edin et al. , 2004) ; models including a complex simulated environment defined in an external package (e. g. Voegtlin, 2011) ; or models with plasticity based on an error signal that depends on the global behaviour of the network (e. g. Stroud et al. , 2018; Zenke and Ganguli, 2018). Capturing all these potential protocols in a purely descriptive format (one that is not Turing complete) is impossible by definition, but it can be easily expressed in a programming language with control structures such as loops and conditionals. The Brian simulator allows the user to write complete computational experimental protocols that include both the model description and the simulation protocol in a single, readable Python script. Case study 3: Threshold finding In this case study, we want to determine the voltage firing threshold of a neuron (Figure  4 ), modelled with three conductances, a passive leak conductance and voltage-dependent sodium and potassium conductances  (Figure 5,.
With version 1 of Brian, we made the choice to sacrifice computational efficiency, because we reasoned that frequently in computational modelling, considerably more time was spent developing the model and writing the code than was spent on running it (often weeks versus minutes or hours; cf. De Schutter, 1992). However, there are obviously cases where simulation time is a bottleneck. To increase computational efficiency without sacrificing flexibility, We decided to make code generation the fundamental mode of operation for Brian 2  (Stimberg et al. , 2014). Code generation was used previously in Brian 1  (Goodman, 2010) , but only in parts of the simulation. This technique is now being increasingly widely used in other simulators, see Blundell et al. (  2018 ) for a review. In brief, from the high level abstract description of the model, we generate independent blocks of code (in C++ or other languages).
We run these blocks in sequence to carry out the simulation. Typically, we first carry out numerical integration in one code block, check for threshold crossings in a second block, propagate synaptic activity in a third block, and finally run post-spike reset code in a fourth block. To generate this code, we make use of a combination of various techniques from symbolic mathematics and compilers that are available in third party Python libraries, as well as some domain-specific optimisations to further improve performance (see Appendix 1 for more details, or  Stimberg et al. , 2014; Blundell et al. , 2018). We can then run the complete simulation in one of two modes, as follows. The sound input is acquired in real time from a microphone, using userprovided low-level code written in C that makes use of an Open Source library for audio input  (Bencina and Burk, 1999).
DOI: https://doi. org/10. 7554/eLife. 47314. 010 In runtime mode, the overall simulation is controlled by Python code, which calls out to the compiled code objects to do the heavy lifting. This method of running the simulation is the default, because despite some computational overhead associated with repeatedly switching from Python to another language, it allows for a great deal of flexibility in how the simulation is run: 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. This facility is widely used in computational models using Brian. In standalone mode, additional low-level code is generated that controls the overall simulation, meaning that during the main run of the simulation it is not necessary to switch back to Python.
While Brian's syntax allows a researcher to define a wide range of models within its general framework, inevitably it will not be sufficient for all computational research projects. Taking this into account, Brian has been built with extensibility in mind. Importantly, it should be possible to extend Brian's functionality and still include the full description of the model in the main Python script, that is without requiring the user to edit the source code of the simulator itself or to add and compile separate modules. As discussed previously, the runtime mode offers researchers the possibility to combine their simulation code with arbitrary Python code. However, in some cases, such as a model that requires realtime access to hardware (Figure  6 ), it may be necessary to add functionality at the target-language level itself.
To this end, simulations can use a general extension mechanism: model code can refer not only to predefined mathematical functions, but also to functions defined in the target language by the user (Figure  7 , l. 9-34). This can refer to code external to Brian, for example to third-party libraries (as is necessary in this case to get access to the microphone). In order to establish the link, Brian allows the user to specify additional libraries, header files or macro definitions (l. 29-31) that will be taken into account during the compilation of the code. With this mechanism the Brian simulator offers researchers the possibility to add functionality to their model at the lowest possible level, without abandoning the use of a convenient simulator and forcing them to write their model 'from scratch' in a low-level language.
Discussion Brian 2 was designed to overcome some of the major challenges we saw for neural simulators (including Brian 1). Notably: the flexibility/performance dichotomy, and the need to integrate complex computational experiments that go beyond their neuronal and network components. As a result of this work, Brian can address a wide range of modelling problems faced by neuroscientists, as well as giving more robust and reproducible results and therefore contributing to increasing reproducibility in computational science. We now discuss these challenges in more detail. Brian's code generation framework allows for a solution to the dichotomy between flexibility and performance. Brian 2 improves on Brian 1 both in terms of flexibility (particularly the new, very general synapse model; for more details see Appendix 5) and performance, where it performs similarly to simulators written in low-level languages which do not have the same flexibility  (Tikidji-Hamburyan et al.
, 2016)  to accelerate simulations in some cases by tens to hundreds of times, and Brian2CUDA (https://github. com/brian-team/brian2cuda). The modular structure of the code generation framework was designed for this in order to be ready for future trends in both high-performance computing and computational neuroscience research. Increasingly, high-performance scientific computing relies on the use of heterogeneous computing architectures such as GPUs, FPGAs, and even more specialised hardware  (Fidjeland et al. , 2009; Richert et al. , 2011; Brette and Goodman, 2012; Moore et al. , 2012; Furber et al. , 2014; Cheung et al. , 2015) , as well as techniques such as approximate computing  (Mittal, 2016). In addition to basic research, spiking neural networks may increasingly be used in applications thanks to their low power consumption  (Merolla et al.