dataesr/scientific-paragraphs-categorization huggingface dataset:
Dataset Description This dataset has been used for analyzing the performance of deep learning algorithms used for the automated detection and classification of mobile malware. For this, some researchers provided Android malware datasets with features in order to facilitate the analysis and utilization of features. To evaluate our approach performance and compare it with existing popular approaches, we compiled an Android application dataset (Drebin-215) comprising of vectors of 215 features from 15,036 app samples. Formally, the Drebin samples are publicly available and widely used in the research community. For  (Arp et al. 2014; Yerima & Sezer, 2018) , 9,476 were benign samples while the remaining 5,560 were malware samples from the Drebin project. The supporting file contains a further description of the feature vectors/attributes obtained via static code analysis of the Android apps.
Results and Discussions of Dimensionality Reduction In this study, the most widely used Drebin-215 dataset has been chosen to verify the proposed dimensionality reduction using Python programming language with the Keras framework. As a result, we noticed that our proposed Stacked autoencoder architecture achieved its goal with a minimal loss rate compared to the other tested architectures cited in the previous table (See Table  2 ). The graphical representation shown in Figure  4  gives the dimensionality reduction results graphs for 100 epochs with training loss vs testing loss.
CoNVoLUTIoNAL NEURAL NETwoRK (CNN) Deep Learning (DL) is part of an artificial neural network technique and a subclass of machine learning  (Clottey et al. 2021). Moreover, DL is part of a broader family of machine learning methods based on learning data representations  (Brahami et al. 2022; Brahami et al. 2022; Qiu et al. 2021). Deep learning is an advanced sub-field of machine learning, which advanced Machine Learning closer to Artificial Intelligence. In DL, multiple layers are used for a higher level of the feature from the input dataset  (Sundareswaran & Lavanya, 2020). Furthermore, DCNN is a class of deep, feed-forward artificial neural networks that has successfully been applied to analyzing visual imagery  (El-Alami et al. 2020). According to earlier works, deep learning algorithms can be classified into three categories based on the form of the learning process, namely supervised, semi-supervised, and unsupervised  (Liu et al.
System Requirements To validate the proposed method, computer hardware was configured including Intel(R) Core(TM) i7-7500U, CPU (2. 70 GHz to 2. 90 GHz), GTX1050Ti GPU, and 8 GB RAM. The primary software configuration included Microsoft Windows 10 64-bit Operating System, Python compiler, Spyder 4. 0. 1 editor, deep learning framework PyTorch, and uses the neural network library Keras 2. 2. 4, Numpy, Pandas, SciPy, scikit-learn, and Matplotlib 3. 1. 3.
Results and Discussions (Detection and Classification -Phase II) In this section, experiments on a popular Android applications dataset are conducted. we first apply the proposed approach to the binary classification task for malware. To distinguish the malware samples and the normal, benign samples, we need a sufficient quantity of both malware samples and benign samples. Otherwise, the most widely used Android apps (Drebin-215) dataset has been chosen to verify the proposed approach using Python programming language with Keras framework. For this, we investigated the automatic binary classification of the cases of Android malware using deeper networks (SAE and Baseline CNN). Multiple layered models have been designed for performing convolution. The Rectified Linear Unit (ReLU) activation function is used to define the output of internal layers.
50% of the Android malware samples. Likewise, Figure  7  shows the confusion matrix of the test. High classification success was achieved in TP and TN values. However, the high values of the classification numbers    7 ). In this respect, the result will cause users not to use some useful and safe applications for no reason and, it will cause users to be at risk because some malicious applications are considered safe by them. Besides that, we conducted a comparative study of our proposed approach with other existing malware detection and classification models on grounds of the approach used, a number of Android application (Drebin-215) datasets used in experimentation, methodology, features used for extraction and classification, and percentage accuracy achieved. In addition, our method extracts various types of features to reflect all aspects of applications as comprehensively as possible.
The results in the table further verify that our proposed model achieves the best performance among all the methods (see Table  5 ). In general, the results of the present study were evaluated comparatively according to similar parameters, we have seen that the proposed approach produced successful results with respect to other studies. However, much better results were produced in earlier studies as aforementioned, better results were obtained with slight differences with the studies using similar formalization. Very good performance metrics results were obtained according to studies with similar malware applications dataset sizes. This shows that existing detection and classification performance metrics values were taken one step further with the proposed approach in the present study. It suggests that the proposed approach has improved specificity compared with the previous works.
CoNCLUSIoN In today's technological advancements world, where Android malware threatens users, taking security measures, detecting, and preventing the damages that malware software can cause emerge as an important field of study. The work conducted within the framework of this study is aimed to detect and classify malware and benign applications targeting the Android operating system. According to  (Andrea et al. 2022) , there are two publishers for the Android operating system (Google Mail Services (GMS) and Open Handset Distribution (OHD)). Likewise, deep learning was widely applied to several applications and has proven to be a powerful machine learning tool for many complex problems such as detecting and classifying malware applications. As well, the application of deep learning for Android malware detection and classification is a hot developing research topic with many challenges.
The fast advancements of new deep learning techniques will keep driving the enhancement of Android malware detection, classification, and analysis. This paper proposes a deep learning model for mobile malware detection and classification. It is based on Stacked AutoEncoder (SAE) and it could be used for reducing the data dimensionality in the case of mobile malware detection. Then, a Convolutional Neural Network (CNN) is utilized to detect malware through malware binary visualization. In the right context, the experiments were conducted using the real-world dataset called Drebin-215 which contains 15,036 app samples with 9,476 benign samples and 5,560 malware samples. The findings prove that the proposed combined approach of SAE and CNN achieves a malware category classification accuracy of about 98.
5%. In the experimental results, a 0. 9874 precision value, 0. 9818 recall value, 0. 9850 accuracy and 0. 9841 F-measure value were obtained. Due to the high performance achieved by this model, we believe that these results help users to make decisions pertinent to a very dangerous situation for Android applications use. In contrast, we compared our results with the previous studies that used main features extraction to achieve better results and some of them used main static features. For future works, we aim to develop a full system for malware via deep learning detection and classification with telecommunications and network research labs. In addition, the results may be improved using more datasets namely CICAndroidBot, Kharon, CICAAGM2017, CICAndMal2017, and CICInvesAndMal2019 that can be added to improve the model performance, more experiments on hyperparameters settings in order to improve the approach, and more sophisticated feature extraction techniques based on deep learning that was developed for the android malware.
2020). After the background subtraction we performed an additional cosmic hit and bad pixel search and correction. For this we used the CASCADe-filtering 19  package which is a sub package of the Calibration of trAnsit Spectroscopy using CAusal Data (CASCADe 20  ) data reduction package developed with the Exoplanet Atmosphere New Emission Transmission Spectra Analysis (ExoplANETS-A 21  ) Horizon-2020 program. The applied filtering method has previously been used on HST transit spectroscopy data  (Carone et al. 2021). We refer to this later paper for further details on the method. In brief, the applied filter method assigns an optimal filter kernel to each detector pixel such that dispersion profile of the source is not broadened in the the spatial direction. We flag all pixels deviating more than 4.
5σ from the mean determined by the applied an-isotropic optimal filter profile. The flagged pixels are then replaced by an interpolated value using the same filter profile. Note that the filtering is applied on each spectral image in the timeseries separately, to preserve all temporal information and not flag and remove real time variable signals other than cosmic hits. After cleaning the spectral images we determined the location of the spectral trace. For this we used the CASCADe-jitter 22  package, also a sub package of the CASCADe transit spectroscopy package. This package uses an implementation of the Canny edge filter  (Canny 1986 ) to create a binary image of the spectral images. The Jacobian and Hessian matrices needed for this method are calculated using a 3 × 3 Scharr-Operator  (Scharr 2000).
Finally we extracted the 1D spectral timeseries data from the spectral images using the extract1d pipeline step with a custom parameters file. We apply the polynomial coefficients from the trace fit listed above to center the extraction aperture at the exact source position for all wavelengths. In the spectral extraction we used a constant width extraction aperture of 8 pixels. We empirically determined that for an constant width extraction aperture extraction width of 8 pixels gave the optimal noise performance and spectral stability. Future improvements on this could be a tapered extraction aperture to take into account the wavelength dependent point-spread function (PSF) width, or a PSF weighted extraction such as discussed in Section 3. 2. The resulting band-averaged timeseries data is shown in the top panel of Figure  4.
To calibrate the extracted spectral timeseries data and to extract the transmission spectrum of L 168-9 b we used the CASCADe transit spectroscopy package. This package makes use of the half-sibling-regression methodology developed by  Schölkopf et al. (2016)  using causal connections within the data set to model both the transit signal and any systematics, and which has been successfully applied to transit observations from the Kepler mission  (Wang et al. 2016 ) and field-stabilized imaging data  (Samland et al. 2021 ). The CASCADe package was successfully applied to HST spectroscopic timeseries data  (Carone et al. 2021). We refer to this latter paper for details on the half-sibling-regression method and its implementation onto the CASCADe package. Before fitting the spectral lightcurves, we rebinned the spectra to a uniform wavelength grid with a spectral resolution of 50 at 7.
5 μm. The center values of the wavelength bins are listed in Table  1. Further, the spectral timeseries data shows a strong response drift during approximately the first 30 minutes as can be seen in Figure  2. In our analysis we, therefore, decided to skip the first 1019 integrations of the time series showing the strongest systematics. Our analysis of the remaining three and a half hours of the timeseries data only reveals a small systematic signal drift as shown in the top panel of Figure  4. The lightcurve fitting with the CASCADe package currently only fits for the transit depth, all other parameters are kept fixed at an appropriate value. We assumed an eccentricity e = 0 and an inclination i = 85°. 5, values taken from the L 168-9 b discovery paper (Astudillo-Defru et al. 2020). We further used a mid transit time T 0 = 2459728.
9599 days, corresponding to the mid-transit time seen in our data, and a relative semi-mayor axis a/R s = 7. 3469, the later is within 1σ from previous reported values (  Astudillo-Defru et al. 2020; Patel & Espinoza 2022). Both values where estimated by requiring a continuous systematics model over the ingress and egress of the transit. For the limb-darkening correction, we used the In the analysis the first 30 minutes of the observations have been omitted as they sow the strongest response drifts (which can be seen in Figure  2 ). nonlinear limb-darkening law proposed by  Claret (2000)  of which the four wavelength dependent limb darkening coefficients were calculated using the ExoTETHyS package  (Morello et al. 2020)  and the Atlas stellar model grid  (Claret 2000). The lightcurve models we fitted to the data were calculated using the Batman package (Kreidberg 2015) using the above parameters as input.
In our systematics modeling (see  Carone et al. 2021 , for details) we used as an additional regressor a second order polynomial as a function of time and the time dependent trace position determined by the CASCADe-jitter package (see above). The errors on the transit depth fit and systematics model were estimated using a bootstrap sampling using 600 samples. Figure  4  shows the fitted band averaged systematics model (top panel) and lightcurve model (middle panel). Note that the analysis method we applied fits both simultaneously and the calibrated lightcurve shown in the middle panel of Figure  4  is not used for actual fitting but is derived from the combined fit to the uncalibrated data shown in the top panel. The bottom panel of Figure  4  shows the residual after subtracting the fitted systematics and lightcurve model.
Eureka! Analysis We performed another independent reduction and analysis of the observations using version 0. 5 of the Eureka! pipeline 23  (Bell et al. 2022). The Eureka! analyses started with the same Stage 1 outputs as the CASCADe analysis. The "Eureka! Control Files" (ECFs) and "Eureka! Parameter Files" (EPFs) used in these analyses are available for download 24 and are summarized below. In Stage 2, version 11. 16. 5 of the crds package (CRDS developers 2022) with CRDS context 0928 and version 1. 6. 0 of the jwst pipeline were used. No changes were implemented relevant for MIRI LRS between versions 1. 5. 3 (used for the CASCADe analysis) and 1. 6. 0. The Stage 2 pipeline was run using default settings with the exception that the photom step was skipped as it is expected to degrade time-series observations.
In Stage 3, a y-window of detector rows (140, 393) and xwindow of detector columns (13, 64) were used to crop out noisy regions of the detector; the frame was rotated by 90°to have wavelength increasing to the right; Gaussian centroiding was used; a source aperture half-width of 4 and background Note. Each wavelength bin has a full-width of 0. 149 μm. 23 https://github. com/kevin218/Eureka/releases/tag/v0. 5 24 Zenodo link to be created on final submission. exclusion region half-widths of 8-16 were considered while a value of 10 was ultimately chosen as it provided spectral light curves with the lowest point-to-point scatter on average; a constant background value was fit and subtracted from each column with a 5σ clipping of bad pixels; and optimal extraction was performed using the median frame and using 10σ clipping while performing the optimal extraction.
A bug was present in the jwst Stage 2 pipeline at the time of analysis which left the wavelength array in the Stage 2 calints files unpopulated; as a result, wavelengths were computed using STScI provided code temporarily implemented 25  into Eureka!ʼs Stage 3. In Stage 4, the spectra was binned into 48 spectral channels with equal widths of 0. 149 μm spanning 4. 86-11. 86 μm as well as a white-light channel. The spatial centroid, spatial PSFwidth, and extracted flux all showed a brief (∼20 integration long) anomaly at the same time (near BJD TDB 2459728. 39 or integration ∼2900) which was caused by the HGA move shown in Figure  1 ; afterwards, all three parameters approximately settled back to their original values. To remove the impact of this event, we iteratively sigma clipped the light curves at 5σ using a box-car filter 500 integrations wide with a maximum of ten iterations.
The simulated light curves were then fitted using the CASCDe package to estimate the error of the simulated transit spectrum. The other estimate (red curve in Figure  10 ) was computed from the estimated noise sources in the observation including source photon noise, background photon noise, and random detector noise sources within an 8 (spatial) × 6 (spectral) pixel extraction aperture (R ∼ 50). This estimate assumed a background of 500 electrons s -1 from version 2. 0 of the JWST exposure time calculator 26  (ETC) and the LRS in-flight photon conversion efficiency (PCE; also known as throughput) curve from that same ETC version. The small differences between the two independent estimates of the noise floor are most likely due to small differences in assumed background levels and psf shapes in combination with the assumptions made for the spectral extraction.
The RSCD effect mainly influences the signal measured from the first few frames of an detector ramp implying that especially short integrations, like we have in the case of the L 168-9 b observations, will be affected by it. This might also explain why our noise estimate based on the in-orbit measured PHOTOM file does not show this increased noise behavior toward shorter wavelengths. As the observations used to derive the PHOTOM file had 140 frames per integration, only a small percentage of the calibration data was effected by possible RSCD effects. This in contrast to the L 168-9 b data set with nine frames per integration. Figure  10  also shows that the noise measured in the CASCADe analysis exceeds estimates from simulations at λ  11 μm. We speculate that this could be due to a difference in the applied spectral extraction methods.
Summary and Conclusions We conducted an observation of the transiting planet L 168-9 b during JWST commissioning to assess the performance of the MIRI LRS mode in time series observations. This planet was selected to provide high spectro-photometric precision and to have a negligible transmission spectrum signal. This observation led to the following results: 1. We analyzed the data using the first stage (Detector 1) of the STScI jwst pipeline, followed by independent spectral analyses using the CASCADe and Eureka! transit spectroscopy analysis packages. Both produced similar white-light curves, transmission spectra, and noise estimates. 2. From the white light curve, we were able to reproduce the planet's transit depth to within the 1σ of the recent value compiled from all TESS data by  Patel & Espinoza (2022).
Identifying, analyzing, and explaining trends in the development of material culture is one of the major concerns in prehistoric archaeology. The traditional recording of data in typologies, however, is not optimal for answering the question of diachronic change because typological data capture variability poorly and are often incompatible with multivariate statistics. To overcome these problems, we present PyREnArA (Python-R-Environment for Artifact Analysis), a trait-based tool that allows for a systematic recording of diversity and variability in a way that is applicable to quantitative analysis and multivariate statistics. Using Gravettian assemblages from Lower Austria and Moravia as a case study, we analyze changes in the morphology as well as the design of lithic projectiles and statistically determine the amount of variation that correlates with the progression of time.
g. ,  Kandler & Shennan, 2015; O'Brien et al. 2016; Crema et al. , 2016). The applicability of cultural evolution as an analytical and explanatory framework for the archaeological record, however, hinges on the data we can gather. Here, problems arise not only from the patchy nature and sometimes poor chronological control, especially for the material culture of the early periods. At least equally problematic is the way archaeological data is traditionally recorded. While it is indispensable to gather quantitative data that can be included in statistical analyses, most information on Paleolithic tool morphology is recorded in typologies. A fundamental question is thus how lithic tools can be analyzed in such a way that their traits can be meaningfully included in studies of cultural evolution.
This is especially true when considering that types are mostly based on shape information and that geometric morphometrics (see below) can measure shape differences directly. Many questions regarding cultural evolution are therefore out of reach for studies applying typological data only recorded as categorical variable. In contrast to typologies, monothetic classificatory approaches are rigid regarding group membership in classes. They do not aim at generic concepts but focus instead on individual properties of individual artifacts. Therefore, they are usually trait-based. Trait-based recordings in archaeology are common-place for technological analyses since quite a while (e. g. ,  Auffermann et al. , 1990; Tostevin, 2003; Nigst 2012; Simon & Moreau, 2012). For lithic tools-the chronologically and chorologically most sensitive part of the lithic artifact spectrum-a strict trait-based systematics is not available to date.
Though, a range of studies have also included such data (e. g. ,  Ioviţă & McPherron, 2011; Morales et al. , 2015; Weiss et al. , 2018). Eventually, diversity and individual variability of lithic tools is a current topic of research. Most notably, O'Brien et al. (  2014 ) have applied a trait-based recording system for Paleoindian lithic points in North America. A system that integrates information on shape, size, and retouch of artifacts and allows for a detailed analysis of small incremental change through time is still missing for the European record. To overcome this paralyzing situation, we present PyREnArA (Python-R-Environment for Artifact Analysis), a half-automated, trait-based recording system for lithic tools. PyREnArA provides traditional and new information on artifact morphology, customized for the implemented statistical methods, which allow for quantitative analyses of morphological change and to statistically determine the amount of variation that correlates with the progress of time.
, at least one pointed end and a general slender appearance, have been considered, irrespective of whether they are considered to be hafted frontally or laterally. After selecting these artifacts, their typological attribution as given in the respective publications has been recorded. In total, information on 267 individual artifacts attributed to 21 types has been recorded and analyzed (Table  1 ). The decision to incorporate only complete artifacts excludes a large part of the projectile spectrum. Also, fragmentation-depending on the fracture type-is often a sign of usage, indicating that these pieces have been selected for their properties after manufacturing. Complete pieces, in contrast, might have never been used for various reasons. Analyzing only complete pieces might thus introduce a bias to the data set.