Exercise 3
Compare changes
Theisen, Lambert authored
```
```
```
```
```
```
```
```
```
```
```
```
```
```
```
```
```
```
```
```
```
```
```
In Julia concrete types are always a leaf of the type tree, i.e. they cannot be inherited from each other. For a C++ or Python person (as a few of us) this seems restrictive at first, but it takes away a lot of unnecessary complexity from the type hierarchy. We will not give further information now, the reason will be more clear at the end of this notebook.
In Julia sind konkrete Typen immer ein Blatt des Typbaums, d.h., sie können nicht voneinander abgeleitet werden. Für jemanden, der mit C++ oder Python vertraut ist (wie einige von uns), mag dies zunächst einschränkend erscheinen, aber es entfernt eine Menge unnötiger Komplexität aus der Typenhierarchie. Wir werden jetzt keine weiteren Informationen geben, der Grund wird am Ende dieses Notebooks klarer sein.
- The first possibility is to organize the book according to methods of cooking: each chapter explains in detail a method of cooking. For example, we will have **Chapter 1: baking**, **Chapter 2: frying** and so on. The drawback of this approach is that whenever we add a new ingredient, we have to change multiple chapters. This approach, focused on the action rather than on ingredients, is typical of functional programming languages.
- The second possibility is to organize the book according to ingredients: each chapter focuses on one ingredient. For example, we will have **Chapter 1: potatoes**, **Chapter 2: fish** and so on. The drawback of this approach is that whenever we add a new recipe, we have again to change multiple chapters. This approach is focused on the ingredients (data) and it is typical of object-oriented programming, where we will have something like:
- Julia takes a third approach called **multiple dispatch** which decouples the action from the data. In our hypothetical recipe book, we will have chapters like **Chapter 1: baking potatoes**, **Chapter 2: frying potatoes**, **Chapter 3: baking fish**, **Chapter 4: frying fish** and so on. Each of the chapters will contain something like:
Um das Konzept des Mehrfachdispatchs vollständig zu verstehen, werden wir eine Analogie verwenden. Wir werden so tun, als ob eine Programmiersprache ein Werkzeug zum Schreiben eines Kochbuches ist. Ein Rezept kombiniert eine Zubereitungsmethode (zum Beispiel Backen, Braten) mit einer Zutat (zum Beispiel Kartoffeln, Karotten, Fisch).
- Die erste Möglichkeit besteht darin, das Buch nach Zubereitungsmethoden zu organisieren: Jedes Kapitel erklärt ausführlich eine Zubereitungsmethode. Zum Beispiel haben wir **Kapitel 1: Backen**, **Kapitel 2: Braten** und so weiter. Der Nachteil dieses Ansatzes ist, dass wir immer dann, wenn wir eine neue Zutat hinzufügen, mehrere Kapitel ändern müssen. Dieser Ansatz, der sich auf die Aktion und nicht auf die Zutaten konzentriert, ist typisch für funktionale Programmiersprachen.
- Die zweite Möglichkeit besteht darin, das Buch nach Zutaten zu organisieren: Jedes Kapitel konzentriert sich auf eine Zutat. Zum Beispiel haben wir **Kapitel 1: Kartoffeln**, **Kapitel 2: Fisch** und so weiter. Der Nachteil dieses Ansatzes ist, dass wir immer dann, wenn wir ein neues Rezept hinzufügen, erneut mehrere Kapitel ändern müssen. Dieser Ansatz konzentriert sich auf die Zutaten (Daten) und ist typisch für objektorientierte Programmierung, bei der wir etwas Ähnliches haben könnten wie:
- Julia verfolgt einen dritten Ansatz namens **Mehrfachdispatch**, bei dem die Aktion von den Daten entkoppelt wird. In unserem hypothetischen Kochbuch haben wir Kapitel wie **Kapitel 1: Kartoffeln backen**, **Kapitel 2: Kartoffeln braten**, **Kapitel 3: Fisch backen**, **Kapitel 4: Fisch braten** und so weiter. Jedes dieser Kapitel enthält etwas Ähnliches wie:
```
```
```
```
In beiden Fällen bedeutet die Syntax `str::String` und `n::Integer`, dass die jeweilige Methode nur während der Zuordnung berücksichtigt wird, wenn das Argument `str` vom Typ `String` ist und `n` ein `Integer` (oder Untertyp) ist. Da Julia immer zur spezifischsten Methode dispatcht, falls mehrere Methoden übereinstimmen, ist dies alles, was wir tun müssen:
```
```
```
```
```
```
```
```
```
```
```
```
```
```
```
which usually allows for more flexible code. Examples are Python or MATLAB. In contrast, so-called **statically-typed** languages (think FORTRAN or C++), require types to be already known before runtime when the program is compiled. This allows both to check more thoroughly for errors (which can manifest in mismatched types) and it usually brings a gain in performance because more things about the memory layout of the program is known at compile time. As a result, aspects such as vectorization, contiguous alignment of data, preallocation of memory can be leveraged more easily.
In der Programmiersprachen-Theorie fallen Typsysteme traditionell in zwei Kategorien. In **dynamisch typisierten** Sprachen wird der Typ eines Werts oder Ausdrucks nur zur Laufzeit abgeleitet, was in der Regel flexibleren Code ermöglicht. Beispiele hierfür sind Python oder MATLAB. Im Gegensatz dazu erfordern sogenannte **statisch typisierte** Sprachen (denken Sie an FORTRAN oder C++), dass die Typen bereits vor der Laufzeit bekannt sind, wenn das Programm kompiliert wird. Dies ermöglicht eine gründlichere Überprüfung auf Fehler (die sich in nicht übereinstimmenden Typen äußern können), und es führt normalerweise zu einer Leistungssteigerung, da mehr Informationen über die Speicherlayout des Programms zur Kompilierzeit bekannt sind. Als Ergebnis können Aspekte wie Vektorisierung, kontinuierliche Ausrichtung von Daten und Vorbelegung von Speicher leichter genutzt werden.
```
When the code is precompiled before execution, the compiler has the information about the type of all the variables in the program. It will then search the best possible method for each of those. If a specific and highly efficient one is found, that will be used. If a specific one is missing, it will use the next possibility in the type tree, which will still work even if not as efficiently.
**Note:** this look up is the reason why it is not possible to instantiate abstract types, having variables of abstract types would make this operation unnecessary complicated. Moreover, it also reflects reality: a generic vegetable does not physically exist, we only have potatoes, carrots, eggplants and so on.
Wenn der Code vor der Ausführung vorkompiliert wird, hat der Compiler Informationen über den Typ aller Variablen im Programm. Er wird dann die beste mögliche Methode für jede dieser Variablen suchen. Wenn eine spezifische und hoch effiziente Methode gefunden wird, wird diese verwendet. Wenn eine spezifische Methode fehlt, wird die nächste Möglichkeit im Typbaum verwendet, die immer noch funktioniert, wenn auch nicht so effizient.
**Hinweis:** Diese Suche ist der Grund, warum es nicht möglich ist, abstrakte Typen zu instanziieren. Die Verwendung von Variablen abstrakter Typen würde diesen Vorgang unnötig kompliziert machen. Außerdem spiegelt es auch die Realität wider: Ein generisches Gemüse existiert physisch nicht, wir haben nur Kartoffeln, Karotten, Auberginen und so weiter.
```
@nottolme Was that intended or just a failed Strg + V pressing?