dataesr/scientific-paragraphs-categorization huggingface dataset:
Within the context of the REVERIE project, an avatar reasoning framework has been developed that serves to model the mind of a virtual human as well as analyzing the captured data from a real human and modeling the interaction between virtual and real. This framework allows people to be represented in an Internet based virtual world. This component brings accuracy of the behavior of avatars and agents as being the most essential element of feeling immersed. The architecture of the avatar reasoning framework that supports the use case presented in the Introduction is shown in Fig. 8. The different instantiations of each class of component that show up reflect the multi-modality required for REVERIE, each instantiation dealing with a specific aspect of human behavior. Analyzer modules receive input from external data capturing components and perform basic processing on the incoming data, ranging from transformation of data to gesture recognition; it does not include interpreta- Each user's semi-autonomous avatar will learn from their user's input to allow the avatar to act independently in certain scenarios  [10].
This enables an immersive navigation within the image dataset that is perfectly equal to -and thus as rich as -original images when viewed from their viewpoint location, and which degrades gracefully in between viewpoint locations. Beyond proving the applicability of this preprocessing-free computer graphics technique to mobile mapping images and LOD1 3D city models, our contributions are three-fold. Firstly, image distortion is corrected online in the GPU, preventing an extra image resampling step. Secondly, externally-computed binary masks may be used to discard pixels corresponding to moving objects. Thirdly, we propose a shadowmap-inspired technique that prevents, at marginal cost, the projective texturing of surfaces beyond the first, as seen from the projected image viewpoint location.
Context Mobile mapping systems are now commonly acquiring image and Lidar datasets with direct georeferencing. The image datasets alone provide a vast amount of geometric and radiometric details. Realizing a 3D city model that matches this level of detail is still a tedious and errorprone task, despite the research efforts to model street scene objects such as traffic signs, facades, trees and street furnitures. The number and variability of these objects make completely modeling such a scene impractical for all but simplest scenes. There is however a number of applications that would benefit from navigating seamlessly and continuously within the mobile mapping images : urban planning, tourism, immersive navigation, augmented reality. We are interested in a method that satisfies the following requirements: Real-time rendering with unconstrained navigation: This is required to offer a navigation with a high degree of immersion with a viewpoint that may move continuously.
Binary Masking for Moving Object Filtering As the proposed application is to visualize a traffic simulation in augmented reality, moving objects such as vehicles or pedestrians, which are captured during the mobile mapping acquisition, have to be cut out of the projected textures, leaving holes that will have to be filled in by sampling nearby textures. The results shown within this paper (fig. 3   objects, as it not the main focus of this paper. Enabling the filtering of moving-labeled pixels may be done at texture upload time without any shading time cost. This is done by adding an alpha channel and making discard-labeled pixels transparent or as a preprocess by actually saving this image as RGBA (or even as RGB with a special value encoding binary transparency). The former option has the advantage of conserving the original data at minimum expense, as the label image is highly compressible.
Shadow artifacts are present around the removed cars which may be addressed, as a future work, by enlarging the masks to also include the shadows or by using a gradient-based image fusion  (Pérez et al. , 2003). Recently Used (LRU) cache policy enabling a constant texture memory footprint and a fast startup time. Indeed, only the point cloud of image locations is loaded from disk or streamed from the network in the initialization phase to construct the Kd-tree. Using tiling of the image location Kd-tree and of the scene, this would enable navigation within a virtually infinite dataset. The next step is to compute the resulting color of synthesized pixel out of the K potential RGBA color samples (ci)i=1. K from the K nearest projective textures. We propose to simply blend them together with linear weights (wi)i=1.
Results, Implementation Details and Discussion The proposed method has been implemented with the OpenScene-Graph rendering engine. Projective texturing a single texture ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume II-3/W3, 2013 CMRT13 -City Models, Roads and Traffic 2013, 12 -13 November 2013, Antalya, Turkey is conceptually identical to shadow mapping from a point light source projecting the acquired image. Thus the implementation follows closely the osgShadow module and its ShadowTexture shadow mapping technique. There is no restriction on the scene that is to be rendered as it only requires a custom fragment shader that may be applied to any type of geometry. The figures of this article have been generated with 8 simultaneous projective 1920x1080 textures with polynomial distortion corrected on the fly (figure  2 ), using an NVIDIA GTX480 GPU.
CONCLUSIONS AND FUTURE WORK To conclude, we have proposed an image-based rendering technique that relies on projective multi-texturing that is able to handle occlusions, non-perspective distortions and binary masking. This rendering has been augmented with the 3D visualization of a 2D traffic simulation to show an example visualization application. We are currently working on dealing with the uncertainty of the datasets, such as an imprecise georeferencing of the images or the specified accuracy of a 3D city model. In this context,  Taneja et al. (2013)  proposes an approach to improve the registration of the georeferenced images. Disregarding this uncertainty yields displacements due to parallax effects when the depth of the scene geometry is not accurate. This uncertainty may be visualized as a 1D blur of the projective texture in the parallax direction  (Eisemann et al.
In this form of programming, a driver developer starts with driver code for a related device, makes a copy, and then adjusts the copy according to device-specific information. In order to understand this phenomenon, a number of studies have applied code clone detectors to Linux code  [6, 10, 18]. However, knowing the amount of duplicated code, as often reported in research papers, or the set of fragments of duplicated code, as reported by code clone detection tools, is not very helpful in understanding how to create a driver. Instead, what is needed is a way to justify which fragments of an ex-Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page.
Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm. org. PLOS'13, November 03 -06 2013, Farmington, PA, USA. Copyright c 2013 ACM 978-1-4503-2460-1/13/11. $15. 00. http://dx. doi. org/10. 1145/http://dx. doi. org/10. 1145/2525528. 2525536 isting driver should be selected, to achieve what functionality. Our thesis is that the set of code fragments included in a device driver is determined by the set of features provided by the device and the target machine, and by developer choices in terms of the use of OS and support libraries. Furthermore, we posit that these features are reflected by the data structures manipulated by the driver.
Put another way, we view the code fragments that make up a driver as being drawn from a set of genes that support the various possible features of a device. A gene is a sequence of related, possibly noncontiguous code fragments that realize the functionality relevant to a feature. We view the construction of a driver as the process of selecting, adapting, and, if needed, interleaving these genes to achieve a desired effect. Thus, when a driver developer copies some existing code, he replicates some genes and deletes others, that do not correspond to the features of the target device. In this paper, we perform a preliminary investigation of this thesis. For this, we manually identify a part of the driver genome, and then study the dispersal of these genes within a driver population. In the context of this preliminary work, our experiments focus on the probe functions of Linux ethernet platform drivers from Linux 3.
Linux Platform Driver Probe Functions To limit the amount of code to study in this preliminary work, we consider only the probe function entry points of Linux ethernet platform drivers, i. e. , the functions mentioned in the probe field of a platform driver structure of an ethernet driver found in the Linux kernel directory drivers/net/ethernet. A platform driver is a driver for a device that offers direct addressing from the CPU, instead of being attached to a bus such as PCI or USB. In Linux 3. 10, over 1300 Linux driver files for all types of services implement the platform driver interface. Of these, 65, amounting to 77,171 lines of code, 1  are ethernet drivers found in the directory drivers/net/ethernet. 2  The probe entry point is invoked when the device is initialized, to perform any device-specific initializations.
The considered Linux 3. 10 ethernet probe entry points amount to 5,838 lines of code. Roughly a third of these probe functions (20) are from drivers for the Arm architecture, and about a sixth  (12)  are for PowerPC. Figure  1  shows a typical probe entry point. This function performs three basic operations, which we recognize as genes: 1) initializing memory mapped I/O (in red, lines 6-7, 13-16, 25, 27), 2) initializing interrupts (in blue, lines 8-9, 17), 3) connecting the device to the net device support library (in green, lines  10-11, 19-20, 31). Note that the code for initializing memory mapped I/O contains a bug; line 27 should call release mem region rather than release resource. Indeed, the possibility of bugs in the code increases the difficulty of identifying genes automatically, and is one reason why clone detection is not sufficient.
Studying the Driver Genome To evaluate our thesis, we carry out a study in two parts. First, to find genes, we pass over the set of probe entry point functions, to identify common sequences of possibly disjoint code fragments, which we abstract into genes. Then, to study gene dispersal, we pass over these functions again, now with the gene definitions, and count the number of occurrences   2 , with some preliminary tool support. The steps in our methodology are as follows, starting from a set of Linux source code files. In Figure  2 , the result of step n is labeled n. Part 1: Gene identification 1. Identify and extract the probe entry points. For this, we use Coccinelle  [14] , to find declarations of platformdriver structures, and extract the definition of the function stored in the structure's probe field.
2. Identify clones in the probe entry point code. Our assumption is that genes contain code that is common to a number of drivers. We thus use clone detection to highlight likely relevant code, to ease the identification of genes. For clone detection, we use Deckard 3  [5] , which can find clones at any degree of granularity. We put no minimum on the clone size and require clones to be exact matches. Nevertheless, we have substantially changed the strategy of Deckard for abstracting over subterms, mitigating the effect of requiring exact matches. In particular, we have modified Deckard to distinguish function names, structure field names, and case labels, which appears to be essential for accurately treating systems code (cf. [6] ). On the other hand, we abstract over debugging code and error-handling code, which tend to be driver-specific.
3. Subdivide clones, as needed, according to their functionality. Clone detectors report maximal recurring code patterns, regardless of their semantics. Thus, different parts of a clone may relate to different genes. 4. Manually collect the identified code fragments that realize a given functionality into genes. We typically identify a gene as a sequence of code fragments involving common variables, but ad hoc knowledge of the semantics of the OS and OS support functions is also required. Part 2: Gene dispersal evaluation 5. Create Coccinelle semantic patches (pattern matching specifications) that detect occurrences of the identified genes. These semantic patches are designed to identify exact occurrences of the genes, as well as fragments of code that may relate to a gene, but do not match the gene exactly.
The remaining graphs show subsequent extensions to the genome. These extensions have been driven by the goal of simplifying driver code and reducing the likelihood of errors. Figure  4  summarizes the number of probe entry points that use at least one instance of each of these genes. In a few cases, a driver tries both platform get resource and platform get resource byname, but the rest of the code is shared; we count these as two separate gene occurrences. Overall, the gene for memory mapped I/O that is used in Figure  1  is the most common, appearing in 15 files. Most of the other genes only appear in at most one or two probe entry points. Clone detection using any kind of minimum threshold on the number of occurrences of a clone would  thus likely not be sufficient to find the relationship between these drivers.
Related Work Clones. Wang and Godfrey investigate clones in Linux SCSI drivers. On Linux 2. 6. 32. 15, they find clone rates of 10-18% depending on the kind of code considered. They furthermore show that a high rate of clones between two drivers implies that the drivers support the same set of busses, with a success rate of over 80%. This result is consistent with our thesis that driver code is determined by device features. Antoniol et al. [1]  studied clones in various Linux 2. 4 versions. They found few clones across different subsystems, e. g. , arch vs. drivers, but they found clone rates of up to 22. 61% between different architectures. The case of different architectures, may be considered to be analogous to the case of different devices, where the code to address specific features may be in common.
Several clone detection tools have been specifically designed to address the of systems code. CP-Miner  [10] , based on the identification of common subsequences within basic blocks, finds that over 21% of Linux 2. 6. 6 driver code is covered by clones. DrComp  [6]  works at the function level, and finds similarities within 8% of driver code, in Linux 2. 6. 37. 6. These tools identify the presence of clones, but do not explain how this cloned code contributes to the driver structure. In practice, we have found that the code fragments that make up a single gene can be widely separated within a driver. A number of works provide mechanisms to identify so-called API usage protocols, which are commonly occurring not-necessarily-contiguous sequences of operations  [4, 8, 9, 11, 13]. The identified protocols have then been used to construct fault finding rules.
These approaches, however, have do not try to exhaustively infer the protocols relevant to a code base nor do they consider compositions of protocols as a means of describing code structure. Driver structure. Spear et al. [17]  propose a notation for declaring the resource requirements of a device driver, in the context of the OS Singularity. Their declarations are primarily intended for verification, but also trigger the generation of boilerplate code targeting a high-level resource acquisition interface. While this work shares with our work a focus on resources, it does not target legacy interfaces, provide an explanation of legacy code, or address the interleaving of resource acquisitions and device-specific operations. Termite proposes the derivation of a driver implementation from specifications of the OS, the device, and the device class  [15].
Termite specifications are concerned with inputoutput behavior, e. g. , the list of OS entry points called by the OS and the types of results they are supposed to produce, and does not address the kinds of code that are common across driver implementations. RevNic proposes to port drivers based on templates and device-specific values obtained from executing a driver for the same device but a different OS  [2]. Templates must be written manually. The fact that we find that some genes, e. g. for initializing memory mapped I/O, occur different numbers of times depending on device needs suggests that a single fixed template may be insufficient. Feature-oriented programming is a programming paradigm in which a complete software product line is described at once, and specific programs are generated by selecting an appropriate set of features from a formally defined feature model.
Beuche et al. organize an OS as a product line in order to be able to generate minimal, application-specific instances. Later work has focused on configuration. She et al. transform a set of unstructured configuration options into a feature model  [16]. Dietrich et al. take makefile information into account  [3]. These approaches organize existing feature decompositions, rather than identifying features in the code. Kästner et al. mine feature implementations in existing Java code, based on a preliminary manual identification of features and some relevant code fragments  [7]. This work could be useful to us in the future, for identifying gene implementations automatically. Our current focus is on understanding what features and feature implementations make up device driver code.
Conclusion In this paper, we have identified a new way of understanding device driver structure, in terms of the genes that are used in their construction, and identified the connection between the presence of these genes and the set of data structures manipulated by the driver. In this preliminary work, we have focused on the portions of these genes found within Linux ethernet platform driver probe functions. In the more general case, a gene covers all operations related to a given feature, e. g. interrupt management, and can have an impact on any of the operations performed by a driver. In the future, we will expand the genome, increase the degree of automation of our methodology, consider how to identify and specify dependencies between genes, and, ideally, propose a means of automatically generating a device-specific skeleton of a driver implementation from minimal information about the features and requirements of the device.
CDS SERVICES CDS has developed highly successful added-value services: SIMBAD, which summarizes information about astronomical objectsit reached 5 million objects in 2011; VizieR, the reference service for astronomical catalogues and tables published in academic journals; and Aladin, an image visualizer, conceived to access images and catalogues stored locally or remotely. These services are used daily by the international astronomical community, and their usage is constantly increasing (500,000 queries/day on average in 2010). SIMBAD (see Figure  1 ) is the reference database for identification and bibliography of astronomical objects, providing a homogenized view across astronomy sub-disciplines  (Wenger, Ochsenbein, Egret, Dubois, Bonnarel, Borde, et al. , 2000). SIMBAD data is selected from articles published in academic journals and astronomical catalogues.
The first version of SIMBAD developed at the beginning of the seventies, and the current version of the software, the fourth major update since 1972, has been operational since 2006. This last update to date has taken the CDS from a home-made, object oriented database to the open source platform PostgreSQL  (Wenger & Oberto, 2007). Another interesting trend has been the inclusion of "less controlled" information in addition to measurements, bibliography, and data: notes from the CDS team (  2002 ) and, more recently (2010), the possibility for users to post annotations, the first CDS Web2. 0 implementation. The database content is built by a team of highly qualified librarians working closely with CDS scientists. In December 2011 SIMBAD contained 5,400,000 objects, 15,200,000 object identifiers, and 250,000 bibliographic references (respectively 3,000,000, 8,300,000 and 140,000 in 2003).
To cope with the rapidly increasing flux of data, methods have been developed for semi-automated entry of information from article texts  (Lesteven, Bonnin, Derriere, Dubois, Genova, Oberto, et al. , 2010)  and tables, but the results are validated by a specialist to keep a high level of quality. VizieR (see Figure  2 ) is the reference database for tabular data from astronomical catalogues and tables published in scientific papers -CDS is the data curator of these tables at the international level. Tables are completed by their description, which links their physical and astronomical content  (Ochsenbein, Bauer, & Marcout, 2000). Tables are available through a ftp service and are also stored in a relational database system that allows users to browse them to discover and extract information.
The master database is a Sybase system, and queries are distributed on a local cluster. Some of the seven mirror copies use PostgreSQL. A specific system allowing very efficient queries by position is implemented for very large catalogues (more than a few ten million objects, the largest ones contain more than 10 9 objects). The catalogue and table collection has been built in close collaboration with several of the major astronomy academic journals, beginning with the "on-line only" publication of "long" tables from Astronomy & Astrophysics by CDS as early as 1993, as explained in Section 3. VizieR contained 9,500 catalogues in December 2011 compared to 3,800 in 2003. More and more tables now come with "attached data", such as images, spectra, time series, etc, well in line with the increasing requirement from the funding agencies to make data produced by research available for checking the research process and for re-use.
2. VizieR user interface (centre) with display of data through VO tools, Topcat and Aladin, and an object spectral energy distribution built from the newly implemented photometric metadata Aladin (see Figure  3 ) is a reference software dedicated to the integration, visualization, and manipulation of images and catalogues provided by CDS or the user or remotely by astronomical data centres around the world. It is evolving continuously, with functionalities allowing users to manipulate huge images and data cubes, to deal with photometry, to convolve images, to carry out cross-matches, to use the software in scripts, etc. Aladin is used by ESA, the Space Telescope Science Institute, the NASA Extragalactic Database NED, and the Canadian Astronomical Data Centre to provide visualization of their images.