- Written by Thomas Weise

Today, Mr. Alexander Jahl from the Distributed Systems Group of the Department of Electrical Engineering and Computer Science of the University of Kassel in Germany published the source code of the *Distributed Algorithms Simulator* on GitHub. This is an educational piece of software written in Java, which allows students to implement many of the algorithms from the field of distributed systems, ranging from distributed critical sections over time synchronization to message flooding to the distributed computation of the greatest common divisor. The simulator then shows a visualization of how the algorithms progress and how the messages travel over the network.

The original code of the *Distributed Algorithms Simulator* was written by me back in 2007 to support the students of the lecture "Basisalgorithmen Verteilter Systeme" held by my PhD father Prof. Dr. Kurt Geihs. It is very rewarding and I am happy to see that this piece of educational software is still doing its job after more than a decade. I hope that the 13 generations of students in the lecture as well as the colleagues who held the exercises for them after me (and who have maintained and improved the software) found it helpful in their studies and teaching, respectively. Now that it became open source, I am curious to see how long it can remain useful.

Thank you, Alex, for maintaining it for so long and for making it OSS!

- Written by Thomas Weise

### Introduction

A long time ago, when I was a PhD student, I wrote the book *Global Optimization Algorithms – Theory and Application*, which I published on my personal website as pdf. Since I recently developed the short course Metaheuristics for Smart Manufacturing and had a very nice experience teaching it, I have decided to begin to write a new book about optimization, *"An Introduction to Optimization Algorithms,"* to incorporate my experience during the past ten years working in the field. When writing such a book, there are a couple of desirable features to improve the workflow and results, such as:

- using a version control and distributed authoring system, which allows me to easily work on and extend the book as well as to make changes to the book and commit them wherever I am,
- automated conversion of the book's sources to PDF, ideally whenever I commit a change,
- automated provision of the PDF version of the book at an online location,
- the generation of an electronic version of the book more suitable for handheld devises like mobile phones, i.e., an EPUB version, which should be automatically be built and provisioned like the PDF version,
- maybe even the possibility that readers can file change requests, ask questions, or propose content to add in a structured way, and
- the option to edit source code examples in an independent repository and update the book whenever they change.

In this post, I want to discuss a process, workflow, and tool support I came up with to achieve all of these features. This workflow has been designed in a way so that you can use it too, easily, for your own open books. Here we first describe the setup, which is stuff you have to do once and only once. After that, we discuss the features and commands that you have available inside your book. You can also find a set of slides about this project here.

- Written by Thomas Weise

`R`

is a powerful and efficient programming language for statistics, modeling, and data mining. Here I want to provide a quick note on the question *"How do I get the name of a function in R?"*.

Consider the scenario where you write a function `myFun`

in the form of ` <- function(f) { … }`

that accepts another function `f`

as parameter and computes something. Maybe your computation takes a lot of time, so you want to output some logging information which contains the name of the function `f`

as well, so the reader can see what is going on. Or maybe you want to generate a report with the results from several functions, so you want the "function names" to be the section titles of the report. Getting the name of a function (or any object) in `R`

is actually quite tricky. Here I discuss a working approach.

- Written by Thomas Weise

Today, we published the first version of a new `R`

package at github.com/thomasWeise/dataTransformeR for normalizing and transforming numerical data.

When we fit models to data, we often do not want to use the raw data as-is. Instead, we usually want to fit models to normalized or log-scaled versions of the data. If all data elements are in `[0,1]`

, this makes it easier to pick initial parameter values for models. If there are exponential relationships present in data sets, we may want to get rid of them by log-scaling the data. This means that, after the models have been fitted, we need to transform the model back by applying the inverse of the data transformation to the model.

This package uses our functionComposeR package to construct and apply such bijective transformations. The core of this package are the `Transformation`

and `TransformedData`

S4 classes and the routines to construct instances of them.

Read more: dataTransformeR: An R Package for Normalizing and Transforming Numerical Data

- Written by Thomas Weise

Today, we published the first version of a new `R`

package at github.com/thomasWeise/functionComposeR for composing and canonicalizing functions. When we combine functions in `R`

in the form of `g(f(x))`

, we have the problem that the result is rarely human readable. This results from two problems. The first problem is that variables inside the function are evaluated in the environment of the function and even if they are constants, they will remain as variables. Thus, when printing a function `f(x)`

, I may sometimes something like a `k*x`

inside, but may not know the value of `k`

, even though it may be perfectly known in the function's environment and a constant. The second problem is that this also applies to nested functions, so there may be something like `f=function(x) x+g(x)`

where `g`

is a well-defined function, but printing `f`

will not reveal the nature of `g`

. Both of these issues also make evaluating the functions slower, as we could resolve the variables to constants and inline the nested functions' bodies, but instead evaluate them as variables and function calls, respectively. With our new package, we try to solve all of these issues at once. We provide a tool for combining functions and one for canonicalizing functions, i.e., for resolving all resolve-able components of a function.

Read more: functionComposeR: An R Package for Composing Functions

Page 1 of 2