Abstract
Today's programming languages are supported by powerful third-party APIs. For a given application domain, it is common to have many competing APIs that provide similar functionality. Programmer productivity therefore depends heavily on the programmer's ability to discover suitable APIs both during an initial coding phase, as well as during software maintenance. The aim of this work is to support the discovery and migration of math APIs. Math APIs are at the heart of many application domains ranging from machine learning to scientific computations. Our approach, called M ath F inder , combines executable specifications of mathematical computations with unit tests (operational specifications) of API methods. Given a math expression, M ath F inder synthesizes pseudo-code comprised of API methods to compute the expression by mining unit tests of the API methods. We present a sequential version of our unit test mining algorithm and also design a more scalable data-parallel version. We perform extensive evaluation of M ath F inder (1) for API discovery , where math algorithms are to be implemented from scratch and (2) for API migration , where client programs utilizing a math API are to be migrated to another API. We evaluated the precision and recall of M ath F inder on a diverse collection of math expressions, culled from algorithms used in a wide range of application areas such as control systems and structural dynamics. In a user study to evaluate the productivity gains obtained by using M ath F inder for API discovery, the programmers who used M ath F inder finished their programming tasks twice as fast as their counterparts who used the usual techniques like web and code search, IDE code completion, and manual inspection of library documentation. For the problem of API migration, as a case study, we used M ath F inder to migrate Weka, a popular machine learning library. Overall, our evaluation shows that M ath F inder is easy to use, provides highly precise results across several math APIs and application domains even with a small number of unit tests per method, and scales to large collections of unit tests.
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have