dataesr/scientific-paragraphs-categorization huggingface dataset:
The search range for the cross-validation was for the kernel hyperparameter σ ∈ [-4, 4], for the common intrinsic dimension d ∈ [1, 20], for the scree test threshold τ ∈ [10 -7 , 1], for the regularization parameter in KFD and KQDA λ ∈ [10 -13 , 10 -6 ] and for the penalty parameter of the SVM γ ∈ [2 5 , 2 9 ]. The global classification accuracy was computed on the testing set and the Dataset Data used in the experiments. n is the number of samples, p is the number of features, k is the number of classes and hr is the hold-out ratio used in the experiments.
, consist in the daily measured temperatures at 35 Canadian weather stations across the country. The pgpEM algorithm was applied here with the model M 0 , which is the most general parsimonious Gaussian process model proposed in this work, with a fixed number k of groups set to 4. The mapping function ϕ consists in the projection of the observed curves on a basis of 20 natural cubic splines. Once the pgpEM algorithm has converged, various informations are available and some of them are of particular Classification results on real-world datasets: reported values are average correct classification rates and standard deviation computed on validation sets. Clustering of the 35 times series of the Canadian temperature data set into 4 groups with pgpEM (left) and geographical positions of the weather stations according to their group belonging (right).
Classification results on test sets for the Thyroid dataset (mixed data). Results are averaged on 25 replications of the experiment. beentunedbycross-validation on a learning sample and the kernels associated to these values are presented in Figure8. The rows and columns of the matrices are sorted according to the class memberships (healthy or sick) and the sick patients are the last ones. We then compared the performance of pgpDA with the combined kernel to pgpDA with, on the one hand, a simple RBF kernel built only on the quantitative variables of the dataset and, on the other hand, a Hamming kernel built only on the categorical variables. Table5presents both the true positive (TP) and false positive (FP) rates obtained on 25 replications of the classification experiment for pgpDA on quantitative data, on categorical data and on the mixed data.
8 72. 5 ± 12. 6 96. 0 ± 0. 5 65. 2 ± 5. 6 97. 2 ± 1. 8 92. 5 ± 2. 1 79. 8 ± 4. 9 96. 1 ± 0. 5 40. 0 ± 5. 4 75. 2 ± 8. 3 64. 6 ± 2. 6 48. 8 ± 5. 7 63. 5 ± 1. 5 35. 4 ± 7. 9 64. 2 ± 26. 8 64. 3 ± 2. 5 50. 5 ± 5. 5 36. 8 ± 1. 2 47. 3 ± 10. 1 95. 9 ± 2. 3 94. 1 ± 1. 7 82. 9 ± 3. 1 93. 6 ± 0. 5 64. 5 ± 6. 3 96. 6 ± 1. 7 88. 1 ± 2. 3 68. 9±18. 1 64. 7 ± 37. 5 96. 8 ± 1. 4 92. 8 ± 1. 8 84. 8 ± 4. 0 77. 6 ± 5. 4 86. 4 (5) 87. 8 (2) 85. 6 (7) 87. 6 (3) 88. 0 (1) 85. 2 (8) 87. 6 (3) 55. 5 (11) 46. 7 (12) 84. 5 (9) 79. 9 (10) 86. 1 (6) interest. Group means, intrinsic dimensions of the group-specific subspaces and functional principal components of each group could in particular help the practitioner in understanding the clustering of the dataset at hand. The left panel of Figure1presents the clustering of the temperature data set into 4 groups with pgpEM.
Furthermore, the most prevailing infrastructure comprises only an external wattmeter  [1, 11]. Another issue arises on how to process the power/energy samples due to the high variability to which they are subject to. Only some contributions deepen to obtain, e. g. , a statistical regression on the samples to produce reliable results  [12]. Given the foregoing, we contribute in this paper with the following: • We target five wattmeters (external and internal) to analyze two different systems representative of current general-purpose platforms: a desktop computer and a server node. Our purpose is to evaluate different power measurement sources/wattmeters, regardless of the power nature (average or instantaneous). • In order to evaluate the precision of the data acquisition devices, we use and deploy five different types of benchmarks which stress different components of the system.
The pmlib software package is developed and maintained by the HPC&A research group of the Universitat Jaume I to investigate power usage of HPC applications. The current implementation of this package provides an interface to utilize all the above-mentioned wattmeters and a number of tracing tools. Power measurement is controlled by the application using a collection of routines that allow the user to query information on the power measurement units, create counters associated to a device where power data is stored, start/continue/terminate power sampling, etc. All this information is managed by the pmlib server, which is in charge of acquiring data from the devices and sending back the appropriate answers to the invoking client application via the proper pmlib routines (see Figure  1 ). Benchmarks.
To evaluate the energy and power behavior, we run different types of workloads to intensively exercise the use of specific parts of the platforms. CPU, memory, NICs and HDDs are the main components that we stressed in our experiments. To achieve this purpose, we selected the following specific benchmarks: • idle: This benchmark employs the sleep POSIX routine 8  to suspend processor activity, thus generating idle periods that let the hardware promote the cores to low-power states, also known as C-states 9. • iperf 10  : This tool performs network throughput measurements. It can test either TCP or UDP throughput. To perform an iperf test, we set both a server and a client. Since the package features a large number of options, we only measure this tool running it as a TCP client. • hdparm 11  : This application provides a command line interface to various kernel interfaces supported by the Linux SATA/PATA/SAS libATA subsystem.
The results of this model are available via a model specific register (MSR) and provide an update frequency in the order of milliseconds. An evaluation by Intel  [27]  demonstrates that the results fairly match the actual usage of the processor, so their consideration in our evaluation is especially important. Specifically, the RAPL interface reports several power/energy readings. Power Package 0 (PKG0) accounts for the total power consumed by the whole socket. Inside, two other measurements can be accessed. Power Plane 0 (PP0) accounts the power used by all the cores/caches, and Power Plane 1 (PP1) reports the power of the on-board GPU, in case of desktop Sandy Bridge processors, or the DRAM memory, for server Sandy Bridge EP processors. Furthermore, an uncore component can be derived from the available readings taking into account that P KG0 = P P 0 + P P 1 + U N C  [28] ; hence it is straightforward to obtain the power dissipation due to internal chip circuitry (QPI network, DDR channels, shared levels of cache, etc.
) by subtracting both power planes to the package power, U N C = P KG0 -(P P 0 + P P 1). To acquire data from this interface we developed a new module for pmlib that retrieves these values via MSR at 100 S/s. This frequency can be set by the user. In a study conducted in  [29]  we assessed that an increase in the sampling frequency directly affects the performance and power dissipation of the platform due to the overhead caused by the daemon responsible for collecting power samples running on the target machine. Therefore, the sampling frequency needs to be carefully configured. ii) NVIDIA Management Library: Recent NVIDIA GPUs are able to report power usage via the NVIDIA Management Library (NVML)  [30]. Routine nvmlDeviceGetPowerUsage() retrieves the current power of the GPUs. In the tested platform, a NVIDIA Tesla Kepler K20, the power readings are accurate to within ±5 W of current power draw.
For the experiments we developed an IPMI module for pmlib that allows to read power from IPMI-capable platforms. The frequency in this case is set automatically by the response of the impitool command and is about 0. 5 S/s. To perform the study of the RAPL interface we use the Intel Desktop platform and test with the aforementioned benchmarks. For the case of NVML and IPMI interfaces we use two new platforms, since the previous configurations are not compatible with these new measurement sources. An Intel Ivy Bridge Core i7-3930K equipped with 6 cores running at 3. 20 GHz, 24 GB of RAM, and a 120 GB Seagate Barracuda 7200. 7 HDD, also equipped with a NVIDIA Tesla Kepler K20 serves to analyze both RAPL and NVML counters. We denote this platform as Intel Desktop 2. On the other hand, we consider a system with four 16-core AMD 6276 Opteron processors (64 cores in total), 64 GB of RAM and a 500 GB Seagate Constellation.
This article presents the WOLF (Wallet Open Library Framework) platform which supports an original interface for NFC developers called "SE-QL". SE-QL is a SQLlike interface which eases and optimizes NFC secure application development in making the heterogeneity of the Secure Element (SE) transparent. SE implementation could be "embedded" (eSE) in the mobile device, or inside the SIM Card (UICC), or "onhost" software-based, or in the Cloud (e. g. through HCE); every SE implementation has its own interface(s) making NFC secureapplication development extremely cumbersome and complex. Proposed SE-QL solves this problem. This article demonstrates the feasibility and attractiveness of our approach based upon an original high-level API.
I. INTRODUCTION: WOLF AND SE-QL Based upon both our Near Field Communication (NFC) know-how and our SQL (Structured Query Language for databases) expertise  [1] , we propose a generic innovative Framework called WOLF (Wallet Open Library Framework) for facilitating Service Providers (SPs) in the process of development and deployment of new NFC secure applications on a wide range of smartphones having different SE implementations. In this article we give an overview of WOLF platform developed at MBDS innovation laboratory, which allows NFC developers to interact easily with an application based on NFC Card Emulation mode by using SQL-like language, "SE-QL". WOLF framework allows SPs to reduce NFC development costs and the time-to-market, improve and ensure the quality of products applications for new secure NFC services.
WOLF extends "NFC Container" project  [2] ,  [3]  previously developed at MBDS in 2008-2010 for J2ME cell phones. Its SE-QL interface idea stems from a long-term research background on SQL and database (DB) systems; SE-QL simplifies NFC service development by abstracting the core software complexity associated with the management of multiple SE environments. WOLF supports the secure ecosystem of F1RST project in India with Tata Consulting Services (TCS), Gemalto and the Indian Institute of Sciences (IISc) of Bangalore under research contract from IFCEPAR | CEFIPRA (www. cefipra. org). F1RST encompasses a portfolio of NFC financial and rural inclusion use cases for unbanked people in India (70% of them owning a cell phone) managed within a F1RST wallet developed by TCS on top of WOLF platform.
In This work within F1RST project is partly supported by IFCEPAR | CEFIPRA under grant No. 7115 and Gemalto (supporting MBDS apprentices, and a CIFRE PhD research Scholarship). www. ijacsa. thesai. org addition, there are related standards (GP / OMAPI, EMV, EN 726-3 for prepaid memory cards, etc. ). Remark: APDU protocol does not manage the device connection or the channel opening. The APDU commands (C-APDU) is the message sent by the client application (initiator) to the service running in the SE. The structure is composed of a mandatory header of 4 fields of one byte: (i) {CLA} (class field) defines the command type (standard, industry, using security or not), (ii) {INS} defines the command instruction, (iii) {P1} is the first parameter (0x00 if not defined), (iv) {P2} is the second parameter (0x00 if not defined), and a conditional body of 3 optional parameters of a variable length: (i) {Lc} is the conditional data length of 1 or 3 (extended APDU*) bytes if not empty,(ii) {Data} is the payload data of {Lc} length if not empty, (iii) {Le} is the expected length of the response data varying from 1 to 3 (extended APDU*) bytes if not empty.
The APDU response (R-APDU) is made of the optional response data (that cannot exceed the length defined in {Le} field provided in the C-APDU), and the 2 bytes response status words {SW1} and {SW2} giving the status of the C-APDU. When the command is successful, the service returns the status words 0x9000. Card Query Language (CQL) initially designed by Pierre Paradinas in the 1990s  [11] ,  [12] , with GEMPLUS (now Gemalto), was the first approach of SQL-like APDU instructions. Smart Card Query Language (SCQL) has been standardized in 1999 by ISO / IEC 7816-7 "Interindustry commands for Structured Card Query Language (SCQL)"  [13]. But SCQL is limited to specific smart cards with embedded lite Relational DataBase Management System (RDBMS) whereas SE-QL is not….
2) Software-based (card emulation) and SE in the Cloud The software emulation (of a smart card) is an approach to card emulation for NFC phones for services that do not need to be always available (i. e. when the mobile is off). It was introduced to mobile phones by Research In Motion (RIM) on the Blackberry platform. In addition to supporting different types of SE, the Blackberry 7 introduced the card emulation mode of NFC tags with a software application on the mobile phone. Host-based Card Emulation (HCE) is the software card emulation solution available on Android devices since the end of 2013 with Android KitKat. HCE services run in the host processor as well as other services making this solution less secure and most vulnerable to malwares  [14]. On the other hand, NFC software-based implementation is much lighter to develop and truly simplifies the deployment; SP can deploy its NFC services itself.
Each user (e. g. SP developer) is identified by a security key on the applet. NFC Container API provides developers some ways to implement additional layers for more complex data management. In that case, the SP develops its own application using the generic API which provides a set of functions (SQLlike) for data management on the card. We illustrate the added value in terms of code simplification by the following Java coding example retrieved from  [2] :  ----------------------------------------/   ----------------------------------------/   ----------------------------------------/   ----------------------------------------/  NFC Container advantages: Source code 1. Example of NFC Container code simplification //- Since access to the hardware-based SE is supervised by the NFC ecosystem owners, the deployment of new NFC services is necessarily related to them.
III. SE-QL AND WOLF API: A GENERIC SQL-LIKE INTERFACE TO COMMUNICATE WITH THE SE The primary SE function is to store (sensitive and confidential) data: the majority of the (contact or contactless) card applications consist in storing and retrieving data (with or without pre-processing, with or without security mechanisms). The second fact is the building APDUs remains a cumbersome task for the developers: manipulating hexadecimal codes is not simple to human understanding; it is time consuming to be implemented and it is difficult to maintain. In this section we illustrate the SE-QL foundation based on DataBase Management System (DBMS) concepts. We present our contribution to the project with the WOLF API at the development current stage, and we describe the implementation within use cases prototypes of the F1RST project.
A DBMS integrates 3 levels:  Data Description Language (DDL): Defines a language allowing description of objects (tables, domains, databases, views, procedures…).  Data Manipulation Language (DML): Defines a standard data manipulation language allowing interrogating and updating a DB without specifying any access algorithm (SQL3 being the current standard  [1]  for relational databases).  Data Control Language (DCL): Defines some integrity and confidentiality constraints in order to manage user's rights and authorizations on objects. The DBMS ensures consistency of data in databases and defines some mechanisms such as sharing, security, physical and logical independence of data, access performances in share or exclusive mode. DBMS can handle several standard request mechanisms allowing manipulating data (read, write, delete, update, sort, etc.
B. From SQL DBMS to SE's Applet GP compliant SE is divided in a set of Security Domains (SDs) separated by firewalls allowing several services to be safely executed on the same card. Each SD is dedicated to a type of business model. On Fig. 6 , the first SD is reserved for the card issuer (MNO, manufacturer. ); it contains maintenance and additional customer's (SP) services. Others are dedicated to the SPs services (transportation, payment card, loyalty card, coupons, etc. ). A DBMS manages a set of databases contains tables consisted of rows and columns / fields. On the other hand, the SE is composed of SDs hosting running applets managing their own data / fields (see Fig. 7 ).  An NFC service hosted in the SE (applet) could be seen as a table of the DB;  The data fields of an applet could be seen as the columns of the table.
This will be translated as following in SE-QL language: (1) "SELECT balance FROM portfolio", (2) "UPDATE portfolio SET balance = {value}". To be done, the metadata must provide portfolio applet AID, SELECT and UPDATE translation into APDU protocol, and the "balance" record byte identifier:  In more complex use cases, several APDU commands may be handled within a single SE-QL instruction, for example, a statement regarding multiple fields. The activity diagram shown on Fig. 8  illustrates the processing of several fields algorithm, where APDU command sending corresponds to the greyed task. These examples illustrate the similarity between an APDU command and a SQL query; the rationale of our approach is to identify mechanisms between these two worlds. Moreover applets are not intended to manage large amounts of data like tables in relational databases; usually there are small pieces of data corresponding to tuples of information in a table in a DBMS.
In addition, SE-QL language will be limited by the www. ijacsa. thesai. org already defined standards; SE-QL goal is only to ease NFC secure application development. Fig. 8. SE-QL SELECT instruction algorithm SE-QL is delivered as a Java package integrated in WOLF libraries that manages SE / reader connection and applet communication initialization. This is managed from SE-QL controller that is the entry point for the client applications of the SE. SE-QL controller is in charge to redirect instructions to the appropriate SE-QL interface according targeted platform, implementing the method "execute" that accepts the SE-QL instruction and the command ID. The result for a given command (identified by an ID) is forwarded through an event of the SE-QL callback currently in the form of a HashMap of returned data, concerned field name being the key.
2) Metadata Metadata is actually provided as a XML (eXtensible Markup Language) file (which could be acquired on the fly during the installation of the application, for example from a web server); it contains one (or more) applet(s) configuration defining two models: the describes the correspondence APDU / SE-QL commands, while the second describes the pattern of the data managed by the applet. The metadata are used by SE-QL parser on the side of the client application at the APDU commands building, as well as the generic applet for its data storage initialization (could also be provided as a script).
1) WOLF current progress  TSM package contains tools dedicated to TSM (work in progress). WOLF for Android and SE-QL have been tested for three use cases so far : (i) SIM-based NFC service on Android device compiled with SDK17 (Android Jelly Bean, build 4. 2. 2 or earlier on nonstandard build of CyanogenMod) using OMAPI, (ii) Android HCE generic service compiled with SDK19 (Android KitKat, build 4. 4. 2), and (iii) a Java application to test the communication between a USB NFC reader plugged to the PC (using standard PC / SC driver, see www. pcscworkgroup. com/) and an NFC device. The beta version of WOLF plugin for Android was implemented last year for CyanogenMod with seek-for-Android [47] implementation of OMAPI (need the device bootloader to be unlocked and CyanogenMod build to be installed in replacement of standard OS on the phone).
Afterward, OMAPI was formally integrated as an external API for Android standard build 4. 2. 2. But since Android KitKat, OMAPI is no more supported by the official Android build; it has been replaced by Android HCE, the software based card emulation mode. **On Android KitKat, SIM-SE access must be routed by Android off-host APDU service…  3) WOLF / SE-QL implementation On Android platform, WOLF library has to be referenced in the project properties. Once it is done, SE-QL controller class can be instantiated once with appropriate parameters (targeted platform, application context if Android, metadata file). Then, you can get the controller and use SE-QL to communicate with the SE, and receive events with the returned responses from the applet as shown in source code 3: Fig. 12  gives an overview of components interaction showing how the client module (service UI) requires the name and the password of the handset end-user, stored by the applet using SE-QL; then, WOLF plugin initiates the connection and the applet requests the user PIN entry.
When user PIN entry has been successfully transmitted, the previous SE-QL instruction can be processed. This sequence derived from F1RST use cases prototyped at MBDS was a first proof-ofconcept; the client module has been tested with the applet embedded in the SIM and the generic HCE applet of WOLF without requiring any code changes except for the manifest (and the Android host-apdu-service XML metadata), since HCE services must be declared in the client application. The WOLF SE-QL reader Java tester is intended to test the communication with the applet hosted into the SE of the mobile phone: the tester frame is shown in Fig. 13 : user grabs the SE-QL instruction in the input text area and clicks on the "Execute" button. Then, he is asked to place the device on the reader and the SE-QL instruction is parsed into APDU(s) command(s); the result is shown in the log trace view.
But, as we talk about contactless communication, we may face untimely interruptions transactions when the devices are removed prematurely. Several researches have been done on database implementation in smart cards (that can apply to the SE)  [11] ,  [12] ,  [13] ,  [18] ; this highlights the need for embedded DB system. Nowadays, lite databases have been adopted for low capacity systems like SQLite (www. sqlite. org) which is multiplatform compliant and it is provided as part of Android OS. This is why we will also explore other areas of investigation around embedded DB, and also other objectoriented structures in the payload such as RESTful (Representational Sate Transfert) services, and the ability to provide XML, JSON (JavaScript Object Notation), etc. Another current important stuff is to manage security according standards specification.
ACKNOWLEDGMENT Special Thanks to Gemalto (supporting MBDS apprentices and a  CIFRE research Scholarship ) and IFCEPAR | CEFIPRA organization supporting  F1RST  ( Financial Inclusion based upon Rural mobiquitous Services Technological platform) project  ( 2012-2015 ) and more personally to  Mr. Ilan Mahalal ,  Program Manager at Gemalto ,  Mr. Debi Pati ,  CEO  lead at TATA CS, and  Nicolas Pastorelly ,  Olfa Arfani ,  Mohamed Sidime ,  Guillaume Larroque ,  Pierrick Morizot  from  University of Nice Sophia Antipolis  and MBDS for their technical contributions to NFC Container, WOLF platform and  F1RST  project.