{
"cells": [
{
"cell_type": "markdown",
"metadata": {},
"source": [
"# Functions, Types & Dispatch\n",
"\n",
"In this chapter we will review the two key concepts, which make Julia stand out,\n",
"namely multiple dispatch and its type system."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"## Defining functions\n",
"\n",
"Defining functions follows a rather intuitive syntax. The value obtained by evaluating the last expression of a `function` block will be automatically returned:"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"function mymult(x, y)\n",
" x * y \n",
"end"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"For one-line functions one may also use a convenient short-hand:"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"mysquare(x) = mymult(x, x)"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"Both such functions are fully generic in the argument types"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"@show mysquare(2) # Use integer arithmetic\n",
"@show mymult(-1, 3. + 2im) # Use complex arithmetic\n",
"@show mysquare(\" abc \"); # Use string concatenation"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"Notice, that for each type combination a separate piece of code will be compiled even though we only *defined* the functionality a single time. This compilation takes place on first use of a particular tuple of types."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"Functions by themselves are objects"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"mymult"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"and may be passed around to other functions, for example:"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"\"\"\"The fold function, applying f from the left and accumulating the results\"\"\"\n",
"function myfold(f, x, y, z)\n",
" f(f(x, y), z)\n",
"end\n",
"myfold(mymult, \"Hello\", \" Julia \", \"World\")"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"Julia makes a distinction between **functions** and **methods**. Methods are concrete implementations in form of a list of Julia expressions to be executed, when the function name is used in the code. Multiple methods may be defined for the same function name. They differ in the number of arguments or in the supported argument types (more on this in a second). The resulting function object represents a mapping from the function name (e.g. `myfold`) to the respective methods.\n",
"Its job is to mediate between the different methods,\n",
"namely to transparently select one method for each call of the function in other Julia code.\n",
"This **dispatch** is done based on the passed arguments and their types, such that the best-fitting method is selected.\n",
"\n",
"For our `myfold` example, one could easily imagine a few more method implementations, for example "
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"myfold(f, x) = x\n",
"myfold(f, x, y) = f(x, y)"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"So now `myfold` works transparently with 1, 2 or 3 arguments:"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"@show myfold(mymult, 2., 3.)\n",
"@show myfold(+, 1)\n",
"@show myfold(==, false, false, true)"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"As an aside we note, that making `myfold` work with a variable number of arguments is possible:"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"myfold(f, x, rest...) = myfold(f, f(x, myfold(rest...)))"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"If you want to know more on this, the `...` is known as an ellipsis in the function argument list and as the splatting operator in the call towards the end of the line."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"##### More details\n",
"- https://docs.julialang.org/en/v1/manual/methods/"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"## Propagating a particle in time\n",
"\n",
"A small project, which will tackle during the course is to develop a simple code for\n",
"simulating the classical dynamics of interacting particles.\n",
"\n",
"Assume we are given a potential $V(x)$ for a single\n",
"particle with unit mass at position $x$. We want to propagate the particle in time.\n",
"That's integrating the famous Newton's equation of motion\n",
"$$ -\\frac{dV}{dx} = \\frac{d^2x}{dt^2}$$\n",
"in time. Defining the accelleration map\n",
"$$ A_V = -\\frac{dV}{dx}$$\n",
"this may be written equivalently:\n",
"$$\\left\\{\\begin{array}{l}\n",
"\\frac{dv}{dt} = A_V \\\\\n",
"\\frac{dx}{dt} = v\n",
"\\end{array}\\right. $$"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"At first we will just apply forward-Euler: We discrete in time using the interval\n",
"$\\Delta t$, which leads to sequences $t^{(n)} = n \\Delta t + t^{(0)}$ and similarly $v^{(n)}$, $x^{(n)}$, etc:\n",
"$$\\left\\{\\begin{array}{l}\n",
"v^{(n+1)} = v^{(n)} + A_V(x^{(n)}) \\Delta t\\\\\n",
"x^{(n+1)} = x^{(n)} + v^{(n)} \\Delta t\\\\\n",
"\\end{array}\\right. .$$\n",
"This is transformed to a Julia function in a single line:"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"euler(A, Δt, xn, vn) = xn + vn * Δt, vn + A(xn) * Δt"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"where `A` is a function object to be passed to `euler`, for example:"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"A(x) = -x\n",
"euler(A, 0.1, 0, 1)"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"### Exercise\n",
"- Take timesteps of $\\Delta t = 0.1$ and start at $x_n = 0$ and $v_n = 1$. Propagate the dynamics for 5 steps in the harmonic potential $V = x^2$.\n",
"- Now do the same thing using the confining potential:\n",
" $$ V_\\alpha(x) = \\left\\{ \\begin{array}{ll} (|x| - 1)^\\alpha & |x| > 1 \\\\ 0 & \\text{else}\\end{array}\\right.$$\n",
" for $\\alpha = 4$."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"## Abstract and concrete types"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"Before we discuss multiple dispatch of functions and dispatch by types, we briefly review Julia's type system. Types in Julia fall into two categories: **Abstract** and **concrete**. Abstract types such as `Integer` or `Number` are supertypes of a bunch of other types, for example:"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"Int32 <: Integer # Read Int32 is-a Integer"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"UInt16 <: Integer"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"Float32 <: Integer"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"Float32 <: Number"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"Integer <: Number"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"# by transitivity:\n",
"@show Int32 <: Number\n",
"@show UInt16 <: Number\n",
"@show Number <: Number;"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"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 I was before looking into Julia) this seems restrictive at first, but it takes away a lot of unnecessary complexity from the type hierachy. In Julia the structure of a library or a problem\n",
"is in many cases not converted into explict type hierachies,\n",
"as it would for OOP languages like Python or C++.\n",
"Instead it builds up implicitly from conventions which are associated with abstract or concrete types.\n",
"\n",
"For example, if you derive off the abstract type `AbstractMatrix` you are expected to implement a certain set of functions (e.g. a way to obtain an element for a given index, something which returns the size of the matrix, etc.). Otherwise not all of the standard library and other linear algebra packages will work. The difference to a hard enforcement of interfaces like in C++ or Java is, however, that *some things* will still work. This has disadvantages as your code could break in the future, but it is extremely useful for rapidly trying something out. Afterwards one should of course still implement the full expected interface of an `AbstractMatrix` consulting the Julia documentation to ensure the code is fully compatible."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"# Dynamical typing and type deduction"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"In programming language theory type systems traditionally fall in two categories.\n",
"In **dynamically typed** languages the type of\n",
"a value or expression is inferred only at runtime,\n",
"which usually allows for more flexible code. Examples are Python or MATLAB.\n",
"In contrast, so-called **statically-typed** languages (think FORTRAN or C++),\n",
"require types to be already known before runtime when the program is compiled.\n",
"This allows both to check more thoroughly for errors (which can manifest in mismatched types)\n",
"and it usually brings a gain in performance because more things about the memory layout of the program is known\n",
"at compile time. As a result aspects such as vectorisation, contiguous alignment of data,\n",
"preallocation of memory can be leveraged more easily.\n",
"\n",
"Julia is kind of both. Strictly speaking it is dynamically typed. E.g. the type of variables can change type at any point:"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {
"scrolled": true
},
"outputs": [],
"source": [
"a = 4\n",
"println(typeof(a))\n",
"a = \"bla\"\n",
"println(typeof(a))"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {
"scrolled": true
},
"outputs": [],
"source": [
"a = 4\n",
"println(typeof(a))\n",
"a = \"bla\"\n",
"println(typeof(a))"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"Note, however, that the type of a *value* cannot change in Julia!1.\n",
"\n",
"Still, Julia's strong emphasis on types are one of the reasons for its performance.\n",
"Unlike in statically typed languages, however, **type deduction in Julia** happens at runtime, right before JIT-compiling a function: The more narrowly the types for a particular piece of code can be deduced, the better the emitted machine code can be optimised. One can influence this using explicit type annotations in function arguments and intermediate expressions. Due to the to the excellent type inference capabilities of Julia, this is in general not needed, however.\n",
"\n",
"This might sound a bit unusal at first, but the result is,\n",
"that it takes almost no effort to write generic code: Just leave off all the type annotations. Notice, that this only means that the code has no types. At runtime types are still inferred as much as possible, such that aspects like vectorisation, contiguous alignment of data, preallocation of memory *can* be taken into account by the Julia compiler."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"To make the Julia compiler appear less like a mysterious black box, let us check up on some of it's inner workings. This is fortunately quite simple, since Julia is equipped with quite some helpful tools to provide insight into the code generation step. One of these is the macro `@code_typed`:"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"@code_typed euler(x -> -2x, 0.1, 0.0, 1.0)"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"@code_typed euler(x -> -2x, 0.1f0, 0.0f0, 1.0f0) # Why not use single precision?"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"@code_typed myfold(mymult, \"Hello\", \" Julia \", \" World!\")"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"It shows exactly the types which are inferred during the JIT compilation procedure. In this sense Julia functions resemble very much the behaviour of fully templated code in C++, albeit the syntax is a lot more condensed. Additionally compile-on-first-use implies that methods are only ever compiled for those combinations of types, which are actually used in the code. Again a difference to C++, where heavily templated code often leads to a combinatorial growth in binary size and compile time."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"Three more facts about Julia types:\n",
"- In Julia all types are the same. For example, there is no difference between `Int32` and `String`, even though the first has a direct mapping to low-level instructions in the CPU and the latter has not (contrast this with e.g. C++).\n",
"- The `Nothing` type with the single instance `nothing` is the Julia equivalent to `void` in C++ or `None` in Python. It often represents that a function does not return anything or that a variable has not been initialised.\n",
"- `Any` is the root of the type tree: Any type in Julia is a subtype of `Any`."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"### Exercise\n",
"Which of the following type are subtypes of another?\n",
"Try to guess first and then verify by using the operator `<:`.\n",
"\n",
"```julia\n",
"Float64 AbstractFloat Integer\n",
"Number AbstractArray Complex\n",
"Real Any Nothing\n",
"```"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"##### For more details\n",
"https://docs.julialang.org/en/v1/manual/types/"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"## Method dispatch by type"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"Let us return back to the `mymult` function:"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"mymult(x, y) = x * y"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"We were able to safely use this functions with a number of type combinations, but some things do not yet work:"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"mymult(2, \" abc\")"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"Let's say we wanted to concatenate the string `str` $n$ times on multiplication with an integer $n$. In Julia this functionality is already implemented by the exponentiation operator:"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"\"abc\"^4"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"So our task is to implement `mymult(\"abc\", 4)` and `mymult(4, \"abc\")` to behave the same way. We define two special methods:"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"mymult(str::AbstractString, n::Integer) = str^n\n",
"mymult(n::Integer, str::AbstractString) = mymult(str, n)"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"In both of these, the syntax `str::AbstractString` and `n::Integer` means that the respective method is only\n",
"considered during dispatch if the argument `str` is of type `AbstractString` or one of its concrete subtypes and similarly `n` is an `Integer` (or subtype). Since Julia always dispatches to the most specific method in case multiple methods match, this is all we need to do:"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"@show mymult(2, \" abc\")\n",
"@show mymult(\"def \", UInt16(3));"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"Notice, that the fully generic\n",
"```julia\n",
"mymult(x, y) = x * y\n",
"```\n",
"is actually an abbreviation for\n",
"```julia\n",
"mymult(x::Any, y::Any) = x * y\n",
"```"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"Let us recap. Roughly speaking what we did to implement `mymult` was:\n",
"- The most generic method was used to establish the basic functionality, which works well for almost all cases.\n",
"- Only a few specialised methods were needed additionally to capture an extra class of special cases on top.\n",
"Arguably this was a very simple example, still this observation is a common paradigm in Julia.\n",
"It is both used to extend existing functions by extra methods for custom types\n",
"as well as to optimise when more performant implementations can be suggested for special cases.\n",
"\n",
"For example, consider the `det`-function for computing the determinant of a matrix,\n",
"which is implemented exactly in this spirit.\n",
"One of its methods is kept as generic as possible, that is assuming nothing about the matrix and just computing the determinant by visiting all rows and columns.\n",
"The result is a slow fallback method, which always works.\n",
"Afterwards a few sensible specialisations for example for `UpperTriangular` or `Tridiagonal`\n",
"matrices are implemented on top.\n",
"These exploit the additional structure, resulting in much reduced cost.\n",
"\n",
"Let's assume now we program an algorithm, which involves a determinant, e.g. the simple normalisation function\n",
"```\n",
"normalise(A) = A / det(A)\n",
"```\n",
"(where of course we assume `A` to be nonsingular). We note:\n",
"- As a user, if I know the structure of my matrix is special, I mark it e.g. with the `Tridiagonal` type. When running `normalise` on it, the `det`-method specialised for `Tridiagonal` will be used, so that the best possible performance results.\n",
"- As a user, if I do not know the structure of the matrix, I leave it general. Then the slow `det` will still give me a sensible result.\n",
"- As a programmer, writing the `normalise` algorithm I do not need to know what kind of matrix my users will pass me, since the dispatch of `det` will assure the best thing happens. Most notably even if I have standard matrices in mind when writing the code, my `normalise` will still work if a passed matrix `A` is non-standard, because the fallback `det` will do the job. \n",
"- As a programmer, writing a custom matrix `A` which adheres to all conventions of the `AbstractMatrix` interface, I instantly have a working `normalise` function even if I could be more clever about it. This way I can rapidly prototype my fancy new matrix type and only later implement the `det` function once I see it's necessary to achieve better performance. Most importantly, however, I can specialise `det` (from `Base`) in my code where I define `A` and *still* the `normalise` function (which could be third-party code) will speed up (more on this below)."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"Notice, that methods can also be parametrised in the types over multiple arguments, for example:"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {
"scrolled": true
},
"outputs": [],
"source": [
"equal_type(x::T, y::T) where {T} = true\n",
"equal_type(x, y) = false"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"equal_type(1, 1.2)"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"equal_type(\"abc\", \"ef\")"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"equal_type_and_integer(x::T, y::T) where {T <: Integer} = true\n",
"equal_type_and_integer(x, y) where {T <: Integer} = false"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"@show equal_type_and_integer(1, 2)\n",
"@show equal_type_and_integer(\"abc\", \"ef\");"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"Without a doubt designing the methods' type annotations needs some practice. For more details and plenty of more options to influence type-specific dispatch, see the [Julia documentation on methods](https://docs.julialang.org/en/v1/manual/methods/)."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"### Exercise\n",
"\n",
"Consider the functions"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {
"scrolled": true
},
"outputs": [],
"source": [
"characterise(x::String, y::Nothing) = \"\"\n",
"characterise(x::Nothing, y::Complex) = \"Only one of us is complex\"\n",
"characterise(x::Number, ::Nothing) = \"I'm a number, Jack, and I'm ok\"\n",
"characterise(x::AbstractFloat, y::Integer) = \"Pretty abstract\"\n",
"characterise(x::BigFloat, y) = \"I'm big\"\n",
"characterise(x, y::Union{BigFloat, BigInt}) = \"We're big\"\n",
"characterise(x::Float32, y::Union{Int32, Int64}) = \"pretty wide\""
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"Where `Union{A, B}` means that the type may either be `A` or `B`."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"For each of the following calls, try to determine which method will be called (if any) and verify by running the code:\n",
"- `characterise(0.1, UInt32(3))`\n",
"- `characterise(0.1, 3)`\n",
"- `characterise(nothing, im)`\n",
"- `characterise(nothing, im)`\n",
"- `characterise(Float32(0.1), UInt32(3))`\n",
"- `characterise(Float32(0.1), 3)`"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"# For example:\n",
"characterise(\"abc\", 1.2)"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"## Standard functions and operators\n",
"\n",
"Plenty of standard functions are already defined in Julia `Base`. This includes:\n",
"- All operators `+`, `*`, `-`, `≈` (isapprox)\n",
"- Standard functions such as `exp`, `sin`, `cos`, `abs`, ...\n",
"- `inv` to compute the multiplicative inverse (e.g. Matrix inverse)\n",
"- `min`, `max` and `minmax`\n",
"\n",
"But also a few special cases worth mentioning:\n",
"- `cis` for $\\exp(i x)$\n",
"- `sinpi` and `cospi` for computing $\\sin(\\pi x)$ and $\\cos(\\pi x)$ more accurately\n",
"- `cbrt` computes the cube root."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"##### More details\n",
"- https://docs.julialang.org/en/v1/base/math/"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"## Multiple dispatch"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"Same as custom functions, additional methods for functions from other packages can also be defined.\n",
"This extends to functions from `Base` Julia. So instead of defining our custom `mymult` function,\n",
"we could have equally well overloaded the `*` operator from `Base` for integers and strings:"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"import Base: *\n",
"*(str::AbstractString, n::Integer) = str^n\n",
"*(n::Integer, str::AbstractString) = mymult(str, n)"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"@show 4 * \"abc\""
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"which is actually equivalent to"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": [
"*(4, \"abc\")"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"For evaluating the latter expression, Julia needs to determine which method of the function `Base.*` to execute.\n",
"For this *both* argument types are taken into account and not just the first or the second. This is **multiple dispatch**, namely the fact that for dispatching to a method definition the type of *all* arguments matters."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"This probably does not sound so impressive, but let us discuss this a little further, staying with the example of multiplication. We consider implementing a binary operator `*(n::Float64, str::SparseMatrixCSC)`, which multiplies a number with a sparse matrix in compressed-column storage format:\n",
"- In many languages such as Python, implementing such a binary operator translates to a special operator function. In the Python case this is `__mul__`, which needs to be implemented for the LHS type, i.e. `Float64`. In other words which method to call for `*` is decided solely by considering the type of the *first* argument, hence the name *single dispatch*.\n",
"- This is not always the most clever thing to do. In our case one could well argue that `SparseMatrixCSC` should be the place where the operator should be implemented, because the net effect will be to scale this matrix. Amongst other reasons this is why Python rolled out a second set of functions, called `__rmul__`, which dispatch on the *second* argument. Problem solved, right?\n",
"- Yes, for `*(n::Float64, str::SparseMatrixCSC)` we are good, but a new conceptional problem results. Let's say I want to use a custom floating point format `Double64` in my code and specifically implement `*(n::Double64, str::SparseMatrixCSC)`. Both `Double64` and `SparseMatrixCSC` are from third-party packages, which know nothing from another. In Python I have roughly three options:\n",
" 1. Implement `__rmul__` in `SparseMatrixCSC`. That's bad because it adds the dependency on `Double64` inside `SparseMatrixCSC`.\n",
" 2. Implement `__mul__` in `Double64` ... same issue in reverse.\n",
" 3. Derive off e.g. `SparseMatrixCSC` in my code and implement there. Works, but I have now a part of my library that is closely coupled to the API of `SparseMatrixCSC`. If anything happens in the `SparseMatrixCSC` I have to follow along or my code breaks.\n",
"- In C++ the very problem of implementing mulitplication is not so prominent, because `operator*` can also be a free function. For other binary operations (like type conversion) the problem is, however, exactly the same: As soon as two non-standard third-party types are involved and my code needs to connect them, I have to make one more special than the other.\n",
"\n",
"The aforementioned problem is known as the *binary method problem* and is elegantly solved by multiple dispatch, because both arguments are treated on the same footing. So in Julia I just need to do\n",
"```\n",
"import Base: *\n",
"*(n::Double64, str::SparseMatrixCSC) = ...\n",
"```\n",
"in my code, without changing any `Double64` or `SparseMatrixCSC` code, because from Julia's point of view my method will now be the most specific for the type tuple `(Double64, SparseMatrixCSC)`."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"##### More details\n",
"- PhD Thesis from Jeff Bezanson\n",
"- https://www.youtube.com/watch?v=kc9HwsxE1OY\n",
"- https://docs.julialang.org/en/v1/manual/methods/"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"## Footnotes\n",
"1I ignore some dirty tricks for performance optimisation here, where one can reinterpret a bit of memory as some other type ..."
]
}
],
"metadata": {
"kernelspec": {
"display_name": "Julia 1.3.0",
"language": "julia",
"name": "julia-1.3"
},
"language_info": {
"file_extension": ".jl",
"mimetype": "application/julia",
"name": "julia",
"version": "1.3.0"
}
},
"nbformat": 4,
"nbformat_minor": 2
}