dataesr/scientific-paragraphs-categorization huggingface dataset:
Both L1 and HLT performance have been studied, showing the high selection efficiency of the CMS trigger system. Second, the performance of the trigger system has been demonstrated by considering key examples across different physics analyses. In CMS, the HLT decisions often are derived from complex correlated combinations of single objects such as electrons, muons, or τ leptons. The broad range of capabilities of the trigger system has been shown through examples in Higgs boson, top-quark, and B physics, as well as in searches for new physics. The trigger system has been instrumental in the successful collection of data for physics analyses in Run 1 of the CMS experiment at the LHC. Efficiencies were measured in data and compared to simulation, and shown to be high and well-understood. Many physics signals were collected with high efficiency and flexibility under rapidly-changing conditions, enabling a diverse and rich physics program, which has led to hundreds of publications based on the Run 1 data samples.
Implementation and computational complexity We have developed efficient implementations of the derived models using the Python programming language and by employing the library Numba for low-level machine acceleration  [24]. These include: (i) the numerical integration of the Fokker-Planck model using an accurate finite volume scheme with implicit time discretization (cf. Sect. Methods), (ii) the parallelized precalculation of the quantities required by the low-dimensional spike rate models and (iii) the time integration of the latter models, as well as example scripts demonstrating (i)-(iii). The code is available as open source software under a free license at GitHub: https://github. com/neuromethods/fokker-planck-based-spike-rate-models With regards to computational cost, summarizing the results of several aEIF network parametrizations, the duration to generate population activity time series for the low-dimensional spike rate models is usually several orders of magnitude smaller compared to numerical simulation of the original aEIF network and a few orders of magnitude smaller in comparison to the numerical solution of the FP model.
The computational demands of the low-dimensional models are very modest in comparison to the aEIF network and also to the integration of the Fokker-Planck PDE, for which we have developed a novel finite volume discretization scheme. We would like to emphasize that any change of a parameter value for input, coupling or adaptation current does not require renewed precomputations. To facilitate the application of the presented models we have made available implementations that precompute all required quantities and numerically integrate the derived low-dimensional spike rate models as well as the Fokker-Planck equation, together with example (Python) scripts, as open source software. Since the derived models are formulated in terms of simple ODEs, they allow to conveniently perform linear stability analyses, e.
Methods Here we present all models in detail -the aEIF network (ground truth), the mean-field FP system (intermediate model ) and the low-dimensional models: spec 1 , spec 2 , LN exp , LN dos -including step-by-step derivations and essential information on the respective numerical solution methods. An implementation of these models using Python is made available at GitHub: https://github. com/neuromethods/fokker-planck-based-spike-rate-models.
e. , N < ∞. We chose values for the neuron model parameters to describe cortical pyramidal cells, which exhibit "regular spiking" behavior and spike frequency adaptation  [7, 50, 51]. For the complete parameter specification see Table  1. All network simulations were performed using the Python software BRIAN2  [52, 53]  with C++ code generation enabled for efficiency. The aEIF model Eqs. (  14 ) and  (15)  were discretized using the Euler-Maruyama method with equidistant time step ∆t and initialized with w i (0) = 0 and V i (0) that is (independently) sampled from a Gaussian initial distribution p 0 (V ) with mean V r -δV and standard deviation δV /2 where δV = V T -V r. Note that the models derived in the following Sects. do not depend on this particular initial density shape but allow for an arbitrary (density) function p 0.
The mean membrane voltage (of non-refractory neurons), Eq. (  28 ), used for the dynamics of the mean adaptation current, Eq. (  23 ), is calculated by V (t n ) = N V m=1 V m p n m / N V m=1 p n m. Practically, we use the initialization p 0 m = p 0 (V m ) and solve in each time step the linear system, Eq. (  35 ), using the function banded solve from the Python library SciPy  [67]. Note that (for a recurrent network or time-varying external input) the tridiagonal matrix G n has to be constructed in each time step t n , which can be time consuming -especially for small ∆V and/or small ∆t. Therefore, we employ low-level virtual machine acceleration for this task through the Python package Numba  [24]  which yields an efficient implementation. Remark: for a vanishing refractory period T ref = 0 the matrix G n would lose its tridiagonal structure due to the instantaneous reinjection, cf.
In our Python implementation we apply Powell's hybrid method as implemented in MINPACK wrapped through SciPy  [67]  to the equivalent real system of the two variables Re{λ} and Im{λ}. Appropriate initial approximations λn can be achieved (i) by exploiting that for sufficiently small generic mean input µ min all eigenvalues have zero imaginary part (see Sect. Remarks on the spectrum). In that case the eigenvalues are given by the roots {λ 0 , λ 1 ,. } of q(V lb ; λ) -the one-dimensional function of the real-valued eigenvalue candidate λ ∈ (-∞, 0] -which are obtained, for example, by (dense) evaluation of that function in a sufficiently large (sub)interval below zero. Furthermore (ii) all eigenvalues depend continuously on the (input) parameters µ and σ (cf. Fig. 7A ), i. e. , for a small step in the respective parameter space the solution λ n of Eq.
Further remarks In order to efficiently simulate the derived cascade rate models it is highly recommended to precalculate the quantities which are needed in each time step on a (µ, σ)-rectangle (see Sect. Low-Dimensional Approximations above). For the LN exp model these quantities are the filter time constants τ µ , τ σ , and for the LN dos model we need the quantities τ , ω and τ σ (all displayed in Fig. 8C ). Both models additionally require the steady-state quantities r ∞ and V ∞ shown in Fig. 6. An efficient implementation to obtain these quantities using Python with the package Numba for low-level virtual machine acceleration is available. Recall, that changing any parameter value of the external input, the recurrent synaptic input or the adaptation current does not require renewed precomputations.
Acknowledgements We thank  Maurizio Mattia  for several fruitful discussions, sharing his unpublished manuscript on the advanced spectral model and the permission to apply it to our system. Additionally we thank  Srdjan Ostojic  for providing his insights and code related to the eigenvalue problem of the Fokker-Planck operator. We would finally like to acknowledge that  Douglas J. Sterling  wrote the initial version of the software framework which was used to integrate and compare the different models. This work was supported by  German Research Foundation  (Collaborative Research Center no. 910 ).
Conclusions In this study, we derived a full-mission SCIAMACHY CO column data set that comprises retrievals from clear-sky and cloudy-sky reflectance measurements in the spectral range 2311-2338 nm over land and ocean scenes. The inversion uses the SICOR CO retrieval code that is developed for the operational data processing of the Sentinel-5 Precursor mission. It allows us to retrieve effective cloud parameters simultaneously with trace gas columns. The data product includes the CO column and its column averaging kernel for each individual sounding, and so it provides information on the vertical CO retrieval sensitivity, which changes with the cloudiness of the observed scene. This study focused on the validation of SCIAMACHY CO retrievals for cloudy-sky observations with MOZAIC/IAGOS aircraft measurements and TCCON and NDACC ground-based observations.
Considering only clear-sky SCIAMACHY observations over land at Lauder, Mauna Loa and Reunion, the comparison was dominated by the SCIAMACHY retrieval noise because of the low surface albedo and the insufficient number of collocations. Filtering the SCIAMACHY data set to select for optically thick low clouds over land and oceans, we found good agreement with the FTS ground-based measurements with a correlation coefficient of r = 0. 6-0. 7. For Wollongong, the high surface albedo led to CO retrievals from SCIAMACHY clearsky measurements that compare well with FTS ground-based measurements with a mean bias of b = -4. 3 ppb and a correlation of r = 0. 5. Even for this site, the cloudy retrievals improved the comparison with a high correlation of r = 0. 8. The mean bias stayed the same within its uncertainty, which demonstrated the overall consistency of the clear-sky and cloudy-sky data product.
Finally we processed the full-mission data record of SCIA-MACHY SWIR measurements. This data set clearly demonstrates the asset of cloudy-sky CO retrievals over oceans, providing a global coverage of the SCIAMACHY CO data product. The correct interpretation of these data requires the use of the column averaging kernel. In future, the data may be used to discriminate the vertical distribution of CO in the atmosphere, e. g. by means of data assimilation. For this, retrievals under optically thick clouds with varying cloud heights are essential because the shielding of the atmosphere below the cloud reveals information about CO in different altitudes. It is the first time that the operational TROPOMI CO algorithm is tested successfully on real data for clear-sky and cloudy atmospheres, which is an important milestone for the preparation of the S5P mission.
Although TROPOMI SWIR measurements will have the same spectral coverage and resolution as SCIAMACHY, we expect a much better data product due to its better radiometric performance and its better spatial resolution and sampling. After the launch of SP5, this techniques used in this study will allow us to use IA-GOS/MOZAIC and FTS measurements from the TCCON and NDACC networks for the validation of TROPOMI CO. Additionally, using the same retrieval approach for SCIA-MACHY and TROPOMI CO retrievals will help to provide a consistent long-term CO data set for both missions. Data availability. The full-mission SCIAMACHY CO data set of this study including clear-sky and cloudy-sky observations is available for download at ftp://ftp. sron. nl/pub/pub/DataProducts/ SCIAMACHY_CO/. The underlying data of the figures presented in this publication can be found at ftp://ftp.
Acknowledgements. SCIAMACHY is a joint project of the  German Space Agency DLR  and the  Dutch Space Agency NSO  with contributions from the  Belgian Space Agency. The work performed is (partly) financed by  NSO  through the  SCIAvisie  project and in collaboration with the SCIAMACHY Quality Working Group (SQWG) by  ESA. We acknowledge the  European Commission  for the support to the  MOZAIC  project (1994)(1995)(1996)(1997)(1998)(1999)(2000)(2001)(2002)(2003) and the preparatory phase of IAGOS ( 2005IAGOS ( -2012 )), the partner institutions of the  IAGOS Research Infrastructure (FZJ, DLR ,  MPI ,  KIT in Germany ,  CNRS ,  CNES, Météo-France in France  and the  University of Manchester in UK) ,  ETHER  ( CNES-CNRS/INSU ) for hosting the database, the participating airlines ( Lufthansa, Air France, Austrian, China Airlines, Iberia, Cathay Pacific ) for transporting the MOZAIC/IAGOS instrumentation free of charge.
In this paper, we propose a way to extract the malicious behavior of the Android applications automatically. Following  (Aafer et al. , 2013; Sharma and Dash, 2014; Song and Touili, 2014) , we model the malicious behaviors via API calls. Let us look at a typical behavior of an Android trojan SMS spy. The smali code of this behavior is given in Figure  1. This behavior consists in collecting the phone id and then sending this data via a text message. This task is done by a sequence of API calls. First, the function getDeviceId() is called at line 5 to collect the phone id. Then, the TelephonyManager object is gotten by calling getDefault() at line 19. Finally, the phone id is sent to an anonymous phone number via a text message by calling sendTextMessage() at line 25. To represent this behavior, we  tion f.
We implemented this technique in a tool which consists of two phases: the training phase and the detection phase. In the training phase, we extract the malicious API graphs from the training set which is a collection of malicious applications and benign applications: First, we unpack and decompile each Android application from the Android package file (APK file). Then, we construct the control flow graph to represent the execution of this application. After that, we model its behaviors in an API call graph. Once we get the API call graphs of all the applications, we apply the TFIDF weighting scheme to get the relevant terms in the malicious graphs and automatically extract the malicious API graphs. In the detection phase, we use these malicious API graphs for detecting the malicious behaviors in the new applications.
RELATED WORKS Information retrieval techniques were applied for malware detection in  (Masud et al. , 2008; Cheng et al. , 2013; Santos et al. , 2013; Dam and Touili, 2016). However, these works do not consider Android malwares. In this work, we extend the work of  (Dam and Touili, 2016)  to Android malwares. The first technique used for Android malware detection is based on the analysis of the manifest file where the required permissions are stored. (Aung and Zaw, 2013; Talha et al. , 2015)  extract the set of permissions needed for malicious behaviors. (Aung and Zaw, 2013 ) constructs a bit-vector of permissions to represent android applications and implements a classifier to distinguish the malicious applications from the benign ones. As for  (Talha et al. , 2015) , they extract information from the Android manifest file, such as application permissions, application services and application receivers to build a database of signatures for malware detection.
Android Applications An Android application is installed into the Android devices via an Android package (an APK file) which consists of (1) Dalvik bytecode (a dex file) which is executable, (2) all resources, and (3) an Android manifest file which contains the declaration of all the permission requirements and necessary components used in the application's execution. In order to analyze the behaviors of an Android application, we have to look into the Android byte code which is executed whenever the application runs. However, this code is a kind of binary code for Android programs. It is hard for humans to read. Thus, we use a tool to decompile this byte code into a human readable code, called smali code. Thanks to the Apktool 4  , the Android package is unpacked and the byte code is decompiled into the smali code.
The smali code represents the Android program in a form of an object oriented programming language (like Java language) where a program is constructed from objects that contain data and functions known as methods. When the Android application runs, one of its objects is executed and in this executed object there are calls to other objects. An Android application is implemented mainly using four main components: Activity, Service, Broadcast Receiver and Content Provider. Each component supports different functions in the application. For instance, the component Activity provides a user interface for interactions between the user and the ap-plication. Based on the component Service, the developer can make background executions. The component Broadcast Receiver is a means to make communications between applications in the system.
Via the Content Provider objects, the application can access/modify data on the system such as Contact list, Calendar, etc. Each component follows its own work flow. For example, in the component Activity, first the method onCreate() is called, then the method onStart(), etc. These components contain the entry points to execute the application. Thus, they are potentially exploited for malicious behaviors. As an example, Figure  1  shows the implementation of an Android application based on the component Activity. The application starts by executing the object MainActivity which is an implementation of the component Activity. This object starts by calling the method onCreate() and then calling the method onStart(). Particularly, in the method onStart(), there is a call to the method Send() at line 13 which belongs to another object (the SendMessage object).
By taking into account the event handlers of an Android application, we make the link between the CFGs of the methods which handle the events according to the work flow of each object. For instance, to handle the initialization of a new activity object, there is a call to the method onCreate() and then a call to the method onStart(). Thus, we add a link between the exit points of the method onCreate() to the entry points of the method on-Start() in this object. As an example, let us consider the smali code in Figure  1. Firstly, we build the CFG for each method as shown in Figure  3. Then, since there is a call to the method Send() from the method onStart(), we make a link from the point (12) where a call to the method Send() will be made to the entry point (17) of the method Send() and a link from the exit point (26) of the method Send() to the next point (13) of this call.
API Call Graph Let A be the set of all APIs in Android applications. An API call graph is a directed graph G api = (V api , E api ), where V api : N × A is a finite set of vertices and E api : (N × A) × (N × A) is a finite set of edges. A vertex (n, f ) means that at a control point n, a call to the API function f is made. An edge ((n 1 , f 1 ), (n 2 , f 2 )) in E means that the API function   f 2 called at the control point n 2 is executed after the API function f 1 called at the control point n 1. To compute an API call graph from the CFG of an Android application, we perform a kind of control point reachability analysis on the CFG as described in  (Dam and Touili, 2016). As an example, let us consider the construction of the API call graph of the code in Figure  1. Since the control flow graph is constructed in Figure  5 , we simplify this graph to get an API call graph where each node is a pair of the control point and the API which is called at this control point.
EXPERIMENTS We evaluate the performance of our approach on a data set of 459 benign applications, which are collected from the website apkpure. com and 3100 malicious applications which are gotten from Drebin dataset  (Arp et al. , 2014). We divide this data set -Training Phase. In this phase, we extract the malicious API graphs from the data in the training set as follows. Firstly, we take each input application as an APK file. Then, this APK file is unpacked and decompiled by Apktool. After getting its smali code from Apktool, we construct the CFG and the API call graph of this application. Once we build the API call graph for each application, we compute the malicious API graphs by the strategies described in Section 5. 2. -Testing Phase. In this phase, we apply the malicious API graphs to classify the applications in the test set.
We take each input application as an APK file. Then, we unpack and decompile this APK file to get its smali code by using Apktool. After that, we construct its API call graph. As we described in Section 4. 2, this application is marked as malicious if there is a feasible common path between its API call graph and the malicious API graphs. Otherwise, it is marked as benign. We evaluate the performance of the functions F 1 , F 2 , F 3 and F 4 (detailed in Section 5. 1) with the Rocchio and Ratio equations (equations 3 and 4). Positives over the sum of True Positives and False Positives. F-Measure is a harmonic mean of precision and recall that is computed as F-Measure = 2×Precision×Recall/(Precision+Recall). These are standard evaluation measures in the IR community. The technique computes more relevant items than irrelevant if the precision rate is high.
Computer security is something that brings to mind the greatest developers and companies who wish to protect their data. Major steps forward are being taken via advances made in the security of technology. The main purpose of this paper is to provide a view of different mechanisms and algorithms used to ensure big data security and to theoretically put forward an improvement in the health-based environment using a proposed model as reference. A search was conducted for information from scientific databases as Google Scholar, IEEE Xplore, Science Direct, Web of Science, and Scopus to find information related to security in big data. The search criteria used were "big data", "health", "cloud", and "security", with dates being confined to the period from 2008 to the present time. After analyzing the different solutions, two security alternatives are proposed combining different techniques analyzed in the state of the art, with a view to providing existing information on the big data over cloud with maximum security in different hospitals located in the province of Valladolid, Spain.
Introduction Big data refers to the huge amount of information that is created and proves difficult to analyze in real time, to the extent that traditional databases are not sufficient for dealing with such data  [1]. When big data is mentioned, it tends to refer to the three Vs (volume, velocity, and variety)  [2] , and some even extend this to the five Vs: volume, velocity, variety, veracity, and value  [3, 4]. These five characteristics mentioned are defined as follows: volume refers to the size of the data generated, although certain minimums are yet to be established as this is a relative concept. Velocity refers to a large amount of data generated over time. Variety refers to a combination of different information formats, whether structured, semistructured, or without structure. Veracity refers to the fact that none of the data generated is of any use if it is not reliable.
Lastly, value refers to the scientific value attributed to this data  [5] [6] [7]. The term "big data" has been exponentially growing in use since 2011 and is taking on increasing weight in both society and the world of business  [8]. As this is a new concept, the lack of trust factor is involved that raises other associated problems  [9]. Some of these problems that are seen in the use of big data are rather dangerous. Even though the data is stored anonymously, there is little control over it, whether this data is private or personal  [10]. Moreover, there are benefits in using big data, the most important of which is that it enables the Government to improve quality of life in society via the analysis of vast amounts of information  [10]. Traditional databases use standard SQL that generates request and handle relational tables.
Owing to the relationships that exist between the tables, utilizing them is not practical because the big data mainly refers to the unstructured information  [10]. NoSQL databases have emerged as a result and offer better functionality especially for the purpose of storing and maintaining information on a large scale without being concerned with the format of data in which it is presented. Furthermore, the NoSQL offers high performance for the large volumes of heterogeneous data within a distributed environment  [11] [12] [13] [14] [15]. Moreover, the terms big data and cloud computing have enormously gained prominence in recent years, and one of the reason for this is because big data is directly related to the cloud  [12, 13]. The importance is because the cloud is coming up with the new architecture paradigms in information technology  [16] [17] [18].