dataesr/scientific-paragraphs-categorization huggingface dataset:
The impact of propagating code changes in terms of data transferred between the debugger and application process 4. The performance overhead of IDRA on the target application system Setup The benchmarks were executed on two different machines: the debugger machine, the machine where the debugger is deployed, and the worker machine, the machine where the application is deployed. Both machines are a four-core Intel® Core™ i7 Processor at 3. 5 GHz with turboboost, and 16 GB RAM DDR3. Both machines run Apple macOS (version 10. 13. 4) with Pharo 7. 0+alpha (Build 848), 32 bit. They are connected through a WiFi 2. 4 GHz local network. All benchmarks that compare IDRA with TelePharo employ the Twitter analyzing application described in section 2. 1 where we read tweets from a file, parse them and create an instance.
Overhead of propagating code changes To assess the performance of handling changes in out-of-place debugging, we compare the overhead of IDRA and TelePharo when transferring code changes. Both debuggers employ very different approaches to handle code changes. In IDRA, changes happen locally and are then sent to the remote machine through the IDRA Changes Handler in a single network transmission when the user explicitly performs a commit. In contrast, in TelePharo the user directly modifies via a remote browser (or a remote debugger) the classes of the remote machine, and changes are directly applied to the application process. In this benchmark we compare the network overhead of triggering a code change in the remotely debugged application. For different code changes, we measure the bytes of propagating: No operation.
No changes are made. A browser is opened and changes are sent A class addition. A class named Test01 is added to a package An instance variable addition. An instance variable named instanceVariable is added to Test01 A class variable addition. A class variable named classVariable is added to Test01 A method code change. A method of the class Test01 is changed adding a line of code Results Table  3  shows the amount of bytes (in KB) used to remotely apply single code changes. The network overhead when not changing code is approximately the same, showing no significant difference between both debuggers. In all other operations IDRA uses 8 to 10 times less network when compared to TelePharo for simple committing operations. Since TelePharo uses a remote browser (stand-alone or included in the remote debugger), every modification constantly generates a request to the remote image to update.
This does not happen when using IDRA because the changes happen first in the local code base, and then are packaged and transferred to the remote image, resulting in less communication overhead. In order to quantify the impact of IDRA on a running application, we compare the execution with and without an active IDRA instance in the worker machine. To this end, we run the Computer Language Benchmark Game  [35]  in the implementation available for SMark  [22] , a benchmarking framework for Pharo. Such benchmarks measure the performance of the overall system applying common programming problems such as n-body, K-nucleotide and thread-ring. We measure the overhead of both the IDRA Monitor, and the IDRA Changes Handler.
2. This debugging scenario shows the challenges when debugging a modern application which analyses a continuous stream of data and is running on a resource-constrained device which may not be accessible to the developer. The scenario steams from an unrelated research project whose goal is to program and debug CPS applications in Pharo conducted by Costiou  [5]. During the presentation of that work, the main developer reported problems when debugging the temperature monitoring application deployed remotely on a raspberry-pi with TelePharo. We then collaborated together in a case study to assess whether IDRA could help him to find the root cause of his bug. This case study allows us to gain initial insights into how the key properties of out-of-place debugging (i. e. low debugging latency and scoped size effects) can help debugging modern applications.
Debugging experience using IDRA With IDRA, the developer was able to debug his application locally at his machine starting from the original exception, experiencing low latency on the debugging operations. During the debugging he changed the code and tested it locally before deploying it back into the remote machine. Most importantly, he avoided crashing the application on both his local and remote machine. As a result, his debugging experience in comparison to TelePharo was improved and he found out the root cause of his bug: in some occasions the sensor was returning a string containing "nan" instead of a concrete value, meaning that the sensor read from the external driver failed. Such value was parsed as a number, causing a parsing exception. Besides fixing the bug in the monitoring application, the developer also used IDRA to debug different applications running on his remote machine, from an unique centralized point.
However, it transfers information using an intermediate log, and allows developers then to debug in a fresh post-mortem environment. Daphne  [19]  is a debugger for DryadLINQ  [26]. It provides a runtime view of the system and the query nodes generated by a LINQ query. It allows developers to add breakpoints to inspect the state and start and stop commands through the Visual Studio remote debugger. Debugging is done directly on the client where the breakpointed node is executing, interrupting it in order to debug it. Execution of a specific node can be replayed locally to analyze its execution using the same debugging primitives. BigDebug  [16]  is a debugger for Apache Spark  [10]  which introduces the concept of simulated breakpoint that does not stop the execution nor freezes the system waiting for the resolution of the breakpoint.
Conclusion In this paper we presented out-of-place debugging, a novel online debugging architecture that allows developers to debug remotely, keeping the debugging experience of in-place debugging. It does so by transferring the entire state of the program execution (application objects and call-stack) to a different process executing on the developer's machine. Since the debugging operations apply locally, our approach minimizes the latency created by network communication and scopes all the side effects to the local debugging process. We prototyped our approach implementing IDRA, an out-of-place debugger for the Pharo Smalltalk programming platform. Our implementation handles external resources by the usage of object replacement during serialization and code instrumentation using metalinks.
Acknowledgements We would like to thank the anonymous reviewers for their constructive comments. We would also like to thank  Jennifer Sartor ,  Clement Bera ,  Carmen Torres Lopez  and  Pablo Tesone  for their help reviewing early versions of the paper. Matteo Marra  is a PhD-SB fellow at the  Fonds Wetenschappelijk Onderzoek -Vlaanderen  -Project number:  1S63418N. We are also grateful to the financial support of the  European Smalltalk User Group  (http://www. esug. org).
DISCUSSION AND FUTURE WORKS The simulation of this paper is based on NetLogo. NetLogo is a language and an IDE (integrated development environment) focused on MAS, allowing to easily create graphs, animations 2D/3D. The main reason to choose NetLogo is the simplicity for creating a prototype allowing fast results. One of the disadvantages of NetLogo for our work is that the centralization of information about the device consumption cannot be done. In the last simulation, each device had to take decisions alone, only based on the global consumption. The best way to centralize information would be to create an agent with such a role. JADE allows the attribution of more specific tasks for each agent, with a more important consumption monitoring, and more interactions between devices. This representation is more realist, it's easier to implement a device controller than to implement a controller on each device.
In this article, we present the flight radius problem on the condensed network. This problem consists of locating in the network what routes represent business opportunities that are attractive regarding time or cost criteria, and passing through a specific flight. We introduce a regret function to model the regret compared to the optimal value of such criteria. We work with a startup company specialized in air transportation. The company has developed a decision tool for airline managers to analyze and simulate a new market. Our problem is derived from this application. Thus, we start by formulating the problem as finding a maximal sub-graph such as for each node, there exists a valid path by the regret function. Then, we propose two methods for solving the problem. One using procedures of the graph database Neo4j where the condensed network is stored.
In such network, we just consider the transfer time without checking if the route is viable. Hence, for an airline managers, what is the relevant subnetwork related to a given flight? What are the passengers origins and destinations? The flight radius problem is formulated as a problem of finding a maximal subgraph in terms of nodes. We constructed the condensed flight network from the company flight database using the time-independent approach and stored it in Neo4j the graph database since the current database presents some limits  (Neo4j, 2017). The problem can be solved using the shortest path algorithms to find the maximal subgraph of the graph. The output subgraph contains paths that are longer than the shortest path with a certain regret, and passing through the specific arc. In this paper, we propose an algorithm to solve the problem of flight radius.
CONDENSED NETWORK The condensed network is generated from a NoSQL database and stored it in Neo4j the graph database using a time-independent approach. It is one of the most popular graph databases where queries can easily be expressed through Cypher query language. Neo4j is used in many use cases, typically recommendation systems and complex networks like transportation network. In Neo4j, data are represented in nodes, relationships, and properties. Both nodes and relationships contain properties  (Robinson et al. , 2015). A relationship connects a pair of nodes, it has a direction, type, a start node, and an end node. In the company's database, data are collected and queried monthly then it makes sense to create a relationship per period which is a month of the year. the relationship represents flight information.
We dispose of historical data about the last fifteen years. The current database used is a MongoDB database that stored data in a disconnected way. This database does not use a graph structure. Therefore, we opt for the graph database Neo4j as another alternative database to overcome the limits of the existing database (Neo4j, 2017). Neo4j uses a graph structure that regroups data and allows visualizing what happens in the network when creating a new route or deleting an existing route. Furthermore, this graph database performed well on the graph traversal since our study is based on such algorithms  (Holzschuher and Peinl, 2014). The graph database Neo4j offers the possibility to implement algorithms as user defined procedures to call in Cypher query. That is can be easy to use it by the final user.
A Query-Based Solution In the earlier section, we proved that the search of valid paths can be restricted to finding valid shortest paths. The problem was solved in Cypher query using the algorithm BIDIRECTIONAL DIJKSTRA implemented in Neo4j as a procedure in APOC  (Larsson, 2008). In Neo4j, we use a parametrized query. The parameters are: o code and d code to specify o and d, rel to identify type of relationship to traverse, criterion for time or cost, and K determines the regret. The query described in 1 contains three major blocks. The first block of the query includes the first three lines. The MATCH clause is used to match the graph pattern which is the arc (o, d) using the supplied parameters. The second block contains the call of the algorithm. Then, the procedure DIJKSTRA is called from the origin o to all other airports A in the graph in order to find the shortest path in terms of time, and finally gets the shortest paths from the destination d.
04. 2 with 32 GB of RAM and one Intel Core i7-3930K 3. 20GHz processors (6 cores). The implementation is based on Neo4j and APOC version 3. 2. 0. 1. Test Instances. Tests on real-world data were realized on the database of the company. To test the method based on a query, we use 6 instances for the problem, each one of them represents a flight with a different type of airport: hub & Spoke and using different value of the parameter K of one criterion. This parameter is chosen according to the minimum connection time M CT , and the median of each criterion. We compute the value of the parameter K according to the median, the first quartile, and the third quartile. In this way, we can measure the spread to describe the variability in each criterion with conjunction with the median as a measure of central tendency.
CONCLUSION This work presents the flight radius problem. We formulated the problem as finding a maximal subgraph, in terms of nodes, such that each node supports a valid path by the regret function. To represent the regret function, we focused in the additive case. In the multiplicative case, the problem seems to be hard to simplify since the regret parameter K depends on the shortest path. Then, we presented two methods to solve the problem. Method using procedures of Neo4j the graph database where the condensed graph is stored and, the method based on a new algorithm that relies on Dijkstra algorithm. Studied instances in this article were realized on the realworld network. The algorithm outperforms the query method and the choice of the parameter K influences the running time of the algorithm.
A speech synthesis system would require interpolation in order to produce an intonation pattern for the whole utterance. The f0 targets are expressed in quarter tones: f0[ 1 /4 tones] = 24 log 2 f0[Hz] f0[Hz] , (1) where f0 is the speaker specific reference f0, usually the median f0. Duration is analysed in terms of the compression/expansion ratio coefficient of the RU  [4, 15, 13]. The ratio is calculated according to: RUratio = dRU -dRU dRU , ( 2 ) where dRU is the measured and dRU is expected duration of the RU calculated as: dRU = (1 -α) p i ∈RU dp i + αDCLK. (3) Here, DCLK is the isochrony clock, i. e. the average RU duration for the database, and α is a coefficient that reflects the tendency towards isochrony of the language, i. e. the weight of the clock.
PySFC The PySFC comprises a self-contained and fully functional ecosystem of tools for the analysis of prosody with the SFC at its core. These tools are, for the most part, used for working with the data and plotting. Python was chosen as an implementation language because of the powerful scientific computing environment that is completely based on free software and that has recently gained power and momentum in the scientific community. To enhance the accessibility of the PySFC, great attention was put on code readability, augmented with detailed functions docstrings, and comments. The system has been licensed as free software and has been made available on GitHub 1.
Modules PySFC comprises the following modules: • sfc. py -main module that controls the application of the SFC model to a chosen dataset. It is responsible for using all of the other modules to read the data, train the SFC model on it and output plots and statistics. • sfc params. py -parameter setting module that holds all the users settable parameters including: data related parameters -type of input data, phrase and local level functional contours, -SFC hyperparameters -number of points to be sampled from the pitch contour at each vowel nucleus, pitch and duration coefficient scaling coefficients, number of iterations of analysis-bysynthesis, as well as the number of hidden units, learning rate, maximum number of iterations and regularisation coefficient for the NNCGs, -SFC execution parameters -use of preprocessed data, use of trained models, etc.
• sfc corpus. py -holds functions used to work with the data corpus that the SFC model directly works with. This includes feature extraction from the input data and the output predictions of the SFC. • sfc data. py -comprises functions that read the input data files and calculate the f0 and duration coefficients, as well as calculate intonation, and phone and syllable duration statistics. • sfc learn. py -holds the SFC training functions based on machine learning. • sfc dsp. py -holds DSP functions for smoothing the pitch contour. • sfc plot. py -holds the plotting functions that are used to plot the data analysis, synthesised SFC contours and SFC performance. The size of these modules can be seen in terms of lines of code shown in Fig. 1. The plot shows that the core functionalities of the SFC are only a small part of the PySFC ecosystem, with the majority of code going into the necessary tools for working with the data, and to a lesser extent into the plotting functionalities.
Databases In order to assess the functionality of PySFC, two databases were used. One comprising emphatic speech in French focused on speaker attitudes uttered in various syntactic organisations and lengths of constituents, and the second comprising read Chinese: • db morlec -a database of 6 attitudes in French: declarative (DC), question (QS), exclamation (EX), incredulous question (DI), suspicious irony (SC) and obviousness (EV)  [4]. In total 1932 utterances were recorded from a single speaker. • db chen -a database of two attitudes in Chinese: declarative (DC) and question (QS)  [7]. In total 110 utterances were recorded from a single speaker.
Performance plots Expansion plots for the functional contour generators can be used to assess the validity of the training results. Fig. 6  shows example expansion plots for db morlec for the assertion DC, question QS, incredulous question DI, and obviousness EV attitudes and the DG functional contour, which signifies a dependency to the left between two syntactic units. In the expansion plot we can see how the generated contours change with expanding left and right contexts. The numbers next to the contours show how many scopes of that kind have been found in the database. We can see that the DG plot contains two scopes that were not found in the data, but that are successfully generated by the trained NNCG. PySFC also allows for plotting the loss in terms of error of the SFC reconstruction.
Conclusions PySFC is a self-contained prosody analysis system based on the SFC model implemented in the scientific Python ecosystem. The main goal of PySFC is enabling access to the SFC for the broader scientific community, but also serving as a platform to facilitate further development of decompositional prosody models. One improvement that is already incorporated is the possibility to choose the number of samples taken from the vocalic nuclei. Another is the inclusion of the concept of gradience that allows for different amplitudes of each contour generator in the final sum contour. Different ways can also be explored for the distribution of the error among the NNCGs in the analysis-bysynthesis loop. The PySFC system will facilitate the rapid development and assessment of these ideas.
Context. The consortium of the Spectro-Polarimetric High-contrast Exoplanet REsearch installed at the Very Large Telescope (SPHERE/VLT) has been operating its guaranteed observation time (260 nights over five years) since February 2015. The main part of this time (200 nights) is dedicated to the detection and characterization of young and giant exoplanets on wide orbits. Aims. The large amount of data must be uniformly processed so that accurate and homogeneous measurements of photometry and astrometry can be obtained for any source in the field. Methods. To complement the European Southern Observatory pipeline, the SPHERE consortium developed a dedicated piece of software to process the data. First, the software corrects for instrumental artifacts. Then, it uses the speckle calibration tool (SpeCal) to minimize the stellar light halo that prevents us from detecting faint sources like exoplanets or circumstellar disks.
g. ,  Boccaletti et al. 2015; de Boer et al. 2016; Ginski et al. 2016; Lagrange et al. 2016; Maire et al. 2016a; Mesa et al. 2016; Perrot et al. 2016; Vigan et al. 2016; Zurlo et al. 2016; Chauvin et al. 2017; Bonnefoy et al. 2017; Feldt et al. 2017; Maire et al. 2017; Mesa et al. 2017; Samland et al. 2017). The good performance to date results from the stability of the instrument over time and a dedicated and sophisticated software for data reduction. The SPHERE reduction software uses the data reduction handling pipeline  (DRH, Pavlov et al. 2008 ) that was delivered to ESO with the instrument as well as upgraded tools optimized using the first SPHERE data to derive accurate spectrophotometric and astrometric calibrations  (Mesa et al. 2015; Maire et al. 2016b). The software that is implemented at the SPHERE data center  (Delorme et al.
2017b ) first assembles tens to thousands of images or spectra into calibrated datacubes, removing or correcting for instrumental artifacts. This includes image processing steps such as flat-fielding, bad pixels, background, frame selection, anamorphism correction, true north alignment, frame centring, and spectral transmission. The outputs of these first steps are temporal and spectral sequences of images organized in datacubes with four dimensions hereafter: coronagraphic images and the associated point-spread functions (PSF). Then, the software uses the speckle calibration tool (SpeCal) written in the IDL language and described in this paper. SpeCal was developed in the context of the SpHere INfrared survey of Exoplanets (SHINE), which is the main part of the SPHERE guaranteed observation time (GTO) and is now used to process all SPHERE data obtained with IRDIS and IFS systematically.
In the rest of the paper, we use "spectral channel" to refer to the spectral dimension, and "angular channel" to refer to the angular dimension. Also, we use SDI for both SDI and dual-band imaging. The SpeCal tool was developed so that all the SHINE SPHERE GTO data can be uniformly processed. We remind readers that this tool uses data processing techniques that were previously proposed in the literature. The interest of the tool is that all these techniques have been tested on several datasets to ensure that all the products are consistent (contrast curves, measurements of astrometry, and photometry of detected pointlike sources). SpeCal can process data recorded using ADI, SDI, RDI, or the combination of ADI and SDI that is called ASDI hereafter (see Table  1 ). When SDI or ASDI is chosen, the frames I(x, y, θ, λ) are spatially scaled with wavelength to compensate for the spectral dispersion of the speckle position and size, the reference wavelength being the shortest one.
The SPHERE PSFs are usually close to two-dimensional Gaussian functions (η = 2) but can deviate from them. In the context of SHINE, PSFs are usually recorded before and after the coronagraphic sequence. SpeCal calculates the best fit to each of the PSFs (∼ 50x50 pixels) and runs two tests on the time series of fitted parameters. First, it works out the average and standard deviation of the normalization factor β over time, records the two values, and sends a warning if the flux of the star β varies by more than 20 % between distinct PSF observations of the target. Then, it sends a warning if the background level α is larger than 10 % of β. These values (10 % and 20 %) were defined as quality requirements based on our experience with the instrument and the analysis of hundreds of datasets. Finally, SpeCal estimates and records the PSF fwhm.