dataesr/scientific-paragraphs-categorization huggingface dataset:
Realistic simulation of noise in vibration phase data. In digital holographic interferometry, the corruption of phase data is mainly due to speckle phase decorrelation. The decorrelation noise can be realistically simulated by considering experimental conditions as described in Ref. 56. The deformation due to the vibration, U z (x, y, t n ) , is put into the noise simulator, then the noisy Doppler phases are obtained by calculating the dif- ference of the successive output noisy maps from the algorithm. As results, the simulator yields speckle phase decorrelation noise having the same statistics as that estimated from real experimental phase maps. The probability density function of phase noise ǫ is the given by the following equation 75 : with ǫ the phase noise, β = |µ| cos(ǫ) and |µ| the modulus of the complex coherence factor of the speckle field between the two considered instants.
The Psychophysics Toolbox (PTB) is one of the most popular toolboxes for the development of experimental paradigms. It is a very powerful library, providing low-level, platform independent access to the devices used in an experiment such as the graphics and the sound card. While this low-level design results in a high degree of flexibility and power, writing paradigms that interface the PTB directly might lead to code that is hard to read, maintain, reuse, and debug. Running an experiment in different facilities or organizations further requires it to work with various setups that differ in the availability of specialized hardware for response collection, triggering, and presentation of auditory stimuli. The Objective Psychophysics Toolbox (o_ptb) provides an intuitive, unified, and clear interface, built on top of the PTB that enables researchers to write readable, clean, and concise code.
INTRODUCTION Writing the source code for an experimental paradigm is one of the most crucial and critical steps of a study. Open-Source software applications and libraries like PsychoPy  (Peirce, 2007 (Peirce, , 2009;; Peirce et al. , 2019)  and the Psychophysics Toolbox (PTB;  Brainard, 1997; Pelli, 1997; Kleiner et al. , 2007)  have enabled researchers to develop experiments using Python or MATLAB (The MathWorks Inc. ), both popular programming languages within the scientific community. Both PsychoPy and the Psychophysics Toolbox essentially provide an interface to the underlying hardware, like the graphics card, the sound card, input devices (keyboards, mice, and button boxes), and devices capable of sending triggers. The libraries are also designed to ensure minimal latencies and -even more important -minimal jitter, which is a crucial requirement for recording high-quality data.
The Psychophysics Toolbox in particular has been used by generations of researchers, acting as a thin interface between MATLAB and various low-level libraries. Visual stimuli are drawn via OpenGL  (Woo et al. , 1999) , which is also used to control and return the time the stimuli appear on screen. Auditory stimuli are controlled via PortAudio  (Bencina and Burk, 2001 ) by directly interacting with audio-buffers. Responses are acquired via low-level access through Java. Besides standard PC hardware, the Psychophysics Toolbox supports a wide variety of specialized hardware like various eye-trackers as well as response and triggering devices -each via a unique interface. This low-level approach makes the Psychophysics Toolbox extremely versatile and flexible. However, this low-level approach makes it harder to create source code that is easy to write, maintain, and understand.
The high level of knowledge required when interacting with the hardware on this level increases the likelihood of errors in the code, while at the same time decreasing the likelihood of errors being identified. It also increases the amount of code that is necessary to accomplish a task. These aspects also make it quite difficult to learn how to use the software efficiently and correctly. The "Objective Psychophysics Toolbox" (o_ptb, available at https://gitlab. com/thht/o_ptb) is an open-source library for MATLAB that attempts to overcome the aforementioned issues by providing an abstraction layer on top of the Psychophysics Toolbox as well as other libraries for specialized hardware. It was designed to provide a generic, enhanced, and intuitive interface to the underlying hardware while maintaining the versatility of the Psychophysics Toolbox.
In this article, we will discuss common challenges and best practices for the development of an experiment and how these influenced the design of the o_ptb. In order to illustrate the benefits of the o_ptb, we wrote source-code for a simple task, including visual and auditory stimulus presentation, triggering and response collection that runs with and without the VPixx system. The first version uses the o_ptb while the second version does not (see Supplementary Materials 1, 2). Throughout this article, sections of these two files will be used to illustrate individual aspects of the design and implementation of the o_ptb. To complement the description of the toolbox, the timing properties (accuracy and jitter) will be presented for two common hardware setups.
The o_ptb, on the other hand, was designed as a high-level toolbox, allowing the user to specify what needs to be done and leaving the how it is done to the toolbox. Figure  1  illustrates this difference using common tasks from an experimental paradigm: the right hand side of each panel lists the necessary low level steps to accomplish the respective task. The purpose of the o_ptb is to enable the user to specify only the more descriptive and in total fewer steps on the left hand side of each panel. The "job" of the o_ptb is to translate these high level commands to the low level commands of the PTB. A toolbox designed for humans must also take into account that errors in source code are common  (Boehm and Basili, 2005). Many of those do not show up as an error message and stop the execution of the script.
In the context of a neuroscientific/psychological experiment, examples include mistakes in formulas processing a stimulus, errors in response collection/processing or problems converting data coming from or going to the underlying hardware. These errors are dangerous as they might lead to severe problems, for example, concerning the temporal accuracy, the randomization of stimuli and trials or properties of stimuli, like their size, position, color, or volume. A well designed high level interface reduces complexity of the source code and provides well-tested code that can be reused. These factors also increase the readability of the source code. All three of these factors have been shown to reduce the number of coding errors  (Lim, 1994; Aggarwal et al. , 2002; Boehm and Basili, 2005; Buse and Weimer, 2010; Börstler et al.
It is also necessary to perform additional initialization steps at the beginning of the experiment. Another lab might be equipped with a high-end soundcard for auditory stimulation and a Labjack device (Labjack Corporation, Lakewood, United States) for triggering. In this case, sound needs to be controlled via PortAudio  (Bencina and Burk, 2001)  while triggers are controlled via the library specific to the device. The experiment is most probably developed and tested on an ordinary desktop computer or laptop without any specialized equipment. If only the PTB is used, the user would face the following two challenges: (1) the experiment would need to determine what devices are connected to the computer and execute the code specific to the hardware found and (2) in-depth knowledge about how the devices work and differ, sometimes on a low level, is needed to ensure a reliable and correct experiment.
A high level toolbox should enable the user to write source code that is as agnostic as possible to the underlying hardware. This not only increases the flexibility of the source code, but also reduces the amount of code and its complexity, which leads to higher quality, less error prone code  (Lim, 1994; Aggarwal et al. , 2002; Boehm and Basili, 2005; Buse and Weimer, 2010; Börstler et al. , 2016).
The Audio Subsystem The low-level commands to control sound hardware as well as the format of the data that it can process vary a lot between devices. It is thus not possible to design a common, transparent, hardware-agnostic interface, while still allowing users to use the low-level commands provided by the Psychophysics Toolbox. Instead, the o_ptb provides a set of audio stimulus classes providing the capability to load a stimulus from a wav or mp3 file, use the content of a MATLAB matrix or generate white noise or a sine wave. These sounds can be processed in numerous ways, including frequency-filtering, windowing, and vocoding (see Figure  4 ). The sound objects can then be scheduled to play at a certain point in time. This reference time can either be the next explicit screen flip to ensure maximum audio-visual synchronization (see Figure  5 ).
Stimuli Are Objects One of the most common tasks of an experiment script is the presentation of stimuli. For instance, a visual stimulus might be an image or movie loaded from the hard drive, a geometric shape or a text. An auditory object might be a sine-wave, white noise, the sound-data read from a wav or mp3 file or a MATLAB matrix. After some manipulation or processing, they are either placed on the screen for a specified amount of time or played via the audio subsystem. It thus seems natural to think of stimuli as objects and an intuitive toolbox written for humans should thus match that representation. Object-oriented programming is a software development paradigm that is ideally suited for this kind of representation. Within the realm of the o_ptb, every visual and auditory stimulus is represented by an object.
It also provides sensible defaults for most settings and runs plausibility checks to prevent common errors (see Figure  7 ). In the remainder of this article, the o_ptb will be used to assess the temporal accuracy of two different hardware setups available at the University of Salzburg. While one of these setups provides the complete set of VPixx products for visual and auditory stimulation as well as triggering, the second system uses the internal video and soundcard of a PC running on Linux and a Labjack U3 USB device (Labjack Corporation, Lakewood, United States) for the triggers.
GENERAL REQUIREMENTS AND INSTALLATION The o_ptb is a toolbox running on MATLAB 2016b or higher (The MathWorks Inc. ). It requires a current version of the Psychophysics Toolbox. It only uses functions provided by MATLAB and the PTB at its core. It thus works on Windows, Mac, and Linux. Certain devices that can be used with the o_ptb might need further software and/or drivers installed on the system. As these drivers might not be available for all platforms, some restrictions might apply. The o_ptb is released under the General Public License 3 (GPL; Free Software Foundation, 2007). The latest version can be downloaded at https://gitlab. com/thht/o_ptb. Assuming that MATLAB and the PTB have already been installed on the computer, it is sufficient to copy the contents of the o_ptb to an arbitrary folder on the computer's hard drive.
, 2007). The stimulation was run on MATLAB 2019b installed on Debian Buster. We tested two hardware setups: The first was a HP 802E with a NVidia Quadro K620 graphics card running at a refresh rate of 120 Hz. This computer was attached to a VPixx System (DATAPixx2 display driver, PROPixx DLP LED Projector by VPixx Technologies, Canada). The VPixx devices were thus used for auditory stimulation and triggering as well as the synchronization of those to the visual stimulation. As the system is used to conduct experiments during which data is acquired by a magnetoencephalograph (MEG), sound was delivered via air-tubes (approximately 5. 6 m length), introducing a physical delay of 16. 5 ms. The second was an HP Elitedesk 800 with a NVidia GeForce GT 730 graphics card connected to a ASUS VG258 Monitor running at 120 Hz.
Sound was emitted via an Intel 8 Series C220 internal sound card. Trigger emission was done using a Labjack U3 device (Labjack Corporation, Lakewood, United States). Despite the highly different hardware configuration of the two systems, the o_ptb allowed us to use exactly the same script on both machines. The data were analyzed using pandas  (Reback et al. , 2020 ) running on Python 3. 7. For each trial, the difference between all three onsets (visual, auditory, and trigger) was calculated. Finally, the mean and the SD for the differences of each pair were calculated.
DISCUSSION The development of experiments is a challenging task for a researcher. The o_ptb presented here not only simplifies this important task by providing a unified interface to hardware used in the experiment. It also adheres to proven principles like code reuse, high level of abstraction, and easy to read code that has been shown to reduce the likelihood of errors that could jeopardize the validity of the results and interpretations of a study  (Lim, 1994; Boehm and Basili, 2005; Buse and Weimer, 2010; Börstler et al. , 2016). This is achieved by adding an additional layer of abstraction between the source code of the experiment and the Psychophysics Toolbox  (Brainard, 1997; Pelli, 1997; Kleiner et al. , 2007)  and further low-level libraries, like PortAudio  (Bencina and Burk, 2001) , the VPixx interface (VPixx Technologies, Canada), and the Labjack exodriver (Labjack Corporation, Lakewood, United States; see Figure  2 ).
This means that the source code does not interact with the devices and their libraries directly. Instead, it interacts with the unified high-level interface provided by the o_ptb that then takes care of the low-level interaction. Additionally, the o_ptb provides stimulus classes for the auditory and visual subsystem providing common operations like frequency filters for the auditory and scaling and positioning for the visual subsystem. The source code comparisons shown in Figures 3-7 illustrate the advantage of the high level approach of the o_ptb. The source code is shorter and less complex when the o_ptb is used because hardware differences are processed "behind the scenes. " It is also easier to read the source code and infer the intention of the user because intuitive names are used. The MATLAB source code used to assess the accuracy of stimulus presentation (available online, see Methods) is another ideal showcase of the benefits of the o_ptb.
Although both stimulation systems use different hardware -one providing a VPixx based setup, the second one running on standard PC components plus a LabJack for triggering -the exact same code was used to run the test stimulation. The results of these tests show that both systems offer sub-millisecond accuracy. Using the VPixx system leads to a further increase of accuracy by a factor of 3-8. Yet, these results are not directly comparable because the availability of the VPixx system was not the only difference between them. Besides differences in the hardware of the computers, the most significant differences between the systems are (a) the use of a projector vs. an LCD monitor and (b) sound delivery via air-tubes. The purpose of this test was thus not to compare these two systems but to show that adequate accuracy can be achieved with and without specialized hardware as long as the configuration and the code of the experiment is of optimal quality, as ensured by the o_ptb.
After almost 4 years of active development and use in peerreviewed studies  (Hartmann and Weisz, 2019; Hauswald et al. , 2020; Sanchez et al. , 2020)  and current pre-prints  (Suess et al. , 2020; Weise et al. , 2020) , the o_ptb has evolved into a stable, mature toolbox. It is extensively documented 1 and includes tutorials to provide a smooth experience from the beginning. To summarize, the o_ptb facilitates and optimizes the development of experiments, leads to better readable and more reusable source code and thus reduces the probability of errors. It enables users to create experiments that run on a variety of platforms without changes to the code and without any device specific sections in the code.
DATA AVAILABILITY STATEMENT The datasets presented in this study can be found in online repositories. The names of the repository/repositories and accession number(s) can be found in the article/Supplementary Material. The code of the timing experiment can be accessed at: https://gitlab. com/thht_experiments/blackbox_tester/-/tree/article and the data and the analysis code of the timing experiment can be accessed at: https://gitlab. com/thht/blackbox_tester_ usbstim/-/tree/article.
The 2016 Computer Engineering [1] and the 2017 Information Technology [2] curricular recommendations comment on AR as follows, "the computer engineering/IT curriculum should allow exploration of new inventions that have yet to emerge as viable technologies. For example, teachers might encourage exploration of ways in which a computer engineer would design environments involving augmented reality and virtual worlds or ways in which big data and data analytics might affect the work of a computer engineer. " The 2013 computer science Bachelor's education report [12] includes AR as part of a human-computer interaction course. The other subject recommendation reports do not mention AR at all. 1  https://www. acm. org/education/curricula-recommendations With this work, we seek to remedy this situation.
We are not aiming to be exhaustive and cover all AR courses available, but try to identify specific aspects of good practice and highlight specific common issues people will face when implementing an AR course module into their regular teaching cycle. We therefore used a soft inclusion criteria of AR-specific content covering at least 30% of a course and the availability of the course description online. We started by conducting a search on a global online aggregator of study programs, Masterportal  4. The search for a key phrase "Augmented Reality" returned 98 results. For each result, we tried to find an official university web page with course description. After the review of the results, only 10 courses were selected. We then searched online using several major search engines and several key phrases, including combinations of "Augmented Reality", "Mixed Reality", and "Extended Reality" with "Course" and "University".
This course focuses on the design and evaluation of XR systems. The topics covered in the course include delivery systems, interaction in XR, psychological aspects, XR evaluation techniques, marker-based AR and tracking, and mobile application development. The courses of the study program include game development, 3D modeling and 3D printing, CG software fundamentals, and Unity platform. A final example is the Augmented Reality Design: Principles and Practice course offered in the Film and Media study program by the Department of Media Design and Technology at the University of Bradford  13. The course focuses on the design and development of marker-based and location-based AR applications, covering the topics of programming, AR development tools, object recognition and tracking, geolocation, multiplatform development, standards and workflows, AR storytelling, creating 3D assets, and ethical issues.
The content focuses on the creation of AR apps using Xcode and the Swift programming language. It covers topics such as user interaction, input and system controls, app design, HCI, closures, animation, and issues of communication with the web and concurrency. 34 https://web. archive. org/web/20200913185035/https://www. edx. org/course/workwith-augmented-reality-ar-and-the-web A similar but shorter offering, 'Getting started with Augmented Reality' is a course offered by Institut Mines-Télécom on Coursera  35. The course offers 19 hours of content (below our exclusion criteria) and contains four modules, covering the introduction of AR concepts, including typical architectures of AR apps, the ARAF format  36  , AR SDKs and location-based AR. The course offers three practical exercises developing mobile AR applications using ARAF.
Commercial Offerings A wide number of courses and tutorials on AR can also be found on commercial websites. Searches for AR on Udemy, a teaching and learning marketplace, returns 60 results, of which only three are longer courses devoted specifically to AR. The lengthiest course identified on a commercial platform was the Udemy 'Learn 3D AR technology with Xcode and Python!', which is aimed at beginners and offers 100. 5 hours of instruction  39. Relying on more than 100 videos, 327 lectures, 51 articles and 43 downloadable resources, the training takes a coding approach to AR development. It does so by introducing coding in Xcode, Python, HTML, CSS, C#, and R. The focus rests mainly on providing an introductory understanding of these programming languages and on information visualisation, rather than on delving deeply into AR development.
The Interaction Design Foundation offers an 18 hour course How to Design for Augmented and Virtual Reality 40. The course is offered by an online provider that focuses specifically on design education. It covers both theoretical and practical aspects of the HIC perspective on AR, including the topics of storytelling, UX and spatial UI, and multimodal interaction and designing content, such as 3D characters. Microsoft, the maker of HoloLens, also offers a number of courses in AR 41. These can be classified as tutorials, each being dedicated to a specific aspect of working with the HoloLens, such as instruction on gesture, gaze, voice, motion controllers, spatial sound, or spatial mapping. Introductory training on game engines such as 'Getting started with Unity' or the Unreal engine is also the focus of other modules.
Professional communities and networks are also becoming engaged in teaching AR. VR First in cooperation with the AR industry has built an XR curriculum to be taught in a coding bootcamp format  44. The program includes an introduction to XR and three sets of practical electives on AR/VR development (Unity, programming, agile development, version control), real-time 3D art (basics of computer graphics, 3D modeling and animation), and UI/UX and game design (interaction design, storytelling, UX and UI, game design, UX evaluation, and optimization). The program also has a strong focus on the industrial cases, workflows and production. It is clear that despite a wealth of short tutorials, the offering of comprehensive AR courses online remains limited, and within this selection no clear curricular trend emerges.
Lesson Plans The suggested curriculum is broken units of lectures and practical tutorials. Lectures in general are conceptualised to cover theory and foundations, while the tutorials are expected to complement them with selected practicals. For example, a lecture on evaluation would cover a broad overview on AR-relevant HCI methodologies and all relevant detail for key methods, whereas the practical tutorial would pick one or two key methods and practice their application from administering the questionnaire to data analysis and representation. In the provided recommendation, we also divide all units into three types used in the ACM curricula recommendations: must, should, and supplementary. The core units cover topics and involve practices that all students must learn and experience. These units are marked with [••••] next to their titles.
Tutorial 9 [••••] Gaze Interaction. This tutorial includes a detailed presentation of the concept of Gaze interaction and how gaze interaction is used to select objects. The tutorial will teach how to implement gaze interaction using prewritten scripts provided by the MixedRealityToolkit. Tutorial 10 [••••] Gesture Interaction. The tutorial explains how to add gesture recogniser, add tap events, manage with hands visible and tracked by Hololens, and gives a framework for deeper understanding of hand tracking and gaze outputs. Tutorial 11 [••••] Voice Interaction. The tutorial describes the basics of how spatial sound can add realism, direct the users gaze, and provide gesture feedback by creating simple voice commands and sounds of AR objects interaction in AR engines, such as Unity.