Colour reverse learning and animal personalities: the advantage of behavioural diversity assessed with agent-based simulations

Foraging bees use colour cues to help identify rewarding from unrewarding flowers, but as conditions change, bees may require behavioural flexibility to reverse their learnt preferences. Perceptually similar colours are learnt slowly by honeybees and thus potentially pose a difficult task to reverse-learn. Free-flying honeybees (N = 32) were trained to learn a fine colour discrimination task that could be resolved at ca. 70% accuracy following extended differential conditioning, and were then tested for their ability to reverse-learn this visual problem multiple times. Subsequent analyses identified three different strategies: ‘Deliberative-decisive’ bees that could, after several flower visits, decisively make a large change to learnt preferences; ‘Fickle- circumspect’ bees that changed their preferences by a small amount every time they encountered evidence in their environment; and ‘Stay’ bees that did not change from their initially learnt preference. The next aim was to determine if there was any advantage to a colony in maintaining bees with a variety of decision-making strategies. To understand the potential benefits of the observed behavioural diversity agent-based computer simulations were conducted by systematically varying parameters for flower reward switch oscillation frequency, flower handling time, and fraction of defective ‘target’ stimuli. These simulations revealed that when there is a relatively high frequency of reward reversals, fickle-circumspect bees are more efficient at nectar collection. However, as the reward reversal frequency decreases the performance of deliberative-decisive bees becomes most efficient. These findings show there to be an evolutionary benefit for honeybee colonies with individuals exhibiting these different strategies for managing resource change. The strategies have similarities to some complex decision-making processes observed in humans, and algorithms implemented in artificial intelligence systems

Designing and evaluating the usability of a machine learning API for rapid prototyping music technology

To better support creative software developers and music technologists' needs, and to empower them as machine learning users and innovators, the usability of and developer experience with machine learning tools must be considered and better understood. We review background research on the design and evaluation of application programming interfaces (APIs), with a focus on the domain of machine learning for music technology software development. We present the design rationale for the RAPID-MIX API, an easy-to-use API for rapid prototyping with interactive machine learning, and a usability evaluation study with software developers of music technology. A cognitive dimensions questionnaire was designed and delivered to a group of 12 participants who used the RAPID-MIX API in their software projects, including people who developed systems for personal use and professionals developing software products for music and creative technology companies. The results from the questionnaire indicate that participants found the RAPID-MIX API a machine learning API which is easy to learn and use, fun, and good for rapid prototyping with interactive machine learning. Based on these findings, we present an analysis and characterization of the RAPID-MIX API based on the cognitive dimensions framework, and discuss its design trade-offs and usability issues. We use these insights and our design experience to provide design recommendations for ML APIs for rapid prototyping of music technology. We conclude with a summary of the main insights, a discussion of the merits and challenges of the application of the CDs framework to the evaluation of machine learning APIs, and directions to future work which our research deems valuable

Classification of changes in API evolution

Applications typically communicate with each other, accessing and exposing data and features by using Application Programming Interfaces (APIs). Even though API consumers expect APIs to be steady and well established, APIs are prone to continuous changes, experiencing different evolutive phases through their lifecycle. These changes are of different types, caused by different needs and are affecting consumers in different ways. In this paper, we identify and classify the changes that often happen to APIs, and investigate how all these changes are reflected in the documentation, release notes, issue tracker and API usage logs. The analysis of each step of a change, from its implementation to the impact that it has on API consumers, will help us to have a bigger picture of API evolution. Thus, we review the current state of the art in API evolution and, as a result, we define a classification framework considering both the changes that may occur to APIs and the reasons behind them. In addition, we exemplify the framework using a software platform offering a Web API, called District Health Information System (DHIS2), used collaboratively by several departments of World Health Organization (WHO).Peer ReviewedPostprint (author's final draft

Technical pre-study for the ExMS project

This report aims to give an overview of software and hardware platforms available now or in the near future for building a prototype of an ExMS application (for an overview of the ExMS project, see Appendix). The report also gives an overview of the different technologies for building third-party mobile client software applications that are in use today. The report is composed of three sections. The first section is a general discussion on mobile client software and the different technologies that can be used to develop third-party mobile client software. The next section continues with a specific discussion on ExMS and answers the following questions: What is the general architecture of the ExMS application? What alternatives exist for implementing the ExMS prototype? The final section of the report is a recommendation of hardware and software platform for building the ExMS prototype

Human-Centric Program Synthesis

Program synthesis techniques offer significant new capabilities in searching for programs that satisfy high-level specifications. While synthesis has been thoroughly explored for input/output pair specifications (programming-by-example), this paper asks: what does program synthesis look like beyond examples? What actual issues in day-to-day development would stand to benefit the most from synthesis? How can a human-centric perspective inform the exploration of alternative specification languages for synthesis? I sketch a human-centric vision for program synthesis where programmers explore and learn languages and APIs aided by a synthesis tool