737 lines
20 KiB
Plaintext
737 lines
20 KiB
Plaintext
---
|
||
notebook-links: false
|
||
engine: julia
|
||
---
|
||
|
||
```{julia}
|
||
#| error: false
|
||
#| echo: false
|
||
#| output: false
|
||
using InteractiveUtils
|
||
import QuartoNotebookWorker
|
||
Base.stdout = QuartoNotebookWorker.with_context(stdout)
|
||
myactive_module() = Main.Notebook
|
||
Base.active_module() = myactive_module()
|
||
```
|
||
|
||
|
||
# Das Typsystem von Julia
|
||
|
||
Man kann umfangreiche Programme in Julia schreiben, ohne auch nur eine einzige Typdeklaration verwenden zu müssen. Das ist natürlich Absicht und soll die Arbeit der Anwender vereinfachen.
|
||
|
||
Wir blicken jetzt trotzdem mal unter die Motorhaube.
|
||
|
||
## Die Typhierarchie am Beispiel der numerischen Typen
|
||
|
||
Das Typsystem hat die Struktur eines Baums, dessen Wurzel der Typ `Any` ist. Mit den Funktionen `subtypes()` und `supertype()` kann man den Baum erforschen. Sie zeigen alle Kinder bzw. die Mutter eines Knotens an.
|
||
|
||
```{julia}
|
||
subtypes(Int64)
|
||
```
|
||
Das Ergebnis ist eine leere Liste von Typen. `Int64` ist ein sogenannter **konkreter Typ** und hat keine Untertypen.
|
||
|
||
Wir klettern jetzt mal die Typhierarchie auf diesem Ast nach oben bis zur Wurzel (Informatiker-Bäume stehen bekanntlich immer auf dem Kopf).
|
||
```{julia}
|
||
supertype(Int64)
|
||
```
|
||
```{julia}
|
||
supertype(Signed)
|
||
```
|
||
```{julia}
|
||
supertype(Integer)
|
||
```
|
||
```{julia}
|
||
supertype(Real)
|
||
```
|
||
```{julia}
|
||
supertype(Number)
|
||
```
|
||
Das wäre übrigens auch schneller gegangen: Die Funktion `supertypes()` (mit Plural-s) zeigt alle Vorfahren an.
|
||
|
||
|
||
```{julia}
|
||
supertypes(Int64)
|
||
```
|
||
|
||
Nun kann man sich die Knoten angucken:
|
||
|
||
{{< embed ../notebooks/nb-types.ipynb#nb3 >}}
|
||
|
||
Mit einer kleinen rekursiven Funktion kann man schnell einen ganzen (Unter-)Baum ausdrucken:
|
||
|
||
{{< embed ../notebooks/nb-types.ipynb#nb1 >}}
|
||
|
||
::::{.content-hidden unless-format="xxx"}
|
||
|
||
...und natürlich gibt es da auch ein Julia-Paket:
|
||
|
||
{{< embed ../notebooks/nb-types.ipynb#nb2 >}}
|
||
|
||
:::
|
||
|
||
|
||
Hier das Ganze nochmal als Bild (gemacht mit LaTeX/[TikZ](https://tikz.dev/tikz-trees))
|
||
|
||
::: {.content-visible when-format="html"}
|
||
{width=80%}
|
||
:::
|
||
|
||
::: {.content-visible when-format="pdf"}
|
||
{width=60%}
|
||
:::
|
||
|
||
|
||
Natürlich hat Julia nicht nur numerische Typen. Die Anzahl der direkten Abkömmlinge (Kinder) von `Any` ist
|
||
|
||
```{julia}
|
||
length(subtypes(Any))
|
||
```
|
||
und mit (fast) jedem Paket, das man mit `using ...` lädt, werden es mehr.
|
||
|
||
|
||
## Abstrakte und Konkrete Typen
|
||
|
||
- Ein Objekt hat immer einen **konkreten** Typ.
|
||
- Konkrete Typen haben keine Untertypen mehr, sie sind immer „Blätter“ des Baumes.
|
||
- Konkrete Typen spezifizieren eine konkrete Datenstruktur.
|
||
|
||
:::{.xxx}
|
||
|
||
:::
|
||
|
||
- Abstrakte Typen können nicht instanziiert werden, d.h., es gibt keine Objekte mit diesem Typ.
|
||
- Sie definieren eine Menge von konkreten Typen und gemeinsame Methoden für diese Typen.
|
||
- Sie können daher in der Definition von Funktionstypen, Argumenttypen, Elementtypen von zusammengesetzten Typen u.ä. verwendet werden.
|
||
|
||
|
||
|
||
Zum **Deklarieren** *und* **Testen** der "Abstammung" innerhalb der Typhierarchie gibt es einen eigenen Operator:
|
||
|
||
```{julia}
|
||
Int64 <: Number
|
||
```
|
||
|
||
Zum Testen, ob ein Objekt einen bestimmten Typ (oder einen abstrakten Supertyp davon) hat, dient `isa(object, typ)`. Es wird meist in der Infix-Form verwendet und sollte als Frage `x is a T?` gelesen werden.
|
||
|
||
```{julia}
|
||
x = 17.2
|
||
|
||
42 isa Int64, 42 isa Real, x isa Real, x isa Float64, x isa Integer
|
||
```
|
||
|
||
|
||
Da abstrakte Typen keine Datenstrukturen definieren, ist ihre Definition recht schlicht. Entweder sie stammen direkt von `Any` ab:
|
||
|
||
```{julia}
|
||
abstract type MySuperType end
|
||
|
||
supertype(MySuperType)
|
||
```
|
||
|
||
oder von einem anderen abstrakten Typ:
|
||
|
||
```{julia}
|
||
abstract type MySpecialNumber <: Integer end
|
||
|
||
supertypes(MySpecialNumber)
|
||
```
|
||
|
||
Mit der Definition werden die abstrakten Typen an einer Stelle des Typ-Baums "eingehängt".
|
||
|
||
## Die numerischen Typen `Bool` und `Irrational`
|
||
|
||
Da sie im Baum der numerischen Typen zu sehen sind, seien sie kurz erklärt:
|
||
|
||
`Bool` ist numerisch im Sinne von `true=1, false=0`:
|
||
|
||
```{julia}
|
||
true + true + true, false - true, sqrt(true), true/4
|
||
```
|
||
|
||
`Irrational` ist der Typ einiger vordefinierter Konstanten wie `π` und `ℯ`.
|
||
Laut [Dokumentation](https://docs.julialang.org/en/v1/base/numbers/#Base.AbstractIrrational) ist `Irrational` ein *"Number type representing an exact irrational value, which is automatically rounded to the correct precision in arithmetic operations with other numeric quantities".*
|
||
|
||
## Union-Typen
|
||
|
||
Falls die Baum-Hierarchie nicht ausreicht, kann man auch abstrakte Typen als Vereinigung beliebiger (abstrakter und konkreter) Typen definieren.
|
||
|
||
```{julia}
|
||
IntOrString = Union{Int64,String}
|
||
```
|
||
|
||
:::{.callout-note .titlenormal}
|
||
|
||
## Beispiel
|
||
Das Kommando `methods(<)` zeigt, dass unter den über 70 Methoden, die für den Vergleichsoperator definiert sind, einige auch *union types* verwenden, z.B. ist
|
||
```julia
|
||
<(x::Union{Float16, Float32, Float64}, y::BigFloat)
|
||
```
|
||
eine Methode für den Vergleich einer Maschinenzahl fester Länge mit einer Maschinenzahl beliebiger Länge.
|
||
:::
|
||
|
||
## Zusammengesetzte (_composite_) Typen: `struct`
|
||
|
||
Eine `struct` ist eine Zusammenstellung von mehreren benannten Feldern und definiert einen konkreten Typ.
|
||
|
||
```{julia}
|
||
abstract type Point end
|
||
|
||
mutable struct Point2D <: Point
|
||
x :: Float64
|
||
y :: Float64
|
||
end
|
||
|
||
mutable struct Point3D <: Point
|
||
x :: Float64
|
||
y :: Float64
|
||
z :: Float64
|
||
end
|
||
```
|
||
|
||
Wie wir schon bei Ausdrücken der Form `x = Int8(33)` gesehen haben, kann man Typnamen direkt als Konstruktoren einsetzen:
|
||
|
||
```{julia}
|
||
p1 = Point2D(1.4, 3.5)
|
||
```
|
||
|
||
|
||
```{julia}
|
||
p1 isa Point3D, p1 isa Point2D, p1 isa Point
|
||
```
|
||
|
||
|
||
Die Felder einer `struct` können über ihren Namen mit dem `.`-Operator adressiert werden.
|
||
|
||
```{julia}
|
||
p1.y
|
||
```
|
||
|
||
Da wir unsere `struct` als `mutable` deklariert haben, können wir das Objekt `p1` modifizieren, indem wir den Feldern neue Werte zuweisen.
|
||
|
||
```{julia}
|
||
p1.x = 3333.4
|
||
p1
|
||
```
|
||
|
||
Informationen über den Aufbau eines Typs oder eines Objekts von diesem Typ liefert `dump()`.
|
||
|
||
```{julia}
|
||
dump(Point3D)
|
||
```
|
||
|
||
|
||
```{julia}
|
||
dump(p1)
|
||
```
|
||
|
||
## Funktionen und *Multiple dispatch*
|
||
|
||
:::{.callout-note .titlenormal}
|
||
|
||
## Objekte, Funktionen, Methoden
|
||
|
||
In klassischen objektorientierten Sprachen wie C++/Java haben Objekte üblicherweise mit ihnen assoziierte Funktionen, die Methoden des Objekts.
|
||
|
||
In Julia gehören Methoden zu einer Funktion und nicht zu einem Objekt.
|
||
(Eine Ausnahme sind die Konstruktoren, also Funktionen, die genauso heißen wie ein Typ und ein Objekt dieses Typs erzeugen.)
|
||
|
||
Sobald man einen neuen Typ definiert hat, kann man sowohl neue als auch bestehende Funktionen um neue Methoden für diesen Typ ergänzen.
|
||
|
||
- Eine Funktion kann mehrfach für verschiedene Argumentlisten (Typ und Anzahl) definiert werden.
|
||
- Die Funktion hat dann mehrere Methoden.
|
||
- Beim Aufruf wird an Hand der konkreten Argumente entschieden, welche Methode genutzt wird *(multiple dispatch)*.
|
||
- Es ist typisch für Julia, dass für Standardfunktionen viele Methoden definiert sind. Diese können problemlos um weitere Methoden für eigene Typen erweitert werden.
|
||
|
||
:::
|
||
|
||
|
||
Den Abstand zwischen zwei Punkten implementieren wir als Funktion mit zwei Methoden:
|
||
|
||
```{julia}
|
||
function distance(p1::Point2D, p2::Point2D)
|
||
sqrt((p1.x-p2.x)^2 + (p1.y-p2.y)^2)
|
||
end
|
||
|
||
function distance(p1::Point3D, p2::Point3D)
|
||
sqrt((p1.x-p2.x)^2 + (p1.y-p2.y)^2 + (p1.z-p2.z)^2)
|
||
end
|
||
```
|
||
|
||
```{julia}
|
||
distance(p1, Point2D(2200, -300))
|
||
```
|
||
|
||
Wie schon erwähnt, zeigt `methods()` die Methodentabelle einer Funktion an:
|
||
|
||
```{julia}
|
||
methods(distance)
|
||
```
|
||
|
||
Das Macro `@which`, angewendet auf einen vollen Funktionsaufruf mmit konkreter Argumentliste, zeigt an, welche Methode zu diesen konkreten Argumenten ausgewählt wird:
|
||
|
||
```{julia}
|
||
@which sqrt(3.3)
|
||
```
|
||
```{julia}
|
||
z = "Hallo" * '!'
|
||
println(z)
|
||
|
||
@which "Hallo" * '!'
|
||
```
|
||
|
||
Methoden können auch abstrakte Typen als Argument haben:
|
||
|
||
```{julia}
|
||
"""
|
||
Berechnet den Winkel ϕ (in Grad) der Polarkoordinaten (2D) bzw.
|
||
Kugelkoordinaten (3D) eines Punktes
|
||
"""
|
||
function phi_winkel(p::Point)
|
||
atand(p.y, p.x)
|
||
end
|
||
|
||
phi_winkel(p1)
|
||
```
|
||
|
||
:::{.callout-tip collapse="true"}
|
||
Ein in *triple quotes* eingeschlossene Text unmittelbat vor der Funktionsdefinition
|
||
wird automatisch in die Hilfe-Datenbank von Julia integriert:
|
||
|
||
```{julia}
|
||
?phi_winkel
|
||
```
|
||
:::
|
||
|
||
|
||
|
||
Beim *multiple dispatch* wird die Methode angewendet, die unter allen passenden die spezifischste ist. Hier eine Funktion mit mehreren Methoden
|
||
(alle bis auf die letzte in der kurzen [*assignment form*](https://docs.julialang.org/en/v1/manual/functions/#man-functions) geschrieben):
|
||
|
||
```{julia}
|
||
f(x::String, y::Number) = "Args: String + Zahl"
|
||
f(x::String, y::Int64) = "Args: String + Int64"
|
||
f(x::Number, y::Int64) = "Args: Zahl + Int64"
|
||
f(x::Int64, y:: Number) = "Args: Int64 + Zahl"
|
||
f(x::Number) = "Arg: eine Zahl"
|
||
|
||
function f(x::Number, y::Number, z::String)
|
||
return "Arg: 2 x Zahl + String"
|
||
end
|
||
```
|
||
Hier passen die ersten beiden Methoden. Gewählt wird die zweite, da sie spezifischer ist, `Int64 <: Number`.
|
||
```{julia}
|
||
f("Hallo", 42)
|
||
```
|
||
Es kann sein, dass diese Vorschrift zu keinem eindeutigen Ergebnis führt, wenn man seine Methoden schlecht gewählt hat.
|
||
|
||
```{julia}
|
||
f(42, 42)
|
||
```
|
||
|
||
|
||
## Parametrisierte numerische Typen: `Rational` und `Complex`
|
||
|
||
|
||
- Für rationale Zahlen (Brüche) verwendet Julia `//` als Infix-Konstruktor:
|
||
|
||
```{julia}
|
||
@show Rational(23, 17) 4//16 + 1//3;
|
||
```
|
||
|
||
- Die imaginäre Einheit $\sqrt{-1}$ heißt `im`
|
||
|
||
```{julia}
|
||
@show Complex(0.4) 23 + 0.5im/(1-2im);
|
||
```
|
||
|
||
`Rational` und `Complex` bestehen, ähnlich wie unser `Point2D`, aus 2 Feldern: Zähler und Nenner bzw. Real- und Imaginärteil.
|
||
|
||
Der Typ dieser Felder ist allerdings nicht vollständig festgelegt. `Rational` und `Complex` sind _parametrisierte_ Typen.
|
||
|
||
```{julia}
|
||
x = 2//7
|
||
@show typeof(x);
|
||
```
|
||
```{julia}
|
||
y = BigInt(2)//7
|
||
@show typeof(y) y^48;
|
||
```
|
||
|
||
|
||
```{julia}
|
||
x = 1 + 2im
|
||
typeof(x)
|
||
```
|
||
```{julia}
|
||
y = 1.0 + 2.0im
|
||
typeof(y)
|
||
```
|
||
|
||
Die konkreten Typen `Rational{Int64}`, `Rational{BigInt}`,..., `Complex{Int64}`, `Complex{Float64}}`, ... sind Subtypen von `Rational` bzw. `Complex`.
|
||
|
||
|
||
```{julia}
|
||
Rational{BigInt} <: Rational
|
||
```
|
||
|
||
Die Definitionen [sehen etwa so aus](https://github.com/JuliaLang/julia/blob/master/base/rational.jl#L6-L15):
|
||
|
||
```{julia}
|
||
struct MyComplex{T<:Real} <: Number
|
||
re::T
|
||
im::T
|
||
end
|
||
|
||
struct MyRational{T<:Integer} <: Real
|
||
num::T
|
||
den::T
|
||
end
|
||
```
|
||
|
||
Die erste Definition besagt:
|
||
|
||
- `MyComplex` hat zwei Felder `re` und `im`, beide vom gleichen Typ `T`.
|
||
- Dieser Typ `T` muss ein Untertyp von `Real` sein.
|
||
- `MyComplex` und alle seine Varianten wie `MyComplex{Float64}` sind Untertypen von `Number`.
|
||
|
||
und die zweite besagt analog:
|
||
|
||
- `MyRational` hat zwei Felder `num` und `den`, beide vom gleichen Typ `T`.
|
||
- Dieser Typ `T` muss ein Untertyp von `Integer` sein.
|
||
- `MyRational` und seine Varianten sind Untertypen von `Real`.
|
||
|
||
Nun ist ℚ$\subset$ ℝ, oder auf julianisch `Rational <: Real`. Also können die Komponenten einer komplexen Zahl auch rational sein:
|
||
|
||
```{julia}
|
||
z = 3//4 + 5im
|
||
dump(z)
|
||
```
|
||
|
||
|
||
|
||
Diese Strukturen sind ohne das `mutable`-Attribut definiert, also *immutable*:
|
||
|
||
```{julia}
|
||
x = 2.2 + 3.3im
|
||
println("Der Realteil ist: $(x.re)")
|
||
|
||
x.re = 4.4
|
||
```
|
||
Das ist so üblich. Wir betrachten das Objekt `9` vom Typ `Int64` ja auch als unveränderlich.
|
||
Das Folgende geht natürlich trotzdem:
|
||
|
||
```{julia}
|
||
x += 2.2
|
||
```
|
||
Hier wird ein neues Objekt vom Typ `Complex{Float64}` erzeugt und `x` zur Referenz auf dieses neue Objekt gemacht.
|
||
|
||
Die Möglichkeiten des Typsystems verleiten leicht zum Spielen. Hier definieren wir eine `struct`, die wahlweise eine Maschinenzahl oder ein Paar von Ganzzahlen enthalten kann:
|
||
|
||
```{julia}
|
||
struct MyParms{T <: Union{Float64, Tuple{Int64, Int64}}}
|
||
param::T
|
||
end
|
||
|
||
p1 = MyParms(33.3)
|
||
p2 = MyParms( (2, 4) )
|
||
|
||
@show p1.param p2.param;
|
||
```
|
||
|
||
|
||
|
||
|
||
## Typen als Objekte
|
||
|
||
(1) Typen sind ebenfalls Objekte. Sie sind Objekte einer der drei "Meta-Typen"
|
||
|
||
- `Union` (Union-Typen)
|
||
- `UnionAll` (parametrisierte Typen)
|
||
- `DataType` (alle konkreten und sonstige abstrakte Typen)
|
||
|
||
```{julia}
|
||
@show 23779 isa Int64 Int64 isa DataType;
|
||
```
|
||
|
||
```{julia}
|
||
@show 2im isa Complex Complex isa UnionAll;
|
||
```
|
||
|
||
|
||
```{julia}
|
||
@show 2im isa Complex{Int64} Complex{Int64} isa DataType;
|
||
```
|
||
|
||
|
||
Diese 3 konkreten "Meta-Typen" sind übrigens Subtypen des abstrakten "Meta-Typen" `Type`.
|
||
|
||
```{julia}
|
||
subtypes(Type)
|
||
```
|
||
|
||
-----------------
|
||
|
||
(2) Damit können Typen auch einfach Variablen zugewiesen werden:
|
||
|
||
```{julia}
|
||
x3 = Float64
|
||
@show x3(4) x3 <: Real x3==Float64 ;
|
||
```
|
||
|
||
:::{.callout-note collapse="true"}
|
||
|
||
Dies zeigt auch, dass die [Style-Vorgaben in Julia](https://docs.julialang.org/en/v1/manual/style-guide/#Use-naming-conventions-consistent-with-Julia-base/) wie „Typen und Typvariablen starten mit Großbuchstaben, sonstige Variablen und Funktionen werden klein geschrieben.“ nur Konventionen sind und von der Sprache nicht erzwungen werden.
|
||
|
||
Man sollte sie trotzdem einhalten, um den Code lesbar zu halten.
|
||
|
||
:::
|
||
|
||
|
||
Wenn man solche Zuweisungen mit `const` für dauerhaft erklärt, entsteht ein
|
||
*type alias*.
|
||
|
||
|
||
```{julia}
|
||
const MyCmplxF64 = MyComplex{Float64}
|
||
|
||
z = MyComplex(1.1, 2.2)
|
||
typeof(z)
|
||
```
|
||
|
||
--------
|
||
|
||
(3) Typen können Argumente von Funktionen sein.
|
||
|
||
|
||
```{julia}
|
||
function myf(x, S, T)
|
||
if S <: T
|
||
println("$S is subtype of $T")
|
||
end
|
||
return S(x)
|
||
end
|
||
|
||
z = myf(43, UInt16, Real)
|
||
|
||
@show z typeof(z);
|
||
```
|
||
|
||
Wenn man diese Funktion mit Typsignaturen definieren möchte, kann man natürlich
|
||
```julia
|
||
function myf(x, S::Type, T::Type) ... end
|
||
```
|
||
schreiben. Üblicher ist hier die (dazu äquivalente) spezielle Syntax
|
||
```julia
|
||
function myf(x, ::Type{S}, ::Type{T}) where {S,T} ... end
|
||
```
|
||
bei der man in der `where`-Klausel auch noch Einschränkungen an die zulässigen Werte der Typvariablen `S` und `T` stellen kann.
|
||
|
||
Wie definiere ich eine spezielle Methode von `myf`, die nur aufgerufen werden soll, wenn `S` und `T` gleich `Int64` sind? Das ist folgendermaßen möglich:
|
||
|
||
```julia
|
||
function myf(x, ::Type{Int64}, ::Type{Int64}) ... end
|
||
```
|
||
`Type{Int64}` wirkt wie ein "Meta-Typ", dessen einzige Instanz der Typ `Int64` ist.
|
||
|
||
|
||
-----------------
|
||
|
||
(4) Es gibt zahlreiche Operationen mit Typen als Argumenten. Wir haben schon `<:(T1, T2)`, `supertype(T)`, `supertypes(T)`, `subtypes(T)` gesehen. Erwähnt seien noch `typejoin(T1,T2)` (nächster gemeinsamer Vorfahre im Typbaum) und Tests wie `isconcretetype(T)`, `isabstracttype(T)`, `isstructtype(T)`.
|
||
|
||
|
||
|
||
|
||
## Invarianz parametrisierter Typen {#sec-invariance}
|
||
|
||
Kann man in parametrisierten Typen auch nicht-konkrete Typen einsetzen? Gibt es `Complex{AbstractFloat}` oder `Complex{Union{Float32, Int16}}`?
|
||
|
||
Ja, die gibt es; und es sind konkrete Typen, man kann also Objekte von diesem Typ erzeugen.
|
||
|
||
```{julia}
|
||
z5 = Complex{Integer}(2, 0x33)
|
||
dump(z5)
|
||
```
|
||
Das ist eine heterogene Struktur. Jede Komponente hat einen individuellen Typ `T`, für den `T<:Integer` gilt.
|
||
|
||
Nun gilt zwar
|
||
|
||
```{julia}
|
||
Int64 <: Integer
|
||
```
|
||
aber es gilt nicht, dass
|
||
```{julia}
|
||
Complex{Int64} <: Complex{Integer}
|
||
```
|
||
|
||
Diese Typen sind beide konkret. Damit können sie in der Typhierarchie von Julia nicht in einer Sub/Supertype-Relation zueinander stehen. Julias parametrisierte Typen sind [in der Sprache der theoretischen Informatik](https://de.wikipedia.org/wiki/Kovarianz_und_Kontravarianz) **invariant**.
|
||
(Wenn aus `S<:T` folgen würde, dass auch `ParamType{S} <: ParamType{T}` gilt, würde man von **Kovarianz** sprechen.)
|
||
|
||
|
||
|
||
## Generische Funktionen
|
||
|
||
Der übliche (und in vielen Fällen empfohlene!) Programmierstil in Julia ist das Schreiben generischer Funktionen:
|
||
|
||
```{julia}
|
||
function fsinnfrei1(x, y)
|
||
return x * x * y
|
||
end
|
||
```
|
||
Diese Funktion funktioniert sofort mit allen Typen, für die die verwendeten Operationen definiert sind.
|
||
|
||
```{julia}
|
||
fsinnfrei1( Complex(2,3), 10), fsinnfrei1("Hallo", '!')
|
||
```
|
||
|
||
Man kann natürlich Typ-Annotationen benutzen, um die Verwendbarkeit einzuschränken oder um unterschiedliche Methoden für unterschiedliche Typen zu implementieren:
|
||
|
||
```{julia}
|
||
function fsinnfrei2(x::Number, y::AbstractFloat)
|
||
return x * x * y
|
||
end
|
||
|
||
function fsinnfrei2(x::String, y::String)
|
||
println("Sorry, I don't take strings!")
|
||
end
|
||
|
||
|
||
@show fsinnfrei2(18, 2.0) fsinnfrei2(18, 2);
|
||
```
|
||
|
||
:::{.callout-important}
|
||
|
||
**Explizite Typannotationen sind fast immer irrelevent für die Geschwindigkeit des Codes!**
|
||
|
||
Dies ist einer der wichtigsten *selling points* von Julia.
|
||
|
||
Sobald eine Funktion zum ersten Mal mit bestimmten Typen aufgerufen wird, wird eine auf diese Argumenttypen spezialisierte Form der Funktion generiert und compiliert. Damit sind generische Funktionen in der Regel genauso schnell, wie die spezialisierten Funktionen, die man in anderen Sprachen schreibt.
|
||
|
||
Generische Funktionen erlauben die Zusammenarbeit unterschiedlichster Pakete und eine hohe Abstraktion.
|
||
|
||
Ein einfaches Beispiel: Das Paket `Measurements.jl` definiert einen neuen Datentyp `Measurement`, einen Wert mit Fehler, und die Arithmetik dieses Typs. Damit funktionieren generische Funktionen automatisch:
|
||
|
||
```{julia}
|
||
#| echo: false
|
||
#| output: false
|
||
|
||
#=
|
||
-Measurements.jl/show.jl adds a method
|
||
Base.show(io::IO, ::MIME"text/latex", measure::Measurement)
|
||
- IJulia sends out a text/latex-cell in addition to the text/plain-cell
|
||
|
||
"outputs": [
|
||
{
|
||
"data": {
|
||
"text/latex": [
|
||
"$2590.0 \\pm 52.0$"
|
||
],
|
||
"text/plain": [
|
||
"2590.0 ± 52.0"
|
||
]
|
||
},
|
||
whenever it finds this method, see
|
||
https://github.com/JuliaLang/IJulia.jl/commit/7311e517194ddba07af64952b0f9413401213050
|
||
|
||
- Quarto takes this latex-cell in its qmd -> ipynb->exec->ipynb -> md pipeline, generating a :::{=tex} -div
|
||
|
||
- so we delete the method
|
||
|
||
=#
|
||
using Measurements
|
||
zz= @which Base.show(stdout, MIME"text/latex"(), 3±2)
|
||
Base.delete_method(zz)
|
||
```
|
||
|
||
```{julia}
|
||
using Measurements
|
||
|
||
x = 33.56±0.3
|
||
y = 2.3±0.02
|
||
|
||
fsinnfrei1(x, y)
|
||
```
|
||
:::
|
||
|
||
## Typ-Parameter in Funktionsdefinitionen: die `where`-Klausel
|
||
|
||
Wir wollen eine Funktion schreiben, die für **alle komplexen Integer** (und nur diese) funktioniert, z.B. eine [in ℤ[i] mögliche Primfaktorzerlegung](https://de.wikipedia.org/wiki/Gau%C3%9Fsche_Zahl). Die Definition
|
||
|
||
```{julia}
|
||
#| eval: false
|
||
function isprime(x::Complex{Integer}) ... end
|
||
```
|
||
|
||
liefert nun nicht das Gewünschte, wie wir in @sec-invariance gesehen haben. Die Funktion würde für ein Argument vom Typ `Complex{Int64}` nicht funktionieren, da letzteres kein Subtyp von `Complex{Integer}` ist.
|
||
|
||
Wir müssen eine Typ-Variable einführen. Dazu dient die `where`-Klausel.
|
||
|
||
```{julia}
|
||
#| eval: false
|
||
function isprime(x::Complex{T}) where {T<:Integer}
|
||
...
|
||
end
|
||
```
|
||
|
||
Das ist zu lesen als:
|
||
|
||
> „Das Argument x soll von einem der Typen `Complex{T}` sein, wobei die Typvariable `T` irgendein Untertyp von `Integer` sein kann.“
|
||
|
||
Noch ein Beispiel:
|
||
```{julia}
|
||
#| eval: false
|
||
function kgV(x::Complex{T}, y::Complex{S}) where {T<:Integer, S<:Integer}
|
||
...
|
||
end
|
||
```
|
||
|
||
> Die Argumente x und y können verschiedene Typen haben und beide müssen Subtypen von `Integer` sein.
|
||
|
||
|
||
Wenn es nur eine `where`-Klausel wie im vorletzten Beispiel gibt, kann man die geschweiften Klammern weglassen und
|
||
|
||
```{julia}
|
||
#| eval: false
|
||
function isprime(x::Complex{T}) where T<:Integer
|
||
...
|
||
end
|
||
```
|
||
schreiben. Das lässt sich noch weiter kürzen zu
|
||
```{julia}
|
||
#| eval: false
|
||
function isprime(x::Complex{<:Integer})
|
||
...
|
||
end
|
||
```
|
||
|
||
Diese verschiedenen Varianten können verwirrend sein, aber das ist nur Syntax.
|
||
|
||
```{julia}
|
||
C1 = Complex{T} where {T<:Integer}
|
||
C2 = Complex{T} where T<:Integer
|
||
C3 = Complex{<:Integer}
|
||
|
||
C1 == C2 == C3
|
||
```
|
||
|
||
Kurze Syntax für einfache Fälle, ausführliche Syntax für komplexe Varianten.
|
||
|
||
Als letztes sein bemerkt, dass `where T` die Kurzform von `where T<:Any` ist, also eine völlig unbeschränkte Typvariable einführt. Damit ist sowas möglich:
|
||
|
||
```{julia}
|
||
function fgl(x::T, y::T) where T
|
||
println("Glückwunsch! x und y sind vom gleichen Typ!")
|
||
end
|
||
```
|
||
Diese Methode erfordert, dass die Argumente genau den gleichen, aber ansonsten beliebigen Typ haben.
|
||
|
||
```{julia}
|
||
fgl(33, 44)
|
||
```
|
||
|
||
```{julia}
|
||
fgl(33, 44.0)
|
||
```
|
||
|
||
|
||
|