dataesr/scientific-paragraphs-categorization huggingface dataset:
E. Variable Name Denormalization Another problem of CocciEvolve is the temporary variables that are added during the update process. These temporary variables add multiple lines of code to the updated file which can be considered harmful since it makes the code less readable and understandable. Typically, most of the added lines just reference other variables in the code -thus they are unnecessary. An example of the temporary variables created by Coc-ciEvolve can be seen in Figure  13. In this figure, we can see that the temporary variables named parameterVariable (line 11-16) and classNameVariable (line 17) only refer to other variables that already exist in the file (method parameter in line 10). Addressing this problem will be beneficial towards the readability and ease of understanding of the updated code.
These variable definitions contain their resolved values as the assigned expressions. These values are then used to replace the temporary variables used as the API's arguments. Finally, we delete the declaration and definition of the temporary variables as they are no longer needed. Our dataset contains 360 target files containing 20 Android deprecated-APIs, extended from the APIs that were used to evaluate CocciEvolve  [7]. The dataset is obtained from a randomly selected GitHub projects obtained using AUSearch  [1] , a tool to search Github repositories for API usages. Using this tool, we collected public GitHub repositories that contain invocations of the deprecated APIs and their replacement APIs in our dataset. Our dataset comprises after-update examples, target files to update that contains usages of the APIs, and oneto-one mappings from the deprecated APIs to the replacement APIs.
B. Research Questions 1) RQ1: How many updates can AndroEvolve apply correctly?: We assess update performance by counting the number of correct updates produced. A correct update is an update that contains the deprecated and replacement API method in the form of an if code block, alongside with all the methods and classes needed by the replacement API method. We compare the update performance of AndroEvolve and CocciEvolve. We also ask an experienced Java and Android engineer to check the measured update performance and verify their correctness. 2) RQ2: How readable is the updated code produced by CocciEvolve and AndroEvolve?: We measured the readability of the updated code produced by AndroEvolve and CocciEvolve. In order to get a better insight on the readability aspect of the update, we conduct an automatic and a manual measurement.
In the automatic measurement, we utilized a state-of-theart code readability scoring tool proposed by Scalabrino et al. [20]. The tool outputs a code readability score in a scale of 0. 0 to 1. 0 with the higher score being a measure of better readability. As the readability score is affected by the length of the source code file, we performed a static slicing to obtain parts of the code that are affected by the update. The static  code slicing is done using JavaParser  [22]  by first locating the deprecated and updated Android APIs based on their description. After these APIs are found, we slice the API method invocations and all the variables that are used in the invocations. The sliced code is then put into a template class and method to allow readability measurement using the tool. An example of the sliced code file is shown in Figure  16.
In the manual measurement, we asked two experienced Android developers to score 60 updated code, with 30 updated code each from CocciEvolve and AndroEvolve. We choose 30 as a sample size to represent the variation in the syntax of the updated code. The developers were not told about which tool is used to produce the updated code. The first developer has 5 years experience in Android, while the second developer has 3 years of experience. For each updated code, the developers were asked to give score in the Likert scale of 1-5 for the readability of the code, and the naturalness of the code. A higher score indicates higher readability and higher confidence that the code resembles the one produced by human. For each pair of updated code produced by CocciEvolve and AndroEvolve, the developers are also asked to determine which code that they prefer.
) APIs. These APIs utilize out-of-file variables for their method invocation. Out-of-file variables are variables that are defined outside of a file scope. These variables can be a class member or a method invocation argument that are defined in other files. Since AndroEvolve works only in a file scope, these out-of-method variables are unresolved, causing an incomplete update. An example of the updated code that carries this problem is shown in Figure  17. In this example, the callback object (line 2, 6) is a class member whose value is defined in another file. AndroEvolve cannot handle complex updates that involve an update of a single API into multiple APIs, such as updating getAllNetworkInfo() API to getAllNetworks() and getNetworkInfo(. ) APIs. Unlike the usual Android API update that replaces an API with a newer API, the case of getAllNetworkInfo() is different.
Updating this API involves the addition of a new control flow in the form of a loop that iterates the Network object returned by getAllNetworks() to receive their NetworkInfo object by using getNetworkInfo(. ) method. AndroEvolve also cannot update multiple invocations of an API method written in a single line of code. While uncommon,  this problem has been found in some target files, resulting in an incomplete update. An example of this problem is shown in Figure  18. We can see that getCurrentHour() (line 7) is invoked multiple times in the last line, causing only the first invocation to be updated. 2) RQ2: Code Readability: In automatic readability measurement, we compute the scores of all 355 updated code and average the scores for the APIs. The detailed scores are shown in Table  II. Based on this result, code updated by AndroEvolve has higher scores for all APIs.
Further analysis of the updated code shows that a bigger improvement is observed for APIs with multiple arguments (e. g. saveLayer(. ), startDrag(. ), etc. ). The manual readability measurement strengthens the above findings. The average readability score given by the developers for code updated by AndroEvolve is 4. 817. Meanwhile, the average readability score for code updated by CocciEvolve is 2. 633. Improvement can also be seen in the scores for code naturalness: AndroEvolve's code was given an average score of 4. 917, while CocciEvolve's only received an average score of 2. 433 for the naturalness aspect of their code. 3) RQ3: Update time: The update time of AndroEvolve is shown in Table  III. Both update-script creation and update-script application steps in AndroEvolve took an average of less than 15 seconds to execute.
VI. DISCUSSION Based on the results provided in Section V-C, it is evident that AndroEvolve achieves a better performance than Coc-ciEvolve. Our approach solves the problem of out-of-method variables by using data flow analysis to resolve their values. Moreover, variable name denormalization also improves the readability of the updated code, as demonstrated by our automatic and manual readability measurements. Despite this achievement, AndroEvolve still fails to update some target files, as described in Section V-C1. Some failures are caused by multiple invocations of the same API within a single line of code. A possible solution for this problem is to temporarily separate the same API invocations that exist in the same line of code into multiple statements to be updated independently. Other failures occur due to usages of out-of-file-boundary variables in the after-update example.
Li et al. [12]  proposed a tool called CDA to characterize deprecated Android APIs. They found inconsistent annotation and documentation on deprecated APIs, and that most deprecated APIs are used in popular libraries. Zhou et al. [26]  examined the usages of deprecated APIs in 26 opensource Java frameworks and libraries and found that many of these APIs were never updated. They proposed Deprecation Watcher, a tool to detect deprecated Android API usages from code examples on the web. Brito et al. [2]  conducted a large scale analysis on Java systems to measure the usages of deprecation messages. Their analysis showed that a number of deprecated APIs did not use these replacement messages. Yang et al. [25]  investigated the impact of Android OS updates on Android apps. They presented an automatic approach to detect parts of Android apps affected by an OS update.
Similar studies on this topic have been done recently. AppEvolve  [5]  is one of the first tools proposed for this purpose. It performs API updates by learning from both before-and afterupdate example. CocciEvolve  [7]  is the current state-of-the-art tool for automated update of deprecated Android API usage. CocciEvolve improves on AppEvolve by only using a single after-update example to perform API update and providing a highly readable and configurable update API update script in the form of semantic patches. CocciEvolve also solves the problem of failure to update code with different form or syntax that occurs in AppEvolve, as highlighted by the replication study by Thung et al. [21]. CocciEvolve utilizes parameter variable normalization to mitigate this problem. Program transformation.
Program transformations have been studied extensively  [3] ,  [9] -  [11] ,  [13] ,  [16] ,  [23]. Stratego  [23]  is a language for program transformation based on the paradigm of rewriting strategies. Stratego performed transformation following the written transformation rules. LASE  [9] ,  [13]  is an example based program transformation tool that is capable of locating and applying systematic edits. LASE provides users with a view of the syntactic edit and its corresponding contexts, allowing users to review and correct the edit suggestions. Rolim et al. [16]  proposed REFAZER, a technique for automatically learn program transformations by observing code edits performed by developers. Coccinelle  [3] ,  [11]  is a C-based program matching and transformation tool that has been utilized for the automated evolution of Linux kernel.
Coccinelle allows developers to write their transformation rules using Semantic Patch Language (SmPL). Recently, Kang et al. [10]  proposed Coc-cinelle4J, a port of Coccinelle for Java language. Coccinelle4J allows the transformation of Java program using the same method as Coccinelle, through the use of semantic patch written in Semantic Patch Language. In our work, AndroEvolve applies program transformation to update deprecated Android API usages. It uses SmPL to write the transformation and Coccinelle4J to apply it.
VIII. CONCLUSION AND FUTURE WORK Updating the usages of deprecated Android APIs is a priority to ensure the functionality of Android apps in the current and previous versions of Android OS. However, performing such updates is time-consuming and labor-intensive. In this work, we proposed AndroEvolve, an automated Android API usage update tool. AndroEvolve uses data flow analysis to resolve the values of out-of-method variables, allowing AndroEvolve to work on the file scope. AndroEvolve also performs variable denormalization to produce updated code with good readability. We evaluated AndroEvolve using a dataset of 360 target files from which it managed to produce 316 successful updates. On the same dataset, CocciEvolve, the previous state-of-the-art tool, only managed to produce 249 successful updates.
We also evaluate the updated code readability using both manual and automatic measurements. In the manual measurement, we asked the opinions of two developers on the readability of the updated code, while in the automatic measurement, we used a code readability scoring tool. In both measurements, AndroEvolve outperforms CocciEvolve by 49. 89% and 82. 94% respectively. For future work, we plan to increase the capability of An-droEvolve. First, we plan to improve the data flow analysis to allow resolving values that are located in other files within the same project. This addition will make AndroEvolve capable of handling out-of-file variables. Second, we also plan to handle more complex Android API updates, especially for cases where a single API is updated into several different APIs. While such a case is uncommon, this improvement would increase the overall effectiveness of AndroEvolve.
Aims and Hypotheses MindBlooming is a two-year research project with multiple primary goals and related hypotheses. Firstly, we aim to design and implement a new Internet-Based Multi-Approach Intervention (IB-MAI) for university students. The intervention covers a wide range of mental health issues that are relevant within the university student population  [11, 28]  and that are treatable with IBIs  [23, 25, 29]. Furthermore, the intervention is tailored to the individual's needs. The mental health issues that MindBlooming addresses are depression, anxiety, sleep problems, self-disruptive thoughts, job-and study-related stress and burnout, and chronic pain. Secondary aims will be:  (1)  the feasibility assessment of this IB-MAI (in terms of acceptability, satisfaction, usability, and uptake) through a pilot study on a restricted sample; (2) a randomized controlled trial (RCT) to compare the IB-MAI with web-education, as the control condition (CC); and (3) exploratory analysis to tune a predictive model on the collected data adopting Machine Learning techniques.
We followed the design principle of Material Design  [30] , which is a system of guidelines, components, and tools that support the best practices of user interface design and specify theories and practical applications of the interaction among human and machine for mobile development. The user interface (Figure  1 ) has been developed following the current usability standards, and it comprises features such as reminders, nudges, a calendar, and a diary. Secondary aims will be:  (1)  the feasibility assessment of this IB-MAI (in terms of acceptability, satisfaction, usability, and uptake) through a pilot study on a restricted sample; (2) a randomized controlled trial (RCT) to compare the IB-MAI with web-education, as the control condition (CC); and (3) exploratory analysis to tune a predictive model on the collected data adopting Machine Learning techniques.
Moreover, to further encourage participation, posters will be placed in local universities. In this phase they will receive preliminary information. Then, through a web link, they will be redirected to a specific landing page with more detailed information about the mobile app. On this web page, participants will be redirected to the proper marketplace (Apple Store and Google Play) to download the app on their smartphones. If possible, European Credit Transfer and Accumulation System (ECTS) credits will be awarded to participants. Once their eligibility has been verified and they have signed an online informed consent form, students interested in participating will be included in the study. We will collect the information concerning the diverse participants' recruitment channels to ensure that there is no difference in baseline data among different recruitment channels.
We will first identify participants that change more than 1 SEM to classify responders and non-responders. Then we will use ML algorithms to predict this outcome starting from socio-demographic in a first step, and socio demographic plus the other outcome variables (except BDI-II of course) in a second step. We will test five different algorithms to have a good mixture of simple linear (LDA), nonlinear (CART, kNN), and complex nonlinear (SVM, RF) methods, thus covering the most used and diffused ML methods  [86]. A total of 20% of the data will be held out for testing purposes, thus ML training will be performed on the remaining 80% data of the total sample. The portion of sample holdout will be set at the beginning and kept constant for all the algorithms tested and outcomes targeted, to make the different models' performances directly comparable.
Here, we present ProFeatMap, an intuitive Python-based website allowing to quickly display protein features such as domains, repeats, post-translational modifications location and so forth, into a highly customizable graphical 2D map. Starting from a user-defined protein list, ProFeatMap automatically extracts the main protein features from the Uniprot database. The resulting high-quality maps can help to gain insights, e. g. feature redundancy, that were previously overlooked but which may be useful for the research project. ProFeatMap is freely accessible on the web at: https://profeatmap. pythonanywhere. com/.
INTRODUCTION Most -omics studies produce datasets involving substantial lists of proteins. A useful approach for examining such lists is to analyze either their protein-associated biological properties as by Gene Ontology  [1] , or their sequences. While Gene Ontology might be able to find overrepresented features in the protein list, it loses information of their relative location, size and organization. Alternatively, sequence examination implies complex analyses as multiple alignments and requires similar proteins to be informative. An intermediate scale of analysis is to focus on features such as domains, amino-acid or domain repeats, post-translational modifications, sequence variants, secondary structures, low-complexity regions, and their organization along the sequence. Several online tools are already available to depict domain organization in a manual or semi-automatic manner (Figure  1A ).
However, even the most versatile programs, such as MyDomains on Prosite  [2] , can only scrutinize one single protein at the same time, representing a tedious and time-consuming approach even for a list containing a limited number of proteins. The interactive Tree Of Life (iTOL) tool bypasses this limitation, but specifically needs a phylogenetic tree as input  [3]. To our knowledge, a versatile tool allowing feature visualization of large protein datasets in both a global and customizable way is still awaited. Here we introduce ProFeatMap, a freely available, user-friendly and interactive web interface. Gathering features directly from the Uniprot database  [4] , the program represents the overall domain organization and many other features in a 2D map in which the two dimensions correspond to the number and the size of the proteins contained in the list.
ProFeatMap implementation ProFeatMap is entirely coded in Python (3. 9. 6)  [8]. It is freely accessible as a web interface developed using the Dash library (2. 0. 0)  [9]. Therefore, it is compatible with most common web browsers. Maps and corresponding legends are drawn with the pillow library (7. 2. 0)  [10]. The program can be run through a website without any account or registration. Alternatively, all scripts are freely accessible on GitHub and can be ran locally. ProFeatMap follows 4 main steps in execution: protein list uploading, features extraction, addition of user numerical values (optional), and map creation and customization. A user guide for each step is found in the help sections of the web interface. A detailed user guide is available within the supplemental information. According to a user-defined protein list, ProFeatMap automatically downloads the Uniprot file for each protein (https://uniprot.
The ProFeatMap usage The user provides a protein list embedded into a two-columns table file (xlsx, xls, ods, csv, tsv, txt, …) containing the UniProt Accession codes and unique protein identifiers. Alternatively, a compatible list can be obtained from UniProt by downloading a protein selection through a query or the basket option. Entry lists may also be composed of various proteins obtained by experimental omics approaches, or proteins with similar segments resulting from e. g. a BLAST search. After extracting feature occurrences, ProFeatMap generates a highly customizable 2D map. An example generated for human kinases (with 489 proteins) is visible on Supplemental. This process can be done through a quick and automatic run, or by adjusting several options.
ACKNOWLEDGMENTS The authors thank the institutional support of the  Centre National de la Recherche Scientifique (CNRS) ,  Université de Strasbourg ,  Institut National de la Santé et de la Recherche Médicale (INSERM)  and  Région Alsace. GB is recipient of a Ph. D. grant by the  Ligue contre le Cancer. The work was supported by the  Ligue contre le Cancer  (équipe labellisée 2015 to GT) and the  Cancéropôle Grand-Est  (projet Emergent 2018 to YN). The authors are grateful to  Gergo Gogl  for the initiation of this visualization project.
Alonso-Mora et al. (2017)  and  Ruch et al. (2020)  used open taxi data from New York City and San Francisco, whereas  Zwick and Axhausen (2020a)  used demand data from the ride-pooling operator MOIA in Hamburg that also serves as a data source here. Less studies taking into account shift times of drivers were found. Bischoff et al. (2017)  used historical taxi demand and supply from Berlin, and Zwick and Axhausen (2020b) used historical demand and shift plans of MOIA in Hamburg to assign a service time to each simulated vehicle with begin and end times according to the data. While the temporal distribution of vehicles approximate the real-world systems, there are no operational duties for shift breaks or hub returns at an end of a shift taken into account. The same accounts for a study of  Martinez et al.
Data preparation and scenario setup We demonstrate the application of shifts using the stop network, demand and shift data from Europe's largest ride-pooling provider MOIA in Hamburg, Germany. MOIA operates since its launch in 2019 with up to 500 vehicles in a 300 km 2 service area covering large parts of the city shown in Figure  3. Although the input data reflects the real-world service, it should be noted that the ridepooling simulation, the used algorithms and the results only remotely resemble MOIA's real-world operation. The street network is based on OpenStreetMap 5  data and MOIA's more than 10,000 virtual pick-up and drop-off stops are matched on it. We only simulate the ride-pooling service and thus observe no congestion through car traffic in the system. In order to obtain realistic travel times throughout the day, we use GPS-based speed data of all weekdays in November 2019 from Tom-Tom 6  and match it to our MATSim network with the help of a map-matching algorithm described by  Yang and Gidófalvi (2018).
Demand and supply data We draw upon recorded ride-pooling requests from MOIA to generate the demand. Requests from four typical weekend days have been collected between 19/09/2020 and 10/10/2020. We randomly sample one fourth of each day's requests to avoid outlying extreme demand scenarios of a single day. All requests are combined and assumed to occur on the same simulated day. In order to avoid clustered requests from the same person, which would then be easily poolable in the simulation, we excluded all requests from a person within a time range of 30 minutes after the first request. Additionally, the departure time of each request is randomized by 10 minutes. In total, the dataset contains 24,032 requests with an average trip length of 7. 3 km. Similarly, we sample historic real-world MOIA shifts from these same days and obtain 476 shifts in total from 4:45 am to 6:30 am the next day.