#  APISens\- Sentiment Scoring Tool for APIs with Crowd-Knowledge

Kisub Kim  Singapore Management University
Singapore
<EMAIL_ADDRESS>Ferdian Thung  Singapore Management University
Singapore
<EMAIL_ADDRESS>Ting Zhang  Ivana Clairine Irsan  Singapore
Management University
Singapore
<EMAIL_ADDRESS>Singapore Management University
Singapore
<EMAIL_ADDRESS>Ratnadira Widyasari  Singapore Management University
Singapore
<EMAIL_ADDRESS>Zhou Yang  David Lo  Singapore Management
University
Singapore
<EMAIL_ADDRESS>Singapore Management University
Singapore
<EMAIL_ADDRESS>
###### Abstract

Utilizing pre-existing software artifacts, such as libraries and Application
Programming Interfaces (APIs), is crucial for software development efficiency.
However, the abundance of artifacts that provide similar functionality can
lead to confusion among developers, resulting in a challenge for proper
selection and implementation. Through our preliminary investigation, we found
that utilizing the collective knowledge of a crowd can greatly assist
developers in acquiring a thorough and complete understanding of the
complexities involved in the software development process. Especially as
emotions are an inseparable part of human nature, it influences developers’
activities. In this regard, we attempt to build a tool that can retrieve
sentiment information for software APIs so that developers can determine APIs
to utilize for their tasks. We employ the dataset from the most popular
platforms (i.e., Twitter and YouTube) to build our research prototype. The
source code, tool, and demo video are available on GitHub at
https://github.com/FalconLK/APISens.

###### Index Terms:

API Sentiment Analysis, API Comprehension, Pre-trained Model

##  I Introduction

Over the past decades, we have encountered the rapid growth of open-source
software (OSS). This phenomenon naturally drives more and more reuse of
software artifacts (e.g., libraries or frameworks). As the community has
tremendous demand, artifact recommendation systems have received extensive
attention. For example, developers often search for existing source code
artifacts [1, 2] to obtain the functions they need to implement or to maintain
the software [3]. Therefore, many automated artifact recommendation systems
have been proposed [4, 5, 6, 7, 8, 9] to help developers select artifacts
efficiently.

The reuse of devised software artifacts causes another problem due to there
being a large number of artifacts that implement the same or similar
functionalities, which may confuse developers. For example, two APIs, getData
and retrieveInformation, are capable of processing the same functionality,
which is “requesting and obtaining the necessary data”. As a more complex
example, there exists decrypt and unscramble whose names are totally different
while they are both for “decoding/cracking something to get the initial
state”. Among the multiple options, developers need to choose the most
appropriate ones. A study [10] suggests that software reuse mainly occurs due
to a lack of base knowledge of the corresponding artifacts. This indicates
that developers reuse artifacts because they do not know what they need to
know to select the most suitable one. They also revealed that re-
implementation happens when the artifacts are required to be further enhanced,
the dependencies are too complicated, or they are deprecated. Moreover, many
developers are actively discussing choosing a suitable artifact in the
software development
community111https://stackoverflow.com/questions/488348/what-are-your-criteria-
for-choosing-a-framework-or-library and their
websites222https://www.lagarsoft.com/blog/8-tips-for-choosing-the-right-
library333https://www.theserverside.com/tip/7-tips-to-choose-the-right-Java-
library.

To support developers with a comprehensive understanding when they select a
software artifact, crowd-knowledge is known to be helpful [11, 12]. Especially
as emotions are an inseparable part of human nature, it influences developers’
activities as well [13]. Several studies in the software engineering community
discovered that developers express sentiments on libraries [10], APIs [14],
commit messages [15], project artifacts [16], etc. Yet, most of the existing
recommendation systems [6, 17, 4, 18, 5] retrieve multiple artifacts without
considering their quality in terms of developer sentiments while only some
approaches [5, 19] considered discussion data from Stack
Overflow444https://stackoverflow.com/.

These observations motivated us to build a tool named APISens, a software API
sentiment scoring tool with crowd-knowledge (i.e., online developer
sentiments) from diverse resources. APISens retrieves the sentiment scores for
APIs such that the user can recognize its popularity, level of awareness, or
how the public reacts to it.

To construct the tool, we employ a pre-trained Transformer (i.e., a deep
neural network architecture based on the attention mechanism) model, BERT
(Bidirectional Encoder Representations from Transformers) [20]. Its
effectiveness in sentiment analysis has been proved by an empirical study
[12]. APISens consists of two models that are based on BERT-base. The first
model is a recognition model, which distinguishes whether the input discussion
is related to a software artifact context instead of a normal context (e.g.,
decrypt and unscramble may be used for a normal context anywhere). We collect
broad discussion text data from diverse online resources (i.e., Twitter and
YouTube) and filter with the first model. Please note that the discussion with
the normal context is the noise for training the API sentiment analysis model.
Furthermore, we believe that the recognition model, which can distinguish
discussions related to software artifacts, is able to extract API-related ones
when it meets the discussion that contains API-related content. We call the
results of the first model API-related discussions. The second model infers a
score for the input API. It is fine-tuned with API-related discussions to
retrieve the score for an API by analyzing its sentiments. In a nutshell,
APISens takes an API name as text and retrieves a comprehensive sentiment
normalized score for such an API.

In summary, this paper contributes the following:

  * •

Diversity of the resources (i.e., Twitter and YouTube) for fine-tuning the
BERT model to infer the sentiment score that supports users with comprehensive
API scores.

  * •

Construction of a tool that can provide multiple scores including sentiment
and popularity for software APIs such that developers can benefit from
determining more appropriate APIs for their tasks.

##  II Related Work

###  II-A Sentiment Analysis for Software Engineering

Sentiment analysis in software engineering is a computational study of various
viewpoints of developers on diverse software artifacts. Most of them consider
sentiment analysis as a polarity classification. Given a text, the goal of the
study is to predict its sentiment orientation among positive, neutral, or
negative. We introduce representative approaches to the topic.

Stanford CoreNLP [21] is designed for single-sentence classification; it is
trained with the Recursive Neural Tensor Network [22] on the Stanford
Sentiment Treebank [21]. SentiStrength [23] is a lexicon-based approach with
several dictionaries, including both formal and informal terms, while each
term is labeled with a sentiment strength. SentiStrength-SE [24] contains a
domain-specific dictionary that is constructed based on an in-depth
investigation of the results from the previous approach. SentiCR [25] is
designed for code review comments. The results show that Gradient Boosting
Tree [26] is the most suitable model for their data. Senti4SD [27] is a
supervised model that utilizes three different features based on (1) generic
sentiment lexicons [23]; (2) keywords (number of occurrences); (3) word
representation in a Distributional Semantic Model (DSM) specifically trained
on Stack Overflow data. Recently, a study by Zhang et al. [12] was conducted
to assess the performance of these sentiment analysis tools and large pre-
trained models that are frequently leveraged within the software engineering
domain.

###  II-B Deep learning based API Recommendation

Recent API recommendation approaches utilize neural networks to learn and
identify patterns in API usage and documentation. These systems can be trained
on datasets consisting of past API usage and documentation, allowing them to
make informed recommendations for future API selection.

DeepAPI [6] is the first introduced deep learning model to API recommendation,
achieving end-to-end API sequence generation. This idea considered the API
recommendation as a machine translation problem with a Recurrent Neural
Network (RNN) EncoderDecoder model to encode a query into a context vector.
Then, it recommends an API sequence based on the context vector for the query.
API2Vec [28] utilizes unsupervised learning and word embedding techniques to
create embeddings and recommend APIs based on their semantic similarity to a
given context. Huang et al. [19] unveiled BIKER by filtering prospective APIs
according to their alignment with Stack Overflow posts by leveraging the bag-
of-word embedding to optimize the selection of APIs. CLEAR [5] also leverages
Stack Overflow posts and BERT sentence embedding to preserve the semantic
information in queries and posts. Moreover, it employs contrastive learning
[29] to distinguish the queries which are semantically dissimilar but
lexically similar. Although BIKER and CLEAR took into account the crowd-
knowledge in a way with Stack Overflow posts, they only adopted related terms
with the target APIs. Therefore, they still missed considering developer
sentiments.

##  III APISens in Detail

APISens takes an API name and retrieves two types of sentiment scores; one
from discussion and the other from videos. As Figure 1 illustrates, the tool
consists of the following three components: (1) API Recognizer, (2) Discussion
Analyzer, and (3) Video Analyzer. Assuming the data from online platforms are
crawled with the corresponding APIs (e.g., GitHub REST
API555https://docs.github.com/en/rest?apiVersion=2022-11-28), APISens must
take a simple form of API name as a query. Given an API name as a query,
APISens’s pre-trained API Recognizer identifies the API-related discussions
(i.e., tweets in this tool). Once the relevant discussions are detected,
Discussion Analyzer takes them as input to retrieve the sentiment scores.
Video Analyzer concurrently analyzes sentiments from the videos corresponding
to the target API with various aspects (i.e., the number of ‘Likes’,
‘Comments’, and ‘Views’). Finally, the user interface shows the results.
Figure 1 illustrates the steps that are unfolded in the working of the score
retrieval.

Figure 1: Overview of APISens.

###  III-A Datasets (Crowd-knowledge)

We collect datasets from two big platforms (i.e., Twitter and YouTube).
Twitter is one of the biggest social network platforms, and a sentiment
analysis tool can benefit in many aspects. It has a large user base, including
developers, which can provide a broad overview of sentiment about software
APIs, while its large and diverse discussions can ensure that the tool is able
to handle a wide range of sentiment. The data from Twitter is constantly being
updated, which is useful for practitioners to be up-to-date. YouTube is the
largest video-sharing platform with a wide range of content across many
different topics, making it a valuable data source for sentiment analysis.
Many people rely on YouTube to get information and opinions about products,
services, and even software APIs.

In order to obtain API datasets from both Twitter and YouTube, we concurrently
collect data from the platforms. As tweets may be written in various languages
and may contain various forms of noise, such as retweets, mentions of other
users, URLs, and emojis, the data is preprocessed prior to collection. The
preprocessing step converts emojis to their corresponding textual
representation and filters out APIs and corresponding tweets by calculating
the average number of tweets per API (i.e., APIs that are related to less than
the average are omitted). This filtering helps to prevent partial
generalization, as the inclusion of tweets from APIs with only a single tweet
could lead to bias. Then, it removes duplicate tweets and those that are
written in non-English using a Python library (i.e., langdetect). The
detection is possible by taking the language with the highest probability. The
video dataset contains the title, description, the number of ‘Likes’,
‘Comments’, and ‘Views’. Some videos may not contain the statistics of the
information for sentiment analysis, and they are the further candidates to be
eliminated. We initially target 1409 JDK APIs for our research prototype and
collected 56,646 tweets. After processing the data, the number of tweets is
28,278, with the corresponding 476 APIs. While the crawler can be performed in
real-time and APISens can analyze the dynamic data, our research prototype
assumes the dataset is already collected.

###  III-B API Recognizer

Our API recognizer is composed of a fully connected layer on top of a pre-
trained BERT [20] as it has shown to be effective in the task of software
library recognition in tweets [30]. We prepend the [CLS] token to each tweet
as the input to BERT. The final hidden state of the [CLS] is seen as the
aggregated representation of the tweet. We use the embedding output from [CLS]
as the input to the classifier. Our API recognizer is trained with the AdamW
optimizer [31] and we use a linear learning rate scheduler.

The employed model is to predict whether the tweets are related to software
artifacts or not. It was initially trained with a library dataset (i.e., 4,456
tweets with 23 libraries). Still, the key features (i.e., tokens related to
the software artifacts) that such a recognition model learns are not different
for APIs. Furthermore, the literature [30] shows that the mixed-setting (i.e.,
utilizing the mixed dataset across the different libraries) performs the best
with 90% of the F1-score. Therefore, it is a suitable model to leverage with
the same setting to classify the discussions related to our target APIs. Based
on the predictions, the authors manually confirm the labels to enhance the
correctness.

Moreover, we classify the video datasets since there may exist noise, such as
the videos related to the normal terms such as unscramble can be associated
with any topic. As we have the titles and descriptions, we apply the same
procedure to filter out the noise. As a result of the video filtering
procedure, the number of target APIs decreased from 476 to 235, and the number
of associated tweets dropped to 1,606.

###  III-C Discussion Analyzer

Given the API-related discussion dataset, this component performs sentiment
analysis to get a score for retrieval. We again employ the same pre-trained
BERT model that is leveraged in a state-of-the-art sentiment analysis approach
[12]. In the literature, the experimental results show that BERT outperforms
other state-of-the-art techniques that specifically target sentiment analysis
for software engineering downstream tasks (i.e., BERT shows 89% of Micro-avg,
which is 7 percentage points better than the second-best model [12]). The API
dataset used for training was 4,522 Stack Overflow posts related to software
APIs. As the model retrieves class predictions among Positive, Neutral, and
Negative, we convert them to integers 10, 5, and 0, respectively, to calculate
the average scores with a maximum of 10. We finally integrate the results and
calculate the average sentiment score for every tweet for the input API to
provide a comprehensive and concise score.

###  III-D Video Analyzer

Given the list of API-related videos filtered with their title and description
by the API Recognizer, APISens extracts the statistics to support the
sentiment more comprehensively. The statistics include the number of likes,
comments, and views of each video that are leveraged to determine the
sentiment of the content (i.e., the input API). These numbers of a video are
known to be indicative of public sentiment toward the video. A high number of
likes and views imply that the video is popular and well-created, while a high
number of comments can provide insight into the types of discussions and
reactions the video elicits. We believe these numbers can be useful for
sentiment analysis as they directly reflect audiences’ opinions that may
contain emotional orientations. To get a more accurate reflection of the
central tendency in the result set while avoiding the outlier effects, we
decide to provide each median value in the user interface.

##  IV Prototype explanation and Evaluation

###  IV-A Prototype Explanation

The user interface of APISens is designed to be intuitive and easy to use.
Figure 2 illustrates the user interface. The main window is divided into three
main sections: the query panel on the top, the result demonstration panel in
the center, and the chart panel on the bottom. The query panel (①) takes an
API name as the user query. Once the Search button is clicked, it analyzes the
discussion sentiment to retrieve the score to a result demonstration panel
(②). At the same time, it provides the sentiment information from the related
videos in ③. As we mentioned, APISens calculates the median value of the
collected videos of the input API. Furthermore, a bar chart (④) displays
statistics of likes and comments from a certain number of videos related to
the corresponding API in the chart panel. This allows users to recognize the
trend of actual numbers of likes and comments on related videos. Users can re-
sample the number of videos to get more drift using the slide bar (⑤). The bar
(⑥) at the top demonstrates the progress.

Figure 2: User Interface of APISens

###  IV-B Possible Use-cases from User Experience

As our goal is to support practitioners, we also conduct a user
study/discussion evaluating APISens’s usefulness. We ask 2 Research Scientists
and 2 Ph.D. students in Software Engineering who have more than 5 years of
programming experience. To obtain opinions, we first deliver APISens with 20
samples of APIs and let the participants rate (i.e., 1 to 5 where 1 indicates
strongly disagree and 5 denotes strongly agree) their usability and usefulness
as well as discuss the potential. Overall, the participants consider APISens
to be easy-to-use (5 out of 5) and useful (4.05 out of 5). We have identified
and established the promising use cases from the user discussion.

Understanding the popularity of the API at a shot. The main use case for
APISens is, indeed, getting the sentiment score for an API such that the user
can recognize whether the API is widely used and well-supported. Also, it can
give a sense of how much demand there is for the API as well as it allows
users to get valuable context and perspective when comparing different APIs or
considering potential alternatives.

Incorporating it from an IDE. The sentiment information could be used to
personalize API recommendations for individual developers based on their
preferences and needs. Hence, the integration can provide more options. It
also benefits code completion of the IDE, as sentiment information can be a
factor for prioritization for real-time API suggestions.

Connection with sequence recommendation techniques. Once APISens is connected
with API sequence recommendation, it can bring synergies such as
prioritize/re-order recommending APIs with high positive sentiment scores.
This could potentially lead to a better user experience.

Sentiment information as learning features. The sentiment information could be
used as a feature in machine learning models to improve the accuracy of API
recommendations. For example, as there is a strong correlation between API
sentiment and API popularity or usage, including such information as a feature
in a model can potentially improve performance.

##  V Further Ideas

Based on our observations and early feedback from the users, we believe that
APISens has the potential to be a useful tool for API comprehension. Here are
some ideas to further improvement: Concurrent support for multiple APIs.
Developers tend to compare multiple APIs to find the best API for a particular
task or to stay up to date with industry trends. This could help them stay
informed about new APIs and best practices and ensure that they are using the
most popular and effective APIs. Training the models with a bigger dataset. To
maximize the performance of the tool, the pre-trained models can be fine-tuned
with a bigger dataset. As statistical power and generalizability of the model
can be derived by the bigger and better dataset, APISens can be further fine-
tuned for more reliable results. Moreover, covering more APIs may help our
tool to be more generally used by developers. Further support with similar
APIs that perform the same functionality. APISens can encompass a function
that can support similar APIs as well as their sentiment information
corresponding to the queried one. This can further boost efficiency and ease
the comparison and determination process for more suitable APIs.

## References

  * [1] S. E. Sim, M. Umarji, S. Ratanotayanon, and C. V. Lopes, “How well do search engines support code retrieval on the web?” _ACM Transactions on Software Engineering and Methodology_ , vol. 21, no. 1, pp. 4:1–4:25, 2011.
  * [2] R. E. Gallardo-Valencia and S. Elliott Sim, “Internet-scale code search,” in _Proceedings of the 2009 ICSE Workshop on Search-Driven Development-Users, Infrastructure, Tools and Evaluation_. IEEE Computer Society, 2009, pp. 49–52.
  * [3] X. Xia, L. Bao, D. Lo, P. S. Kochhar, A. E. Hassan, and Z. Xing, “What do developers search for on the web?” _Empirical Software Engineering_ , vol. 22, no. 6, pp. 3149–3185, 2017.
  * [4] F. Thung, D. Lo, and J. Lawall, “Automated library recommendation,” in _2013 20th Working conference on reverse engineering (WCRE)_. IEEE, 2013, pp. 182–191.
  * [5] M. Wei, N. S. Harzevili, Y. Huang, J. Wang, and S. Wang, “Clear: contrastive learning for api recommendation,” in _Proceedings of the 44th International Conference on Software Engineering_ , 2022, pp. 376–387.
  * [6] X. Gu, H. Zhang, D. Zhang, and S. Kim, “Deep api learning,” in _Proceedings of the 2016 24th ACM SIGSOFT international symposium on foundations of software engineering_ , 2016, pp. 631–642.
  * [7] Q. Huang, X. Xia, Z. Xing, D. Lo, and X. Wang, “Api method recommendation without worrying about the task-api knowledge gap,” in _2018 33rd IEEE/ACM International Conference on Automated Software Engineering (ASE)_. IEEE, 2018, pp. 293–304.
  * [8] X. Liu, L. Huang, and V. Ng, “Effective api recommendation without historical software repositories,” in _Proceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering_ , 2018, pp. 282–292.
  * [9] A. T. Nguyen, M. Hilton, M. Codoban, H. A. Nguyen, L. Mast, E. Rademacher, T. N. Nguyen, and D. Dig, “Api code recommendation using statistical learning from fine-grained changes,” in _Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering_ , 2016, pp. 511–522.
  * [10] B. Xu, L. An, F. Thung, F. Khomh, and D. Lo, “Why reinventing the wheels? an empirical study on library reuse and re-implementation,” _Empirical Software Engineering_ , vol. 25, no. 1, pp. 755–789, 2020.
  * [11] E. Biswas, M. E. Karabulut, L. Pollock, and K. Vijay-Shanker, “Achieving reliable sentiment analysis in the software engineering domain using bert,” in _2020 IEEE International Conference on Software Maintenance and Evolution (ICSME)_. IEEE, 2020, pp. 162–173.
  * [12] T. Zhang, B. Xu, F. Thung, S. A. Haryono, D. Lo, and L. Jiang, “Sentiment analysis for software engineering: How far can pre-trained transformer models go?” in _2020 IEEE International Conference on Software Maintenance and Evolution (ICSME)_. IEEE, 2020, pp. 70–80.
  * [13] M. De Choudhury and S. Counts, “Understanding affect in the workplace via social media,” in _Proceedings of the 2013 conference on Computer supported cooperative work_ , 2013, pp. 303–316.
  * [14] G. Uddin, O. Baysal, L. Guerrouj, and F. Khomh, “Understanding how and why developers seek and analyze api-related opinions,” _IEEE Transactions on Software Engineering_ , vol. 47, no. 4, pp. 694–735, 2019.
  * [15] E. Guzman, D. Azócar, and Y. Li, “Sentiment analysis of commit comments in github: an empirical study,” in _Proceedings of the 11th working conference on mining software repositories_ , 2014, pp. 352–355.
  * [16] A. Murgia, P. Tourani, B. Adams, and M. Ortu, “Do developers feel emotions? an exploratory analysis of emotions in software artifacts,” in _Proceedings of the 11th working conference on mining software repositories_ , 2014, pp. 262–271.
  * [17] X. Gu, H. Zhang, and S. Kim, “Deep code search,” in _2018 IEEE/ACM 40th International Conference on Software Engineering (ICSE)_. IEEE, 2018, pp. 933–944.
  * [18] K. Kim, D. Kim, T. F. Bissyandé, E. Choi, L. Li, J. Klein, and Y. L. Traon, “Facoy: a code-to-code search engine,” in _Proceedings of the 40th International Conference on Software Engineering_ , 2018, pp. 946–957.
  * [19] L. Cai, H. Wang, Q. Huang, X. Xia, Z. Xing, and D. Lo, “Biker: a tool for bi-information source based api method recommendation,” in _Proceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering_ , 2019, pp. 1075–1079.
  * [20] J. Devlin, M.-W. Chang, K. Lee, and K. Toutanova, “Bert: Pre-training of deep bidirectional transformers for language understanding,” _arXiv preprint arXiv:1810.04805_ , 2018.
  * [21] R. Socher, A. Perelygin, J. Wu, J. Chuang, C. D. Manning, A. Y. Ng, and C. Potts, “Recursive deep models for semantic compositionality over a sentiment treebank,” in _Proceedings of the 2013 conference on empirical methods in natural language processing_ , 2013, pp. 1631–1642.
  * [22] R. K. Bakshi, N. Kaur, R. Kaur, and G. Kaur, “Opinion mining and sentiment analysis,” in _2016 3rd international conference on computing for sustainable global development (INDIACom)_. IEEE, 2016, pp. 452–455.
  * [23] M. Thelwall, K. Buckley, G. Paltoglou, D. Cai, and A. Kappas, “Sentiment strength detection in short informal text,” _Journal of the American society for information science and technology_ , vol. 61, no. 12, pp. 2544–2558, 2010.
  * [24] M. R. Islam and M. F. Zibran, “Leveraging automated sentiment analysis in software engineering,” in _2017 IEEE/ACM 14th International Conference on Mining Software Repositories (MSR)_. IEEE, 2017, pp. 203–214.
  * [25] T. Ahmed, A. Bosu, A. Iqbal, and S. Rahimi, “Senticr: a customized sentiment analysis tool for code review interactions,” in _2017 32nd IEEE/ACM International Conference on Automated Software Engineering (ASE)_. IEEE, 2017, pp. 106–111.
  * [26] M. Pennacchiotti and A.-M. Popescu, “Democrats, republicans and starbucks afficionados: user classification in twitter,” in _Proceedings of the 17th ACM SIGKDD international conference on Knowledge discovery and data mining_ , 2011, pp. 430–438.
  * [27] F. Calefato, F. Lanubile, F. Maiorano, and N. Novielli, “Sentiment polarity detection for software development,” _Empirical Software Engineering_ , vol. 23, no. 3, pp. 1352–1382, 2018.
  * [28] T. D. Nguyen, A. T. Nguyen, H. D. Phan, and T. N. Nguyen, “Exploring api embedding for api usages and applications,” in _2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE)_. IEEE, 2017, pp. 438–449.
  * [29] T. Chen, S. Kornblith, M. Norouzi, and G. Hinton, “A simple framework for contrastive learning of visual representations,” in _International conference on machine learning_. PMLR, 2020, pp. 1597–1607.
  * [30] T. Zhang, D. P. Chandrasekaran, F. Thung, and D. Lo, “Benchmarking library recognition in tweets,” in _2022 IEEE/ACM 30th International Conference on Program Comprehension (ICPC)_ , 2022, pp. 343–353.
  * [31] I. Loshchilov and F. Hutter, “Decoupled weight decay regularization,” _arXiv preprint arXiv:1711.05101_ , 2017.