more_julia/generic_programming.ipynb

{
 "cells": [
  {
   "cell_type": "markdown",
   "id": "84e9ebb5",
   "metadata": {},
   "source": [
    "\n",
    "<a id='generic-programming'></a>"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "7a329111",
   "metadata": {},
   "source": [
    "# Generic Programming"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "39ffa3a6",
   "metadata": {},
   "source": [
    "## Contents\n",
    "\n",
    "- [Generic Programming](#Generic-Programming)  \n",
    "  - [Overview](#Overview)  \n",
    "  - [Exploring Type Trees](#Exploring-Type-Trees)  \n",
    "  - [Distributions](#Distributions)  \n",
    "  - [Numbers and Algebraic Structures](#Numbers-and-Algebraic-Structures)  \n",
    "  - [Reals and Algebraic Structures](#Reals-and-Algebraic-Structures)  \n",
    "  - [Functions, and Function-Like Types](#Functions,-and-Function-Like-Types)  \n",
    "  - [Limitations of Dispatching on Abstract Types](#Limitations-of-Dispatching-on-Abstract-Types)  \n",
    "  - [Exercises](#Exercises)  "
   ]
  },
  {
   "cell_type": "markdown",
   "id": "352bb1db",
   "metadata": {},
   "source": [
    "> I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work. – Alexander Stepanov"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "e42fedd0",
   "metadata": {},
   "source": [
    "## Overview\n",
    "\n",
    "In this lecture we delve more deeply into the structure of Julia, and in particular into\n",
    "\n",
    "- abstract and concrete types  \n",
    "- the type tree  \n",
    "- designing and using generic interfaces  \n",
    "- the role of generic interfaces in Julia performance  \n",
    "\n",
    "\n",
    "Understanding them will help you\n",
    "\n",
    "- form a “mental model” of the Julia language  \n",
    "- design code that matches the “white-board” mathematics  \n",
    "- create code that can use (and be used by) a variety of other packages  \n",
    "- write “well organized” Julia code that’s easy to read, modify, maintain and debug  \n",
    "- improve the speed at which your code runs  \n",
    "\n",
    "\n",
    "(Special thank you to Jeffrey Sarnoff)"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "f6352796",
   "metadata": {},
   "source": [
    "### Generic Programming is an Attitude\n",
    "\n",
    "From *Mathematics to Generic Programming* [[SR14](https://julia.quantecon.org/../zreferences.html#id3)]\n",
    "\n",
    "> Generic programming is an approach to programming that focuses on designing algorithms and data structures so that they work in the most general setting without loss of efficiency… Generic programming is more of an *attitude* toward programming than a particular set of tools.\n",
    "\n",
    "\n",
    "In that sense, it is important to think of generic programming as an interactive approach to uncover generality without compromising performance rather than as a set of rules.\n",
    "\n",
    "As we will see, the core approach is to treat data structures and algorithms as loosely coupled, and is in direct contrast to the [is-a](https://en.wikipedia.org/wiki/Is-a)  approach of object-oriented programming.\n",
    "\n",
    "This lecture has the dual role of giving an introduction into the design of generic algorithms and describing how Julia helps make that possible."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "ecac5835",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "using LinearAlgebra, Statistics\n",
    "using Distributions, Plots, QuadGK, Polynomials, Interpolations"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "b8bc784b",
   "metadata": {},
   "source": [
    "## Exploring Type Trees\n",
    "\n",
    "The connection between data structures and the algorithms which operate on them is handled by the type system.\n",
    "\n",
    "Concrete types (i.e., `Float64` or `Array{Float64, 2}`) are the data structures we apply an algorithm to, and the abstract types (e.g. the corresponding `Number` and `AbstractArray`) provide the mapping between a set of related data structures and algorithms."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "92da9cb3",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "using Distributions\n",
    "x = 1\n",
    "y = Normal()\n",
    "z = \"foo\"\n",
    "@show x, y, z\n",
    "@show typeof(x), typeof(y), typeof(z)\n",
    "@show supertype(typeof(x))\n",
    "\n",
    "# pipe operator, |>, is is equivalent\n",
    "@show typeof(x) |> supertype\n",
    "@show supertype(typeof(y))\n",
    "@show typeof(z) |> supertype\n",
    "@show typeof(x) <: Any;"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "9dc43522",
   "metadata": {},
   "source": [
    "Beyond the `typeof` and `supertype` functions, a few other useful tools for analyzing the tree of types are discussed in the [introduction to types lecture](https://julia.quantecon.org/../getting_started_julia/introduction_to_types.html)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "d173e622",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "using Base: show_supertypes # import the function from the `Base` package\n",
    "\n",
    "show_supertypes(Int64)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "da26f3bc",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "subtypes(Integer)"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "d169cde9",
   "metadata": {},
   "source": [
    "Using the `subtypes` function, we can write an algorithm to traverse the type tree below any time `t` – with the confidence that all types support `subtypes`"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "9c4e0e13",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "#  from https://github.com/JuliaLang/julia/issues/24741\n",
    "function subtypetree(t, level = 1, indent = 4)\n",
    "    if level == 1\n",
    "        println(t)\n",
    "    end\n",
    "    for s in subtypes(t)\n",
    "        println(join(fill(\" \", level * indent)) * string(s))  # print type\n",
    "        subtypetree(s, level + 1, indent)  # recursively print the next type, indenting\n",
    "    end\n",
    "end"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "14b877be",
   "metadata": {},
   "source": [
    "Applying this to `Number`, we see the tree of types currently loaded"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "d82cc46f",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "subtypetree(Number) # warning: do not use this function on ``Any``!"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "50bfa435",
   "metadata": {},
   "source": [
    "For the most part, all of the “leaves” will be concrete types."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "ae785db0",
   "metadata": {},
   "source": [
    "### Any\n",
    "\n",
    "At the root of all types is `Any`\n",
    "\n",
    "There are a few functions that work in the “most generalized” context: usable with anything that you can construct or access from other packages.\n",
    "\n",
    "We have already called `typeof`, `show` and `supertype` – which will apply to a custom `struct` type since `MyType <: Any`"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "14d2a06e",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "# custom type\n",
    "struct MyType\n",
    "    a::Float64\n",
    "end\n",
    "\n",
    "myval = MyType(2.0)\n",
    "@show myval\n",
    "@show typeof(myval)\n",
    "@show supertype(typeof(myval))\n",
    "@show typeof(myval) <: Any;"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "5c93ca9c",
   "metadata": {},
   "source": [
    "Here we see another example of generic programming: every type `<: Any` supports the `@show` macro, which in turn, relies on the `show` function.\n",
    "\n",
    "The `@show` macro (1) prints the expression as a string; (2) evaluates the expression; and (3) calls the `show` function on the returned values.\n",
    "\n",
    "To see this with built-in types"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "f2a3e04e",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "x = [1, 2]\n",
    "show(x)"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "8643e78d",
   "metadata": {},
   "source": [
    "The `Any` type is useful, because it provides a fall-back implementation for a variety of functions.\n",
    "\n",
    "Hence, calling `show` on our custom type dispatches to the fallback function"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "e0d9cc37",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "myval = MyType(2.0)\n",
    "show(myval)"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "7266c8b5",
   "metadata": {},
   "source": [
    "The default fallback implementation used by Julia would be roughly equivalent to"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "2c35ca76",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "function show(io::IO, x)\n",
    "    str = string(x)\n",
    "    print(io, str)\n",
    "end"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "cacba419",
   "metadata": {},
   "source": [
    "To implement a specialized implementation of the `show` function for our type, rather than using this fallback"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "dd0ce126",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "import Base.show  # to extend an existing function\n",
    "\n",
    "function show(io::IO, x::MyType)\n",
    "    str = \"(MyType.a = $(x.a))\"  # custom display\n",
    "    print(io, str)\n",
    "end\n",
    "show(myval)  # it creates an IO value first and then calls the above show"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "b2000eb2",
   "metadata": {},
   "source": [
    "At that point, we can use the `@show` macro, which in turn calls `show`"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "6f111a37",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "@show myval;"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "89f0ee0c",
   "metadata": {},
   "source": [
    "Here we see another example of generic programming: any type with a `show` function works with `@show`.\n",
    "\n",
    "Layering of functions (e.g. `@show` calling `show`) with a “fallback” implementation makes it possible for new types to be designed and only specialized where necessary."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "281de99e",
   "metadata": {},
   "source": [
    "### Unlearning Object Oriented (OO) Programming (Advanced)\n",
    "\n",
    "See [Types](https://docs.julialang.org/en/v1/manual/types/#man-types-1) for more on OO vs. generic types.\n",
    "\n",
    "If you have never used programming languages such as C++, Java, and Python, then the type hierarchies above may seem unfamiliar and abstract.\n",
    "\n",
    "In that case, keep an open mind that this discussion of abstract concepts will have practical consequences, but there is no need to read this section.\n",
    "\n",
    "Otherwise, if you have used object-oriented programming (OOP) in those languages, then some of the concepts in these lecture notes will appear familiar.\n",
    "\n",
    "**Don’t be fooled!**\n",
    "\n",
    "The superficial similarity can lead to misuse: types are *not* classes with poor encapsulation, and methods are *not* the equivalent to member functions with the order of arguments swapped.\n",
    "\n",
    "In particular, previous OO knowledge often leads people to write Julia code such as"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "39cded16",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "# BAD! Replicating an OO design in Julia\n",
    "mutable struct MyModel\n",
    "    a::Float64\n",
    "    b::Float64\n",
    "    algorithmcalculation::Float64\n",
    "\n",
    "    MyModel(a, b) = new(a, b, 0.0) # an inner constructor\n",
    "end\n",
    "\n",
    "function myalgorithm!(m::MyModel, x)\n",
    "    m.algorithmcalculation = m.a + m.b + x # some algorithm\n",
    "end\n",
    "\n",
    "function set_a!(m::MyModel, a)\n",
    "    m.a = a\n",
    "end\n",
    "\n",
    "m = MyModel(2.0, 3.0)\n",
    "x = 0.1\n",
    "set_a!(m, 4.1)\n",
    "myalgorithm!(m, x)\n",
    "@show m.algorithmcalculation;"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "d2376a6a",
   "metadata": {},
   "source": [
    "You may think to yourself that the above code is similar to OO, except that you\n",
    "\n",
    "- reverse the first argument, i.e., `myalgorithm!(m, x)` instead of the object-oriented `m.myalgorithm!(x)`  \n",
    "- cannot control encapsulation of the fields `a`, `b`, but you can add getter/setters like `set_a`  \n",
    "- do not have concrete inheritance  \n",
    "\n",
    "\n",
    "While this sort of programming is possible, it is (verbosely) missing the point of Julia and the power of generic programming.\n",
    "\n",
    "When programming in Julia\n",
    "\n",
    "- there is no [encapsulation](https://en.wikipedia.org/wiki/Encapsulation_%28computer_programming%29) and most custom types you create will be immutable.  \n",
    "- [Polymorphism](https://en.wikipedia.org/wiki/Polymorphism_%28computer_science%29) is achieved without anything resembling OOP [inheritance](https://en.wikipedia.org/wiki/Inheritance_%28object-oriented_programming%29).  \n",
    "- [Abstraction](https://en.wikipedia.org/wiki/Abstraction_%28computer_science%29#Abstraction_in_object_oriented_programming) is implemented by keeping the data and algorithms that operate on them as orthogonal as possible – in direct contrast to OOP’s association of algorithms and methods directly with a type in a tree.  \n",
    "- The supertypes in Julia are simply used for selecting which specialized algorithm to use (i.e., part of generic polymorphism) and have nothing to do with OO inheritance.  \n",
    "- The looseness that accompanies keeping algorithms and data structures as orthogonal as possible makes it easier to discover commonality in the design.  "
   ]
  },
  {
   "cell_type": "markdown",
   "id": "a7a57b99",
   "metadata": {},
   "source": [
    "#### Iterative Design of Abstractions\n",
    "\n",
    "As its essence, the design of generic software is that you will start with creating algorithms which are largely orthogonal to concrete types.\n",
    "\n",
    "In the process, you will discover commonality which leads to abstract types with informally defined functions operating on them.\n",
    "\n",
    "Given the abstract types and commonality, you then refine the algorithms as they are more limited or more general than you initially thought.\n",
    "\n",
    "This approach is in direct contrast to object-oriented design and analysis ([OOAD](https://en.wikipedia.org/wiki/Object-oriented_analysis_and_design)).\n",
    "\n",
    "With that, where you specify a taxonomies of types, add operations to those types, and then move down to various levels of specialization (where algorithms are embedded at points within the taxonomy, and potentially specialized with inheritance).\n",
    "\n",
    "In the examples that follow, we will show for exposition the hierarchy of types and the algorithms operating on them, but the reality is that the algorithms are often designed first, and the abstact types came later."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "7a6baa46",
   "metadata": {},
   "source": [
    "## Distributions\n",
    "\n",
    "First, consider working with “distributions”.\n",
    "\n",
    "Algorithms using distributions might (1) draw random numbers for Monte-Carlo methods; and (2) calculate the pdf or cdf – if it is defined.\n",
    "\n",
    "The process of using concrete distributions in these sorts of applications led\n",
    "to the creation of the [Distributions.jl](https://github.com/JuliaStats/Distributions.jl) package.\n",
    "\n",
    "Let’s examine the tree of types for a Normal distribution"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "7d31b176",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "using Distributions\n",
    "d1 = Normal(1.0, 2.0) # an example type to explore\n",
    "@show d1\n",
    "show_supertypes(typeof(d1))"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "94db862f",
   "metadata": {},
   "source": [
    "The `Sampleable{Univariate,Continuous}` type has a limited number of functions, chiefly the ability to draw a random number"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "3910b999",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "@show rand(d1);"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "9367a3c3",
   "metadata": {},
   "source": [
    "The purpose of that abstract type is to provide an interface for drawing from a\n",
    "variety of distributions, some of which may not have a well-defined predefined pdf.\n",
    "\n",
    "If you were writing a function to simulate a stochastic process with arbitrary\n",
    "iid shocks, where you did not need to assume an existing pdf etc., this is a natural candidate.\n",
    "\n",
    "For example, to simulate $ x_{t+1} = a x_t + b \\epsilon_{t+1} $ where\n",
    "$ \\epsilon \\sim D $ for some $ D $, which allows drawing random values."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "320addf4",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "function simulateprocess(x_0; a = 1.0, b = 1.0, N = 5,\n",
    "                         d::Sampleable{Univariate, Continuous})\n",
    "    x = zeros(typeof(x_0), N + 1) # preallocate vector, careful on the type\n",
    "    x[1] = x_0\n",
    "    for t in 2:(N + 1)\n",
    "        x[t] = a * x[t - 1] + b * rand(d) # draw\n",
    "    end\n",
    "    return x\n",
    "end\n",
    "@show simulateprocess(0.0, d = Normal(0.2, 2.0));"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "4743aa9e",
   "metadata": {},
   "source": [
    "The `Sampleable{Univariate,Continuous}` and, especially, the `Sampleable{Multivariate,Continuous}` abstract types are useful generic interfaces for Monte-Carlo and Bayesian methods.\n",
    "\n",
    "Moving down the tree, the `Distributions{Univariate, Continuous}` abstract type has other functions we can use for generic algorithms operating on distributions.\n",
    "\n",
    "These match the mathematics, such as `pdf`, `cdf`, `quantile`, `support`, `minimum`, `maximum`, etc."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "38019442",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "d1 = Normal(1.0, 2.0)\n",
    "d2 = Exponential(0.1)\n",
    "@show d1\n",
    "@show d2\n",
    "@show supertype(typeof(d1))\n",
    "@show supertype(typeof(d2))\n",
    "\n",
    "@show pdf(d1, 0.1)\n",
    "@show pdf(d2, 0.1)\n",
    "@show cdf(d1, 0.1)\n",
    "@show cdf(d2, 0.1)\n",
    "@show support(d1)\n",
    "@show support(d2)\n",
    "@show minimum(d1)\n",
    "@show minimum(d2)\n",
    "@show maximum(d1)\n",
    "@show maximum(d2);"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "50e36f81",
   "metadata": {},
   "source": [
    "You could create your own `Distributions{Univariate, Continuous}` type by implementing those functions – as is described in [the documentation](https://juliastats.github.io/Distributions.jl/latest/extends/).\n",
    "\n",
    "If you fulfill all of the conditions of a particular interface, you can use algorithms from the present, past, and future  that are written for the abstract `Distributions{Univariate, Continuous}` type.\n",
    "\n",
    "As an example, consider the [StatsPlots](https://github.com/JuliaPlots/StatsPlots.jl) package"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "2100565b",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "using StatsPlots\n",
    "d = Normal(2.0, 1.0)\n",
    "plot(d) # note no other arguments!"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "32c1f9ec",
   "metadata": {},
   "source": [
    "Calling `plot` on any subtype of `Distributions{Univariate, Continuous}`\n",
    "displays the `pdf` and uses `minimum` and `maximum` to determine the range.\n",
    "\n",
    "Let’s create our own distribution type"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "d43c47f9",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "struct OurTruncatedExponential <: Distribution{Univariate, Continuous}\n",
    "    alpha::Float64\n",
    "    xmax::Float64\n",
    "end\n",
    "function Distributions.pdf(d::OurTruncatedExponential, x::Real)\n",
    "    d.alpha * exp(-d.alpha * x) / exp(-d.alpha * d.xmax)\n",
    "end\n",
    "Distributions.minimum(d::OurTruncatedExponential) = 0\n",
    "Distributions.maximum(d::OurTruncatedExponential) = d.xmax\n",
    "# ... more to have a complete type"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "6c6f96ee",
   "metadata": {},
   "source": [
    "To demonstrate this"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "af8d2613",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "d = OurTruncatedExponential(1.0, 2.0)\n",
    "@show minimum(d), maximum(d)\n",
    "@show support(d) # why does this work?"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "684bba12",
   "metadata": {},
   "source": [
    "Curiously, you will note that the `support` function works, even though we did not provide one.\n",
    "\n",
    "This is another example of the power of multiple dispatch and generic programming.\n",
    "\n",
    "In the background, the `Distributions.jl` package  has something like the following implemented"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "d2579121",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "    Distributions.support(d::Distribution) = RealInterval(minimum(d), maximum(d))"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "0aec932d",
   "metadata": {},
   "source": [
    "Since `OurTruncatedExponential <: Distribution`, and we\n",
    "implemented `minimum` and `maximum`, calls to `support` get this\n",
    "implementation as a fallback.\n",
    "\n",
    "These functions are enough to use the  `StatsPlots.jl` package"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "00c282df",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "plot(d) # uses the generic code!"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "84de3568",
   "metadata": {},
   "source": [
    "A few things to point out\n",
    "\n",
    "- Even if it worked for `StatsPlots`, our implementation is incomplete, as we haven’t fulfilled all of the requirements of a `Distribution`.  \n",
    "- We also did not implement the `rand` function, which means we are breaking the implicit contract of the `Sampleable` abstract type.  \n",
    "- It turns out that there is a better way to do this precise thing already built into `Distributions`.  "
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "7c03b375",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "d = Truncated(Exponential(0.1), 0.0, 2.0)\n",
    "@show typeof(d)\n",
    "plot(d)"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "f8a695c4",
   "metadata": {},
   "source": [
    "This is the power of generic programming in general, and Julia in particular: you can combine and compose completely separate packages and code, as long as there is an agreement on abstract types and functions."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "8290d072",
   "metadata": {},
   "source": [
    "## Numbers and Algebraic Structures\n",
    "\n",
    "Define two binary functions,  $ + $ and $ \\cdot $, called addition and multiplication – although the operators can be applied to data structures much more abstract than a `Real`.\n",
    "\n",
    "In mathematics, a [ring](https://en.wikipedia.org/wiki/Ring_%28mathematics%29) is a set with associated additive and multiplicative operators where\n",
    "\n",
    "- the additive operator is associative and commutative  \n",
    "- the multiplicative operator is associative and distributive with respect to the additive operator  \n",
    "- there is an additive identity element,  denoted $ 0 $, such that $ a + 0 = a $ for any $ a $ in the set  \n",
    "- there is an additive inverse of each element, denoted $ -a $, such that $ a + (-a) = 0 $  \n",
    "- there is a multiplicative identity element, denoted $ 1 $, such that $ a \\cdot 1 = a = 1 \\cdot a $  \n",
    "- a total or partial ordering is **not** required (i.e., there does not need to be any meaningful $ < $ operator defined)  \n",
    "- a multiplicative inverse is **not** required  \n",
    "\n",
    "\n",
    "While this skips over some parts of the mathematical definition, this algebraic structure provides motivation for the abstract `Number` type in Julia\n",
    "\n",
    "- **Remark:** We use the term “motivation” because they are not formally connected and the mapping is imperfect.  \n",
    "- The main difficulty when dealing with numbers that can be concretely created on a computer is that the requirement that the operators are closed in the set are difficult to ensure (e.g. floating points have finite numbers of bits of information).  \n",
    "\n",
    "\n",
    "Let `typeof(a) = typeof(b) = T <: Number`, then under an informal definition of the **generic interface** for\n",
    "`Number`, the following must be defined\n",
    "\n",
    "- the additive operator: `a + b`  \n",
    "- the multiplicative operator: `a * b`  \n",
    "- an additive inverse operator: `-a`  \n",
    "- an inverse operation for addition `a - b = a + (-b)`  \n",
    "- an additive identity: `zero(T)` or `zero(a)` for convenience  \n",
    "- a multiplicative identity: `one(T)` or `one(a)` for convenience  \n",
    "\n",
    "\n",
    "The core of generic programming is that, given the knowledge that a value is of type `Number`, we can design algorithms using any of these functions and not concern ourselves with the particular concrete type.\n",
    "\n",
    "Furthermore, that generality in designing algorithms comes with no compromises on performance compared to carefully designed algorithms written for that particular type.\n",
    "\n",
    "To demonstrate this for a complex number, where `Complex{Float64} <: Number`"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "f82b2e09",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "a = 1.0 + 1.0im\n",
    "b = 0.0 + 2.0im\n",
    "@show typeof(a)\n",
    "@show typeof(a) <: Number\n",
    "@show a + b\n",
    "@show a * b\n",
    "@show -a\n",
    "@show a - b\n",
    "@show zero(a)\n",
    "@show one(a);"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "89272f07",
   "metadata": {},
   "source": [
    "And for an arbitrary precision integer where `BigInt <: Number`\n",
    "(i.e., a different type than the `Int64` you have worked with, but nevertheless a `Number`)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "e3feb0d8",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "a = BigInt(10)\n",
    "b = BigInt(4)\n",
    "@show typeof(a)\n",
    "@show typeof(a) <: Number\n",
    "@show a + b\n",
    "@show a * b\n",
    "@show -a\n",
    "@show a - b\n",
    "@show zero(a)\n",
    "@show one(a);"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "d68656ce",
   "metadata": {},
   "source": [
    "### Complex Numbers and Composition of Generic Functions\n",
    "\n",
    "This allows us to showcase further how different generic packages compose – even if they are only loosely coupled through agreement on common generic interfaces.\n",
    "\n",
    "The `Complex` numbers require some sort of storage for their underlying real and imaginary parts, which is itself left generic.\n",
    "\n",
    "This data structure is defined to work with any type `<: Number`, and is parameterized (e.g. `Complex{Float64}` is a complex number storing the imaginary and real parts in `Float64`)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "aa49a3d1",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "x = 4.0 + 1.0im\n",
    "@show x, typeof(x)\n",
    "\n",
    "xbig = BigFloat(4.0) + 1.0im\n",
    "@show xbig, typeof(xbig);"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "ac1a314f",
   "metadata": {},
   "source": [
    "The implementation of the `Complex` numbers use the underlying operations of\n",
    "storage type, so as long as `+`, `*` etc. are defined – as they should be\n",
    "for any `Number` – the complex operation can be defined"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "1a368a06",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "@which +(x, x)"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "9c881ca2",
   "metadata": {},
   "source": [
    "Following that link, the implementation of `+` for complex numbers is"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "b613c0c0",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "+(z::Complex, w::Complex) = Complex(real(z) + real(w), imag(z) + imag(w))"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "313326a7",
   "metadata": {},
   "source": [
    "`real(z)` and `imag(z)` returns the associated components of the complex number in the underlying storage type (e.g. `Float64` or `BigFloat`).\n",
    "\n",
    "The rest of the function has been carefully written to use functions defined for any `Number` (e.g. `+` but not `<`, since it is not part of the generic number interface).\n",
    "\n",
    "To follow another example , look at the implementation of `abs` specialized for complex numbers"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "a5637acf",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "@which abs(x)"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "b1a1dade",
   "metadata": {},
   "source": [
    "The source is"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "c3e0ceaf",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "abs(z::Complex)  = hypot(real(z), imag(z))"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "6dff936f",
   "metadata": {},
   "source": [
    "In this case, if you look at the generic function to get the hypotenuse, `hypot`, you will see that it has the function signature `hypot(x::T, y::T) where T<:Number`, and hence works for any `Number`.\n",
    "\n",
    "That function, in turn, relies on the underlying `abs` for the type of `real(z)`.\n",
    "\n",
    "This would dispatch to the appropriate `abs` for the type"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "bae6a244",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "@which abs(1.0)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "5a2b2cea",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "@which abs(BigFloat(1.0))"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "4d2241be",
   "metadata": {},
   "source": [
    "With implementations"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "72ddf924",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "abs(x::Real) = ifelse(signbit(x), -x, x)\n",
    "abs(x::Float64) = abs_float(x)"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "e60bde0e",
   "metadata": {},
   "source": [
    "For a `Real` number (which we will discuss in the next section) the fallback implementation calls a function `signbit` to determine if it should flip the sign of the number.\n",
    "\n",
    "The specialized version for `Float64 <: Real` calls a function called `abs_float` – which turns out to be a specialized implementation at the compiler level.\n",
    "\n",
    "While we have not completely dissected the tree of function calls, at the bottom of the tree you will end at the most optimized version of the function for the underlying datatype.\n",
    "\n",
    "Hopefully this showcases the power of generic programming:  with a well-designed set of abstract types and functions, the code can both be highly general and composable and still use the most efficient implementation possible."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "c82b65b5",
   "metadata": {},
   "source": [
    "## Reals and Algebraic Structures\n",
    "\n",
    "Thinking back to the mathematical motivation, a [field](https://en.wikipedia.org/wiki/Field_%28mathematics%29) is a `ring` with a few additional properties, among them\n",
    "\n",
    "- a multiplicative inverse: $ a^{-1} $  \n",
    "- an inverse operation for multiplication: $ a / b = a \\cdot b^{-1} $  \n",
    "\n",
    "\n",
    "Furthermore, we will make it a [total ordered](https://en.wikipedia.org/wiki/Total_order#Strict_total_order) field with\n",
    "\n",
    "- a total ordering binary operator: $ a < b $  \n",
    "\n",
    "\n",
    "This type gives some motivation for the operations and properties of the `Real` type.\n",
    "\n",
    "Of course, `Complex{Float64} <: Number` but not `Real` – since the ordering is not defined for complex numbers in mathematics.\n",
    "\n",
    "These operations are implemented in any subtype of `Real` through\n",
    "\n",
    "- the multiplicative inverse: `inv(a)`  \n",
    "- the multiplicative inverse operation: `a / b = a * inv(b)`  \n",
    "- an ordering `a < b`  \n",
    "\n",
    "\n",
    "We have already shown these with the `Float64` and `BigFloat`.\n",
    "\n",
    "To show this for the `Rational` number type, where `a // b` constructs a rational number $ \\frac{a}{b} $"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "3a66bcf5",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "a = 1 // 10\n",
    "b = 4 // 6\n",
    "@show typeof(a)\n",
    "@show typeof(a) <: Number\n",
    "@show typeof(a) <: Real\n",
    "@show inv(a)\n",
    "@show a / b\n",
    "@show a < b;"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "52223d63",
   "metadata": {},
   "source": [
    "**Remark:** Here we see where and how the precise connection to the mathematics for number types breaks down for practical reasons, in particular\n",
    "\n",
    "- `Integer` types (i.e., `Int64 <: Integer`) do not have a a multiplicative inverse with closure in the set.  \n",
    "- However, it is necessary in practice for integer division to be defined, and return back a member of the `Real`’s.  \n",
    "- This is called [type promotion](https://docs.julialang.org/en/v1/manual/conversion-and-promotion/#Promotion-1), where a type can be converted to another to ensure an operation is possible by direct conversion between types (i.e., it can be independent of the type hierarchy).  \n",
    "\n",
    "\n",
    "Do not think of the break in the connection between the underlying algebraic structures and the code as a failure of the language or design.\n",
    "\n",
    "Rather, the underlying algorithms for use on a computer do not perfectly fit the algebraic structures in this instance.\n",
    "\n",
    "Moving further down the tree of types provides more operations more directly tied to the computational implementation than abstract algebra.\n",
    "\n",
    "For example, floating point numbers have a machine precision, below which numbers become indistinguishable due to lack of sufficient “bits” of information"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "ac3935b1",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "@show Float64 <: AbstractFloat\n",
    "@show BigFloat <: AbstractFloat\n",
    "@show eps(Float64)\n",
    "@show eps(BigFloat);"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "ad384bb3",
   "metadata": {},
   "source": [
    "The `isless` function also has multiple methods.\n",
    "\n",
    "First let’s try with integers"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "f5f13ff9",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "@which isless(1, 2)"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "2d0a5fc3",
   "metadata": {},
   "source": [
    "As we saw previously, the `Real` data type is an *abstract* type, and encompasses both floats and integers.\n",
    "\n",
    "If we go to the provided link in the source, we see the entirety of the function is"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "c440ae8e",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "isless(x::Real, y::Real) = x<y"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "8ead3dc5",
   "metadata": {},
   "source": [
    "That is, for any values where `typeof(x) <: Real` and `typeof(y) <: Real`, the definition relies on `<`.\n",
    "\n",
    "We know that `<` is defined for the types because it is part of the informal interface for the `Real` abstract type.\n",
    "\n",
    "Note that this is not defined for `Number` because not all `Number` types have the `<` ordering operator defined (e.g. `Complex`).\n",
    "\n",
    "In order to generate fast code, the implementation details may define specialized versions of these operations."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "8a88ed82",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "isless(1.0, 2.0)  # applied to two floats\n",
    "@which isless(1.0, 2.0)"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "c90a00e5",
   "metadata": {},
   "source": [
    "Note that the reason  `Float64 <: Real` calls this implementation rather than the one given above, is that `Float64 <: Real`, and Julia chooses the most specialized implementation for each function.\n",
    "\n",
    "The specialized implementations are often more subtle than you may realize due to [floating point arithmetic](https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html), [underflow](https://en.wikipedia.org/wiki/Arithmetic_underflow), etc."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "c5c2ab3a",
   "metadata": {},
   "source": [
    "## Functions, and Function-Like Types\n",
    "\n",
    "Another common example of the separation between data structures and algorithms is the use of functions.\n",
    "\n",
    "Syntactically, a univariate “function” is any `f` that can call an argument `x` as `f(x)`.\n",
    "\n",
    "For example, we can use a standard function"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "413962d8",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "using QuadGK\n",
    "f(x) = x^2\n",
    "@show quadgk(f, 0.0, 1.0)  # integral\n",
    "\n",
    "function plotfunctions(f)\n",
    "    intf(x) = quadgk(f, 0.0, x)[1]  # int_0^x f(x) dx\n",
    "\n",
    "    x = 0:0.1:1.0\n",
    "    f_x = f.(x)\n",
    "    plot(x, f_x, label = \"f\")\n",
    "    plot!(x, intf.(x), label = \"int_f\")\n",
    "end\n",
    "plotfunctions(f)  # call with our f"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "2f2e604a",
   "metadata": {},
   "source": [
    "Of course, univariate polynomials are another type of univariate function"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "40bb8cce",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "using Polynomials\n",
    "p = Polynomial([2, -5, 2], :x)  # :x just gives a symbol for display\n",
    "@show p\n",
    "@show p(1.0) # call like a function\n",
    "\n",
    "plotfunctions(p)  # same generic function"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "fc3996f8",
   "metadata": {},
   "source": [
    "Similarly, the result of interpolating data is also a function"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "4a154b73",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "using Interpolations\n",
    "x = 0.0:0.2:1.0\n",
    "f(x) = x^2\n",
    "f_int = LinearInterpolation(x, f.(x))  # interpolates the coarse grid\n",
    "@show f_int(1.0)  # call like a function\n",
    "\n",
    "plotfunctions(f_int)  # same generic function"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "d03b4a89",
   "metadata": {},
   "source": [
    "Note that the same generic `plotfunctions` could use any variable passed to it that “looks” like a function, i.e., can call `f(x)`.\n",
    "\n",
    "This approach to design with types – generic, but without any specific type declarations – is called [duck typing](https://en.wikipedia.org/wiki/Duck_typing).\n",
    "\n",
    "If you need to make an existing type callable, see [Function Like Objects](https://docs.julialang.org/en/v1/manual/methods/#Function-like-objects-1)."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "0417f162",
   "metadata": {},
   "source": [
    "## Limitations of Dispatching on Abstract Types\n",
    "\n",
    "You will notice that types in Julia represent a tree with `Any` at the root.\n",
    "\n",
    "The tree structure has worked well for the above examples, but it doesn’t allow us to associate multiple categorizations of types.\n",
    "\n",
    "For example, a semi-group type would be useful for a writing generic code (e.g.\n",
    "continuous-time solutions for ODEs and matrix-free methods), but cannot be\n",
    "implemented rigorously since the `Matrix` type is a semi-group as well\n",
    "as an `AbstractArray`, but not all semi-groups are `AbstractArray` s.\n",
    "\n",
    "The main way to implement this in a generic language is with a design approach called “traits”.\n",
    "\n",
    "- See the [original discussion](https://github.com/JuliaLang/julia/issues/2345#issuecomment-54537633) and an [example of a package to facilitate the pattern](https://github.com/mauro3/SimpleTraits.jl).  \n",
    "- A complete description of the traits pattern as the natural evolution of Multiple Dispatch is given in this [blog post](https://white.ucc.asn.au/2018/10/03/Dispatch,-Traits-and-Metaprogramming-Over-Reflection.html).  "
   ]
  },
  {
   "cell_type": "markdown",
   "id": "cda750c1",
   "metadata": {},
   "source": [
    "## Exercises"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "002c201b",
   "metadata": {},
   "source": [
    "### Exercise 1a\n",
    "\n",
    "In a previous exercise, we discussed the [trapezoidal rule](https://julia.quantecon.org/../getting_started_julia/introduction_to_types.html#intro-types-ex-5) for numerical integration.\n",
    "\n",
    "To summarize, the vector\n",
    "\n",
    "$$\n",
    "\\int_{\\underline{x}}^{\\bar{x}} f(x) \\, dx \\approx \\omega \\cdot \\vec{f}\n",
    "$$\n",
    "\n",
    "where $ \\vec{f} \\equiv \\begin{bmatrix} f(x_1) & \\ldots & f(x_N) \\end{bmatrix}\\in R^N $ and, for a uniform grid spacing\n",
    "of $ \\Delta $,\n",
    "\n",
    "$$\n",
    "\\omega \\equiv \\Delta \\begin{bmatrix} \\frac{1}{2} & 1 & \\ldots & 1 & \\frac{1}{2}\\end{bmatrix} \\in R^N\n",
    "$$\n",
    "\n",
    "The quadrature rule can be implemented easily as"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "b209d9ef",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "using LinearAlgebra\n",
    "function trap_weights(x)\n",
    "    return step(x) * [0.5; ones(length(x) - 2); 0.5]\n",
    "end\n",
    "x = range(0.0, 1.0, length = 100)\n",
    "ω = trap_weights(x)\n",
    "f(x) = x^2\n",
    "dot(f.(x), ω)"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "2f498015",
   "metadata": {},
   "source": [
    "However, in this case the creation of the `ω` temporary is inefficient as there are no reasons to allocate an entire vector just\n",
    "to iterate through it with the `dot`.  Instead, create an iterable by following the [interface definition for Iteration](https://docs.julialang.org/en/v1/manual/interfaces/#man-interface-iteration-1), and\n",
    "implement the modified `trap_weights` and integration.\n",
    "\n",
    "Hint:  create a type such as"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "66e52997",
   "metadata": {
    "hide-output": false
   },
   "outputs": [],
   "source": [
    "struct UniformTrapezoidal\n",
    "    count::Int\n",
    "    Δ::Float64\n",
    "end"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "69a27c57",
   "metadata": {},
   "source": [
    "and then implement the function `Base.iterate(S::UniformTrapezoidal, state=1)`."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "3d88c31e",
   "metadata": {},
   "source": [
    "### Exercise 1b (Advanced)\n",
    "\n",
    "Make the `UniformTrapezoidal` type operate as an array with [interface definition for AbstractArray](https://docs.julialang.org/en/v1/manual/interfaces/#man-interface-array-1).  With this, you should be able it go `ω[2]` or `length(ω)` to access the quadrature weights."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "134aa5ed",
   "metadata": {},
   "source": [
    "### Exercise 2 (Advanced)\n",
    "\n",
    "Implement the same features as Exercise 1a and 1b, but for the  [non-uniform trapezoidal rule](https://en.wikipedia.org/wiki/Trapezoidal_rule#Non-uniform_grid)."
   ]
  }
 ],
 "metadata": {
  "date": 1732137475.4785233,
  "filename": "generic_programming.md",
  "kernelspec": {
   "display_name": "Julia",
   "language": "julia",
   "name": "julia-1.11"
  },
  "title": "Generic Programming"
 },
 "nbformat": 4,
 "nbformat_minor": 5
}