![\"Spreadsheet](\"/images/fib-spread.png\")
Orig: Music to hear, why hear’st thou music sadly?\nComp: 00100010111011111100101101110010100010100101110000111000000101101001001111111100111000101110000111000000100100011111110000101000111010101101101000100111011111100101101110010111111001011010010011100011011101\nDeco: Music to hear, why hear’st thou music sadly?\nSize uncompressed 44\nSize compressed 26# This is part of my anti-atrophy tasks. As most of my professional software development\n# tasks are now is done through agentic development. This is fitness for the brain!\n#\n# Solely based on what's here: https://en.wikipedia.org/wiki/Huffman_coding\n\nimport requests\nimport pprint\nimport heapq\nimport math\n\n# Fetch the file, this is our corpus\nresponse = requests.get("https://www.gutenberg.org/cache/epub/100/pg100.txt")\ntext = response.text\n\n# Calculate frequencies\n\nfreqs = {}\ncount = 0\n\nfor c in text:\n if not c in freqs:\n freqs[c] = 0\n freqs[c] += 1\n count += 1\n\n# Normalize\nfor k in freqs:\n freqs[k] = freqs[k] / count\n\n# How priority queues aka head queues work\np1 = []\n# heapq.heapify(p1) - No need to run for empty lists\n\nheapq.heappush(p1, (5, "not so important"))\nheapq.heappush(p1, (1, "Really important"))\nheapq.heappush(p1, (20, "Forget it"))\nheapq.heappush(p1, (24, ("t1", "t2", "t3")))\n\nimportant_task = heapq.heappop(p1)\n\nassert important_task[0] == 1\n\n# For heapq when using the tuples, it will go onto next element if the first element is identical.\n# The docs are framing the type construction as a payload to attach a payload.\n# This is over loaded semantics (shane on you, Python)\ntie_breaker = 0\ndef next_tie_breaker():\n global tie_breaker\n tie_breaker += 1\n return tie_breaker\n\n\nleafs = []\nfor k in freqs:\n heapq.heappush(leafs, (freqs[k], next_tie_breaker(), k))\n\n# Alternatively\n# leafs1 = [(v, next_tie_breaker(), k) for k, v in freqs.items()]\n# heapq.heapify(leafs1)\n\n# Representing the tree:\n# Leaf (frq, _, symbol)\n# Node: (frq, _, (left, right))\n\nwhile True:\n if len(leafs) == 1:\n break\n\n a = heapq.heappop(leafs)\n b = heapq.heappop(leafs)\n sumProp = a[0] + b[0]\n node = (sumProp, next_tie_breaker(), (a, b))\n\n heapq.heappush(leafs, node)\n\nhuffman_tree = heapq.heappop(leafs)\n\nhuffman_dict = {}\nrev_huffman_dict = {}\n\nstack = [("", huffman_tree)]\nwhile len(stack) > 0:\n next = stack.pop()\n\n match(next):\n case (prefix, (frq, x, (left, right))):\n stack.append((prefix + "1", left))\n stack.append((prefix + "0", right))\n case (prefix, (frq, x, symbol)):\n huffman_dict[prefix] = symbol\n rev_huffman_dict[symbol] = prefix\n case _:\n pprint.pprint(next)\n\n\n\n# Let's compress something!\n\nstring = "Music to hear, why hear’st thou music sadly?"\n\n\n# compress\ncompressed = ""\nfor c in string:\n compressed += rev_huffman_dict[c]\n\ndecompressed = ""\ntree_traverser = huffman_tree\nfor c in compressed:\n # Traverse the tree\n if c == "1":\n tree_traverser = tree_traverser[2][0]\n if c == "0":\n tree_traverser = tree_traverser[2][1]\n\n # Are we at a leaf?\n if isinstance(tree_traverser[2], str):\n decompressed += tree_traverser[2]\n tree_traverser = huffman_tree\n\n\nprint(f"Orig: {string}")\nprint(f"Comp: {compressed}")\nprint(f"Deco: {decompressed}")\n\nprint(f"Size uncompressed {len(string)}")\nprint(f"Size compressed {math.ceil(len(compressed) / 8)}") # We approximate hereMy 100 days of Fibonacci challenge\nstarted yesterday where I implemented the function directly recursive\nand using accumulated recursion in Haskell.\nToday I decided to take one of the most widely known\nlanguages and implement of iterative edition of the Fibonacci function.
\nIn C I implemented Fibonacci iteratively. In the implementation I have used\nthe type long to store intermediate results and return values. It\nguarantees 32 bit of storage, which allows us to compute large enough results.
unsigned long fib_iterative(long n){\n unsigned long i=0, a=0, b=1;\n for(i=1 ; i<=n ; i++){\n unsigned long tmp = a+b;\n a = b;\n b=tmp;\n }\n return a;\n}Overflows needs to be carefully thought about in C. The language\nprovides very little support for unlimited integers compared to\nyesterdays language, Haskell, which indeed had support for big integers.
\nHaskell supports large integers by using a library which uses strings\nfor representing integers along with implementations of arithmetic\nfunctions for working on these integers. This could also have been\nimplemented in C. However, this is out of scope for this article.
\nThe full code for Fibonacci in C is available\non Github.\nBe aware that the code might change when I feel for implementing other\nalgorithms in C.
\nThe iterative Fibonacci has a linear time complexity. This is the same\nas the tail recursive implementation. These two implementations also\nhave much in common.
\nThe iterative implementation con not be implemented in pure\nfunctional languages because it requires mutable states.\nThis is seen when we change the value of a in the\nabove example by a = b;. Furthermore the while concept is not natural to\nfunctional programming, where operations on collections of elements\nare done recursively.
C was meant to be close to the hardware. As a slight layer\non assembly programming. A language used for programming operating\nsystems and hardware driver. And so it is fast as it has a minimal\nruntime system and lets the programmer have complete control over\nthe hardware.
\nThe control is also often the downside of this language. As it provides\na limited set of abstraction, it is easy to make errors. Errors like\nbuffer overflows are not rare when looking at projects written in C.
\n"},{"url":"/100-days-of-fibonacci-day-10-python/","relativePath":"100-days-of-fibonacci-day-10-python.md","relativeDir":"","base":"100-days-of-fibonacci-day-10-python.md","name":"100-days-of-fibonacci-day-10-python","frontmatter":{"title":"100 Days of Fibonacci - Day 10, Python","layout":"post","video":false,"comments":false,"image":"/assets/images/cover.jpg","image2":"/assets/images/cover.jpg","date":"2016-02-20","template":"post"},"html":"\nIt is yet another time for a post in my\n100 days of Fibonacci challenge.\nToday I am containing myself a bit and provide a link between\na concept in programming and its root in mathematics.
\n\nThe concept is list comprehension in Python. Python is a widely\nused programming language especially used as an easy language\nappropriate for beginners. The languages is in particular\nclose to English. Furthermore it enforces good style by scoping by indentation.
\n\nAs mentioned I zoom in on the list comprehension feature in\nPython. I relate this feature with the way sets are defined in\nmath. Lastly I talk a bit about the interpretation of infinite sets in\nprogramming.
\n\nThe implementation is the direct recursive implementation accompanied\nby dynamic programming by momoization. This as\nmy Java implementation. It is not\nnew to implement it like this, and simply provides a predicate to use in\nthe list comprehension.
\ncache = {}\ndef fib(n):\n if cache.get(n, None) != None :\n return cache[n]\n\n if n == 0 :\n return 0\n if n == 1 :\n return 1\n\n cache[n] = fib(n-1) + fib(n-2)\n return cache[n]The cache is here used as a global variable. Global variables are something one\nshould by all means avoid, but here the amount of code is small and the main\ngoal of this post is not software architecture.
\n\nFrom here we can know create the list of the 20 first Fibonacci numbers using\nlist comprehension in Python. We print it directly to provide an output.
\nprint [fib(x) for x in range(20)]This is a one-liner for mapping the list of numbers from 0 to 19 to the list\ntheir corresponding Fibonacci numbers.
\n$ python fib.py \n[0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ..., 4181]The implementation is available from my supporting\nGit repository.
\nThe notation used above looks mostly like a very compact for-loop. For this\nrelation to work we need to slightly open up our understanding of lists and\niteration in programming languages.
First we need to view a list as a set. It should be quite clear that a list\nindeed can be a set. For that to work we need operations like intersection,\nunion, difference, etc. Any programmer should be able to quickly implement\nthose. The contrary, that lists are sets, are not given. Lists are inherently\nordered, where sets are unordered.
\n\nThe other thing is the for-loop. for-loops are usually viewed as iterating\nall elements in a list one-by-one, and doing something to them. Instead we\ncan see it as quantification. For a second we should forget everything about\nthe order of the list and details about iterations, and just see it as we\nperform an operation on every single element in the set.
We now have the mindset set for the following mathematical interpretation of\nthe above list comprehension to work. The following is a direct translation.
\n$$\n \\{ \\ fib(x) \\ | \\ x \\in \\{0, 1, 2, 3, 4, 5, ..., 19\\} \\ \\}\n$$\nwhich would usually be written as follows.
\n$$\n \\{ \\ fib(x) \\ | \\ x \\in \\mathbb{N} \\ \\}\n$$\nThe reason why the last formulation is kind of futile is that Python\nuses strict evaluation: All terms are evaluated. The set of naturals is\ninfinite and hence the computation will not halt.
\nThe last formulation is, however, possible to formulate in programming.\nWe just need a lazy evaluated language. As such we can formulate it, and use\nit, in the Haskell programming language. Following works given an\nimplementation of the fib function:
[fib n | n <- [0..]]And what is all this worth? Well, a lot of material programmers have to\nimplement was first formulated in a mathematical language. This relations seeks\nthe demystify the relation between programming and math. In fact it can (and\nis / will be in other posts) be argued that math and programming is in fact\nthe same thing. But for some reason the two areas are somewhat disjoint. This,\nin my opinion, largely because of two cultures in communicating.
\nIn this post i implemented Fibonacci in python. There is nothing new to\nthe implementation. It was a directly recursive implementation supported\nby a cache for speed.
\n\nThe concept elaborated in this post is list comprehension and its relationship\nthe the mathematical formulation of sets. Ultimately my message is that we as\nprogrammers should be able to both formulate and interpret in other frameworks.\nAlso those seemingly very distant frameworks, like mathematics is for\nmany programmers.
\n"},{"url":"/100-days-of-fibonacci-day-0-haskell/","relativePath":"100-days-of-fibonacci-day-0-haskell.md","relativeDir":"","base":"100-days-of-fibonacci-day-0-haskell.md","name":"100-days-of-fibonacci-day-0-haskell","frontmatter":{"title":"Day 0, Haskell","subtitle":"100 Days of Fibonacci","date":"2015-12-15","template":"post"},"html":"Today I taught my computer architecture class for the last time.\nMy students and I discussed the complexity of the various Fibonacci\nalgorithms. Fibonacci is a function often used to test out new\nprogramming languages as it is easy to implement and can showcase\nmany techniques.
\nLater on I worked with my friend Anders Schmidt who showed me\nPaul Flavius Nechita's 100 Days UI Challenge.\nI thought it was cool and wanted to do something similar. But\nI do not design.
\nSo I decided to program Fibonacci in 100 different programming languages.\nThe idea is to showcase some typical aspects of a programming\nlanguage and implement the function in the different languages idiomatic ways.
\nAs today is the first day of this project I am going to present Fibonacci\nin Haskell. This is mostly because I recently have spend quite some time\nwith that language. The formulations of the function is going to be\nby direct recursion and recursion with accumulation.
\nWhere else would you start? Here we look at Haskell as a practical\ngeneral purpose language.
\nIn Haskell I did two different implementations. First, the\nrecursive way, which is the way we usually think of problems in\na functional context. We use pattern matching to pick out the\nbase and induction cases.
\n-- Standard recursive implementation, very slow\nfib :: Integer -> Integer\nfib 0 = 0\nfib 1 = 1\nfib n = fib (n - 1) + fib (n - 2)However, it turns out that this solution is quite slow due to the\nexponential fanout with the two recursive calls.\nLuckily there is another way! So I implemented it using recursion\nwith an accumulator:
\n-- Using an accumulator\nfibAcc :: Integer -> Integer\nfibAcc n = doFib n (0,1)\n where\n doFib :: Integer -> (Integer, Integer) -> Integer\n doFib 0 (a, b) = a\n doFib n (a, b) = doFib (n-1) (a+b, a)To keep the type signature identical to the other Fibonacci\nwe uses the where construction to wrap the actual function.
Lastly we need to make a command line program that takes the number (i.e. n)\nthat we want to calculate $fib(n)$ for. As Haskell is pure and lazy, we\ncan't simply in line system calls like we do in c. In Haskell a monadic\nstyle is chosen.
\n-- First argument is read and parsed as Integer\nmain = do\n a <- getArgs\n putStrLn $ show (fibAcc $ read (a !! 0) )In the above example we first read the list of arguments into\na, thereafter we parse the first (0th) element and calculate\nthe corresponding Fibonacci number. The result is converted\nto a string and written back to the command line.
Haskell provides two ways to evaluate a program. It has its REPL\n(read-eval-print loop) where the file can be loaded and the\nprogram can be compiled.
\n$ ghci Fib.hs\n...\nOk, modules loaded: Main.\n*Main> fib 10\n55\n*Main> fibAcc 10\n55Alternatively Haskell can be compiled and executed:
\n$ ghc Fib.hs -o fib\n$ ./fib 10\n55The file is available for download\nhere.
\nIn this first implementation we used two techniques for implementing\nthe Fibonacci function:
\nHere we take offset in Haskell as a general purpose language.\nAmong others it is known for its extremely flexible type\nsystem which enables us to reason quite fine grained about our\nprograms.
\nHowever, the concerns we have with Haskell here is how well\nit integrates with other lagnauges and the complexity of the output\ncode. As seen it is relatively easy to implement a linear\nalgorithm of Fibonacci.
\nFunctional programming has in general\nshown good progress in outputting efficient code, and for many\napplications the generally superior readability is better\nthan squeezing that last performance out of the CPU.
\nHaskell integrates well with the rest of the system. This\nexample shows the use of command line arguments, which are fairly\nstraight forward. Furthermore Haskell supports\nFFI for\nboth importing and exporting functions.
\nI have elaborated on the Fibonacci implementation and presented it\nby two formulations: Direct recursion and recursion with an accumulator.\nThe language to carry the implementation has been Haskell. Haskell\nwas presented and swiftly evaluated.
\n"},{"url":"/100-days-of-fibonacci-day-11-fixed-point/","relativePath":"100-days-of-fibonacci-day-11-fixed-point.md","relativeDir":"","base":"100-days-of-fibonacci-day-11-fixed-point.md","name":"100-days-of-fibonacci-day-11-fixed-point","frontmatter":{"title":"100 Days of Fibonacci - Day 11, Fixed Point","layout":"post","video":false,"comments":false,"date":"2016-10-11","template":"post"},"html":"In this article, we will look into encoding the Fibonacci function using the\nfix-point combinator. This is an interesting function as it can be used\nto implement general recursion in a programming language.
To set a context we first need to discuss some programming language\nfundamentals: In daily speech, programmers are used to programming\nlanguages being express all possible computations. This is, they are\nTuring complete.
\nHowever, often we want a programming language to support various properties.\nSome often discussed properties are\ntype safety, which entails that\nprograms that compile also runs without errors, and\nnormalization, which\nroughly says we always get a result.
\nAn often used framework for reasoning about these properties is the\nsimply typed lambda calculus (STLC) with friends. With the raw STLC,\nit is not possible to encode general recursion. Hence we need to add\na friend, which makes it possible.
\nThis friend could be the fixed point operator.
\nGenerally, the fix operator looks as follow:
In this article we let Haskell be our syntactical point of view. This is\nbecause we then will have an interpreter for free.
\nIn the ghci interpreter we may define the function as follows:
> let fix f = let x = f x in xWe now have a function fix that takes a function as the argument,\napplies it to\nitself and returns the result. If the function we apply fix on returns a\nvalue, then fix will return a value:
> fix (\\rec -> "Hello Fix!")\n"Hello fix!"Next, if we just apply the function on itself we will get an infinite loop:
\n> fix (\\rec -> rec)\n^CInterrupted.Now, this makes sense, as we continuously attempt to apply the lambda function\non itself.
\nIn above example, we only have a single argument, n, which is the function\nitself. We can say that we have the recursion directly in our hands. But to\nbe able to do something interesting, like calculating the i'th Fibonacci\nnumber, we need to add an argument we can decrement on. First a simple\nexample.
> fix (\\rec n -> if n == 0 then 0 else n + rec (n-1)) 10\n55In above example we use the if to return a value when we hit 0, otherwise\nwe apply the function on n-1. The expression simply adds all numbers from\n0 to 10.
From here it is straight forward to implement the Fibonacci function. We need\nto have a nested if-statement, as we have two base cases. Otherwise, it is very\nsimilar to the function above.
\n> let fib = fix (\\rec n -> \n if n == 0 then 0 else if n == 1 then 1 else rec (n-1) + rec (n-2))\n> fib 10\n55This is a directly recursive implementation of the Fibonacci function. This is\nindeed visible from time complexity, and it is not feasible to compute the\nFibonacci number of large numbers. It is indeed possible to augment above\nimplementation with an accumulator.
\nAbove implementation is interesting as we completely separate the recursion\nfrom the actual computation. In\nan earlier article,\nI implemented the function in Haskell using normal function syntax. Here the\ndistinction between the recursion mechanism and the calculating mechanism is\nnot as distinct.
\nThe separation is especially interesting when formally reasoning about\nprogramming languages as we can get clutter away. This, however, is much\neasier when doing this in dedicated languages.
\nAbove examples are kind of futile in Haskell, as it already supports better\nfunctionality for solving the Fibonacci function. It is, however, interesting\nto think about what a minimal language for solving the function would be.\nIn above implementation, we need support for fix, if-then-else, boolean\nconstructions, and natural numbers. This is four language constructions.
Perspective. As in the real world, by looking at a problem from a different\nangle, we can often find solutions much faster.
\nDay 12 is the matrix implementation of the fibonacci sequence.\nA specially constructed matrix has the property of calculating\nthe next element in the sequence upon multiplication with the previous element.
\nImplementing the Fibonacci sequence like this has a rather special side effect:\nIt allows reducing the problem of calculating the Fibonacci sequence to\nmultiplication for which we can utilize knowledge on multiplication and make\nand calculate an element much faster than the iterative approaches.
\nThe matrix looks like this:
\n$$\n Q_{fib} = \\begin{bmatrix}\n 1 & 1 \\\\\n 1 & 0\n \\end{bmatrix}\n$$\nThe nth element of the Fibonacci sequence can then be found by reading either\nthe top-right or bottom-left element of the matric as defined by \\( Q_{fib}^n \\).
\nLet's see an example in Julia
\n❯❯❯ julia\n _\n _ _ _(_)_ | Documentation: https://docs.julialang.org\n (_) | (_) (_) |\n _ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help.\n | | | | | | |/ _` | |\n | | |_| | | | (_| | | Version 1.8.1 (2022-09-06)\n _/ |\\__'_|_|_|\\__'_| | Official https://julialang.org/ release\n|__/ |\n\njulia> Q = [1 1;1 0]\n2×2 Matrix{Int64}:\n 1 1\n 1 0\n\njulia> Q^10\n2×2 Matrix{Int64}:\n 89 55\n 55 34From here it is evident that the 10th element of the fibonacci sequence is 55.
\nAs calculating the n'th element in the Fibonacci sequence is now the same as\ntaking the exponent, we can utilize exponentiation by squaring. This method\nrelies on the insight that \\( b^n = b^{{2}^{n/2}} \\) when n is even - a rule\nthat can be derived from the power of a power rule:
\n$$\nb^{{x}^{y}} = b^{x * y}\n$$\nAs an example we can calculate \\( 2^{10} \\) using the method:
\n$$\n\\begin{align*}\n 2^{10} &= 4^{5} \\quad \\text{(power of power rule)} \\\\\n &= 4 \\times (4^{4}) \\\\\n &= 4 \\times (16^{2}) \\quad \\text{(power of power rule)} \\\\\n &= 4 \\times 256 \\\\\n &= 1024\n\\end{align*}\n$$\nThis algorithm can be implemented in Julia as the following:
\nfunction fast_exp(base, exp)\n result = 1\n while exp > 0\n if exp % 2 == 0\n base *= base\n exp = exp ÷ 2\n else\n result *= base\n exp -= 1\n end\n end\n return result\nendAnd to see how well it works we can make a quick\ncheck on calculating the 100.000 element of the Fibonacci\nsequence.
\n...\njulia> include("fast-exp.jl")\nfast_exp (generic function with 1 method)\n\njulia> Q = [big(1) big(1);big(1) big(0)]\n2×2 Matrix{BigInt}:\n 1 1\n 1 0\n\njulia> @time fast_exp(Q, 100000);\n 0.000767 seconds (703 allocations: 285.633 KiB)\n\njulia> @time naive_exp(Q, 100000);\n 0.723526 seconds (3.10 M allocations: 4.097 GiB, 9.84% gc time)The naive implementation is not the build in, rather the iterative\nimplementation following the naive approach. The code can be found\nhere.
\nKey techniques when developing software is reduction and abstraction. The\nabove is an example of a reduction to an algebraic field that allows us to\nuse multiplication.
\n"},{"url":"/100-days-of-fibonacci-day-3-scala/","relativePath":"100-days-of-fibonacci-day-3-scala.md","relativeDir":"","base":"100-days-of-fibonacci-day-3-scala.md","name":"100-days-of-fibonacci-day-3-scala","frontmatter":{"title":"Day 3, Scala","subtitle":"100 Days of Fibonacci","date":"2015-12-18","template":"post"},"html":"\nComing from yesterdays Java, Scala is a naturally the next step. It is\na functional language compiled to run on the Java Virtual Machine.\nIt integrates easily with Java programs, and as such, it is often used\nin conjunction with Java. Javas API is also available in Scala. This\nmakes it easier for Java developers to start with Scala if they\nwant to dive into functional programming.
\nThis is the 4th day in my little\nchallenge I am carrying\nout as a personal project. The first days elaborated on simple concepts,\nbut later on more complicated concepts such as type level programming, parallel\nprogramming and even more theoretical subjects are explored.
\nToday I present an implementation of Fibonacci in the Continuation Passing\nStyle (CPS). This can easily be done in Scala because of its functional\nnature:
\n// Fibonacci in Contiuation Passing Style\ndef fib_cps (n: Int, k: (Int => Int)) : Int = n match{\n case 0 => k(0)\n case 1 => k(1)\n case _ => fib_cps(n-1, (a: Int) =>\n fib_cps(n-2, (b: Int) =>\n k(a+b)))\n}In this example I have used pattern matching to keep\nit easily readable.\nThe variable k holds the continuation which is evaluated\nin the base cases (case 0 and case 1).
The above code was wrapped to make it compatible to the\nusually type signature of Fibonacci.
\n// An alias to make it satisfy the type signature Int -> Int\ndef fib_cont(n: Int) = fib_cps(n, ((x: Int) => x)) The main function holds a call to above. The whole thing is compiled\nand run on the command line completely as one would expect coming\nfrom Java.
\n$ scalac Fib.scala \n$ scala Fib\n55A little quiz: Guess n such that $fib(n) = 55$ (I have elaborated on this\ntomorrow).
\nThe code can as usually be found on GIT\nhere
\nContinuation Passing Style is not easy to read, and as such it is not a\ngood way\nto implement functions, unless there is a very good reason. These reasons\ncan be applications where explicit management of the control flow is\nnecessary.
\nMany compilers do an implicit conversion from recursive functions to\nfunctions in CPS. A reason is that all computations are wrapped in a\npackage (i.e. the continuation) and is put in the heap which reduces\nmaximum stack size.
\nToday I looked at 2 new things, Scala and Continuation Passing style.
\nScala is a great language for writing functional code that has to\nintegrate with Java projects, or for writing functional code using\nJava libraries.
\nContinuation passing style is a way of programming which can be enormously\nuseful. Especially when writing large project where the control flow has\nto be explicitly managed.
\n"},{"url":"/100-days-of-fibonacci-day-2-java/","relativePath":"100-days-of-fibonacci-day-2-java.md","relativeDir":"","base":"100-days-of-fibonacci-day-2-java.md","name":"100-days-of-fibonacci-day-2-java","frontmatter":{"title":"Day 2, Java","subtitle":"100 Days of Fibonacci","date":"2015-12-17","template":"post"},"html":"In my 100 days of Fibonacci\nproject I have now shown three idioms for implementing algorithms:\nDirect recursion, accumulated recursion, and an iterative\napproach. Today I diving into a technique for optimizing\nfunction with many repetitive calls.
\nMemoization can be added to an already implemented function. When\nused correctly is provides a radical speedup for a little extra\nmemory consumption. This I have showcased in Java on the directly\nrecursive Fibonacci implementation.
\nHere I have implemented Fibonacci in Java using dynamic programming. The\nidea is to check whether the result has already been calculated. If\nit has so, then we return the already calculated the result, otherwise\nwe calculate the result, save it, and return.
\n/**\n * Memoization implementation of the Fibonacci function using hash table\n * as container for memory entries\n */\nprivate static BigInteger fibDynamic(int n, Hashtable<Integer, BigInteger> mem){\n // Check if we have the result\n if(mem.containsKey(new Integer(n)))\n return mem.get(new Integer(n));\n\n // Base cases\n if(n == 0)\n return new BigInteger("0");\n if(n == 1)\n return new BigInteger("1");\n\n // calculate and memoize Fibonacci\n mem.put(new Integer(n), fibDynamic(n-1, mem).add(fibDynamic(n-2, mem)));\n return mem.get(n);\n}To keep the type signature to that of the other implementations, we build an\noverloaded wrapper method, which initializes a hash table, runs the\nrecursive function and returns its result.
\n/**\n * Driver for the dynamic implementation of Fibonacci\n */\nprivate static BigInteger fibDynamic(int n){\n Hashtable<Integer, BigInteger> mem = new Hashtable<Integer, BigInteger>(n+1);\n return fibDynamic(n, mem);\n}The code is as usual available and can be found\non Github.
\nToday I introduced dynamic programming. We have two ways to apply dynamic\nprogramming, either by memoization or tabulation. Memoization is the process\nof remembering intermediate results. This is exactly what I did in the\nearlier example. Here we might cache some results we never use.\nTabulation is the process of pre-calculating a table of intermediate results\nand then afterwards aggregate the result afterwards.
\nDynamic programming can also be seen as a method of reducing the number\nof unfolds. In this example the Fibonacci implementation is called linear\nnumber of times to n. In the direct recursive method, it would\nhave been exponentially in n.
\nJava is one of the top languages used today. It is compiled to an\nintermediate representation, Java byte code, before it is ran on a Java\nvirtual machine. This makes it very portable without sharing the Java\nsource code. Furthermore there is a big body of libraries and articles\nwritten solving various problems in the language.
\nWhen having an enterprise it is certainly also a big plus that\nmost programmers program in Java. It is easy to find people who\nare able to read and write Java code.
\n"},{"url":"/100-days-of-fibonacci-day-4-prolog/","relativePath":"100-days-of-fibonacci-day-4-prolog.md","relativeDir":"","base":"100-days-of-fibonacci-day-4-prolog.md","name":"100-days-of-fibonacci-day-4-prolog","frontmatter":{"title":"Day 4, Prolog","subtitle":"100 Days of Fibonacci","date":"2015-12-19","template":"post"},"html":"Updates:
\nIn my 100 days of Fibonacci\nproject I looked at functional and imperative language. There are however\nmany more programming paradigms today we are going to dive into\none of the most used\nlogic programming languages.
\nProlog is heavily used in the field of artificial intelligence. This is due\nto the natural way of formulating computations in terms of predicates.\nThis allows for concise expression of tree structures that certain data might\nexhibit.
\nIn this blog post, i show how to implement Fibonacci in the directly\nrecursive style. As we will see this gives problems when we want to\nexploit some Prolog features.
\nIn Prolog, I defined a predicate that holds both the argument and the\nresult. A predicate is something that can only be true or false.\nTherefore, the notion of return value is explicit parameters to the\npredicates in Prolog.
\n% Implementation using direct recursion.\nfib_direct(0, 0).\nfib_direct(1, 1).\nfib_direct(N, R) :-\n X1 is N-1,\n X2 is N-2,\n fib_direct(X1, A),\n fib_direct(X2, B),\n R is A + B.In above the base cases are defined as simple predicates. The first argument\nis the nth Fibonacci number and the second is the result.
\nBy writing fib_direct(0, 0). we denote that the predicate predicate\nfib_direct is true when applied 0 for both arguments. In swipl\n(SWI Prolog interpreter) we can write fib_direct(0, X). to make\nit derive the second argument given the first argument.
$ swipl fib.pl \n% fib.pl compiled 0.00 sec, 4 clauses\nWelcome to SWI-Prolog ...\n\nFor help, use ?- help(Topic). or ?- apropos(Word).\n\n?- fib_direct(0, R).\nR = 0 .The third definition of the fib_direct predicate is the one that\nallows us to calculate Fibonacci for arbitrary numbers. We can again\nmake prolog derive the result by supplying N
...\n?- fib_direct(10, R).\nR = 55 .A problem here is that we use the is/2 notation. It enforces evaluation\nof the right side and puts the result in the variable on the left side.\nThis is something we want to avoid in logical programming, as we need the\nright side to be defined. The reason is that we can not choose what to derive anymore.
Yesterday I put up a little challenge to try to figure out where 55 came from.\nThis challenge is ideal to solve in Prolog as we can use the\nsame code to derive what n is for a given Fibonacci number. We would have\ndone something like.
\n?- fib_direct(N, 55).\nERROR: fib_direct/2: Arguments are not sufficiently instantiatedBut as you can see it fails. This is because of the use of is/2.\nThe is-operator does explicit evaluation of the right-hand side\nbefore it check whether it equals the left-hand side.
To remove the use of that operator I have implemented Peano natural\nnumbers and defined what addition is. This allows us to implement\nFibonacci in a purely structural manner.
\nFibonacci is a very simple function that requires 3 constructions:\na data type (natural numbers), data aggregation (addition), and\na way to define the recursive dependencies. That last thing is done\nthrough recursively defined predicates in Prolog.
\n% Definiition of the Peano numbers\nnat(0).\nnat(s(_)).\n\n% Readable nats\nnat_to_int(0, 0).\nnat_to_int(s(N), R) :-\n nat_to_int(N, R1),\n R is R1 + 1.\n\nint_to_nat(0, 0).\nint_to_nat(X, s(R)) :-\n X1 is X-1,\n int_to_nat(X1, R).Above is the data type. The first three lines are somewhat unnecessary\nas Prologs typing discipline is implicit.
\nThe next two block display how we convert between the arithmetic integers\nand the naturals. We use pattern matching an a recursively defined predicate.\nThis construction is quite idiomatic for this problem.
\nNet we have an implementation of addition. Again we use pattern\nmatching in two defined predicates. The first predicate is the\nbase case while the second is the induction case.
\n% Definition of addition ( add(A, B, Result ))\nadd(0, B, B).\nadd(s(A), B, R) :- add(A, s(B), R).To understand what is happening one can think of two stacks of plates\nwhere we move all plates piecewise from the left stack to the right.\nWhen the left stack is empty, we stop and let the right one be the\nresult.
\nThe last part in this implementation is the definition of Fibonacci.\nNote that we implicitly subtract the number by 2 when we match in\nthe induction case. This is necessary as we don't have any functionality\nfor subtracting. General subtraction is not necessary as we only need to\nsubtract by 2. In the body of the predicate we add by 1, to get the subtraction\nof 1.
\nfib_peano(0, 0).\nfib_peano(s(0), s(0)).\nfib_peano(s(s(N)), R) :-\n fib_peano(N, A),\n fib_peano(s(N), B),\n add(A, B, R).\n\n% Wrapper functions dealing with all the conversions\nfib_peano_wrapper_get_res(A, B) :-\n int_to_nat(A, X),\n fib_peano(X, Y),\n nat_to_int(Y, B).\nfib_peano_wrapper_get_arg(A, B) :-\n int_to_nat(B, Y),\n fib_peano(X, Y),\n nat_to_int(X, A).The two last blocks are for reading arithmetic arguments. They simply\nconvert a number to the Peano structure before it run the fib_peano\npredicate. Lastly it converts back to arithmetic integers to make it\neasier to read the output.
First we take a look at how it would look without conversion from integers.\nIt is apparent that it is rather cumbersome to practically work with numbers\nin this format.
\n?- fib_peano(s(s(s(s(s(s(s(s(s(s(0)))))))))), R), nat_to_int(R, X).\nR = s(s(s(s(s(s(s(s(s(s(...)))))))))),\nX = 55 .The last piece of code for this post demonstrates how the wrappers work.\nthe first example simply returns the 10th Fibonacci number.\nThe second example is more interesting. It lets us derive which\nindex the Fibonacci number 55 has.
\n?- fib_peano_wrapper_get_res(10, B).\nB = 55 .\n\n?- fib_peano_wrapper_get_arg(A, 55).\nA = 10 .The last piece of code also solves the puzzle from\nyesterday\nwhere I asked what n is for $fib(n) = 55$.
\nThe time and space complexity is generally not good when using this\nrepresentation. It is usually only used when reasoning about programs,\ni.e. proving different properties about programs. The idea about\nstructuring problems in terms of nothing but predicates is very\nusable, and is indeed one of the reasons why Prolog is widely used.
\nAs usual the files are available on\nGithub.
\nLogic programming has its core in predicates. We define logical\npropositions and make the subsystem derive what we need. This works\nvery well when we work on structures like lists and trees.
\nThe Fibonacci function, however, works on natural numbers which\nwe usually represent as integers for direct translation to\nmachine instructions.
\nAs seen above it was indeed possible to implement naturals structurally.\nOn a more general note, it is actually possible to model all problems in\na structural manner. This is exploited in amongst other languages\nCoq.
\nActually, all problems may be expressed in structures. This we will\nget back to when discussing theorem provers.
\nToday I looked at Prolog. I implemented the Fibonacci function\nin a logic context. We saw that We didn't exploit Prologs ability\nto derive the argument to Fibonacci. To circumvent that, I\nbuilt a structural implementation of natural, using Peano,\nso we didn't have to make an explicit evaluation. This implementation\nhad the ability to derive what number a given Fibonacci number is,\neven though it is not practical.
\n"},{"url":"/100-days-of-fibonacci-day-5-spreadsheet/","relativePath":"100-days-of-fibonacci-day-5-spreadsheet.md","relativeDir":"","base":"100-days-of-fibonacci-day-5-spreadsheet.md","name":"100-days-of-fibonacci-day-5-spreadsheet","frontmatter":{"title":"Day 5, Spreadsheet","subtitle":"100 Days of Fibonacci","date":"2015-12-20","template":"post"},"html":"This is an article in a series of articles. An overview of the entire\nproject can be found here.
\nOver the course of this project, small intermedios will occur.\nToday is one of these. The past days I implemented Fibonacci\nin what is considered \"tradition\" programming languages. They\nhave a formal syntax based on a grammar and an alphabet.
\nToday I am presenting Fibonacci through a tool that many people\nuse on a daily basis. Also, people who do not come out of a\ncomputer science / engineering world.
\nI simply implemented Fibonacci by hard coding two values, 0 and 1, in\ntwo cells. These are the values we earlier on has seen as the base cases.\nThereafter I used the formula =B2+B1 in the third cell. I could then\nsimply drag and drop that cell allowing the spreadsheet to calculate\nthe respective values.
The column left to the Fibonacci column is the index of the corresponding\nFibonacci number.
\nI have written that this method is dynamic programming using tabulation.\nThe reason for this is that I assume this being a pre-calculated table of\nFibonacci numbers. When one has this table she can quickly look up the number\nshe needs for further calculation. There might be other classifications\nof this technique using other reasons.
\nAs usual, the file is in my Fibonacci snippet folder and can be found\nhere.
\nThe main idea with this post is simply to try to broaden up the perception\nof programming. Many people program on a daily basis when they do their\nbudgeting or quickly need to calculate combined costs of some product.
\nProgramming should not be considered foreign, as it isn't. It is something\nwe all do. But more on this idea in a later post.
\nToday I demonstrated a new programming language simply by drag-and-drop.\nThe idea was to broaden up the idea about what programming is. This is not\nthe last time I do so, even though I promise to present some more complex\nconcepts before that.
\n"},{"url":"/100-days-of-fibonacci-day-6-javascript/","relativePath":"100-days-of-fibonacci-day-6-javascript.md","relativeDir":"","base":"100-days-of-fibonacci-day-6-javascript.md","name":"100-days-of-fibonacci-day-6-javascript","frontmatter":{"title":"100 Days of Fibonacci - Day 6, JavaScript","layout":"post","video":false,"comments":false,"date":"2015-12-21","template":"post"},"html":"This is an article in a series of articles. An overview of the entire\nproject can be found here.
\nUntil now I have focused on Fibonacci as a function of some input.\nI have defined a function which returns a value when supplied an argument.\nThis yield a batch processing paradigm. However, the Fibonacci is defined as\na series, and as such it makes sense to treat it as a series.
\nIn this blog post, I am going to treat Fibonacci as an unlimited stream of\nnumbers. To carry out this idea, I am going to use JavaScript. The reason\nfor this is that JavaScript is a well-known programming language and\nbecause their event system is easy to understand. Later I will expand\nthe notion to other languages where the concept is known as streams,\nsignals, coinductive data structures, etc.
\nThe core JavaScript implementation is like the iterative implementation\nI did day 1 in C.\nIt is expanded to directly emit an event carrying the result.
\n// Start dispatching events\nfunction startDispatcher(){\n var a=0;\n var b=1;\n var i=1;\n\n //We never stop the stream\n while(true){\n var tmp = a+b;\n b=a;\n a=tmp\n\n // emit\n emitter.emit('fib', {"fibn" : a, "n":i});\n i++;\n }\n}When this function is called it will emit a new event every time a\nFibonacci number has been calculated. But this does not work by itself. We\nalso need something to consume it. Following is a function that consume the\nevents and prints a . on the screen. When we hit n = 10 we write the\ncorresponding element in the Fibonacci series.
// Listen on the event\nemitter.on("fib" ,function(e){\n // Only write result when n is 10\n if(e.n == 10)\n process.stdout.write("\\n" + e.fibn + "\\n");\n else\n process.stdout.write(".")\n});When running the file through node we get following:
\n$ node fib.js \n.........\n55\n...................................................................................................As usual, the code is available\nhere.
\nJavaScript was initially made as a scripting language for browsers and\nhas gained its popularity for programming user interfaces. With faster\nprocessors and faster implementations of JavaScript the browser has got\nmore responsibility, and JavaScript has been turned into a general purpose\nprogramming language. It has been ported to run on the server (with the\nmost widespread implementation as being \"nodeJS\") and databases. It\nis now possible to develop large distributed applications in nothing but\nJavaScript, which is also done.
\nSo what about the Events? When programming user interfaces the interface\nusually stands still until a button is pressed or an input field is\nfilled. Here the subsystem fires some events whenever something meaningful\nis happening. It is then possible to add functions to be called on these\nevents.
\nThis approach has been in use for a long time. But has certain disadvantages\nwhen working on large systems. It quickly becomes messy when too many events\nare to be handled and dispatched. But certain solutions already do exists.\nLater on, we will take a look at Elm, Here we model the complete application\nand let the system handle what part of the web page is updated. And don't\nmatter. It is fast.
\nÍ have introduced the notion of events which are going to support our\nunderstanding of streams and signals for reactive programming later on.\nThis I have done in JavaScript which has turned into a general purpose\nprogramming language primarily for full stack web development.
\n"},{"url":"/100-days-of-fibonacci-day-8-r/","relativePath":"100-days-of-fibonacci-day-8-r.md","relativeDir":"","base":"100-days-of-fibonacci-day-8-r.md","name":"100-days-of-fibonacci-day-8-r","frontmatter":{"title":"100 Days of Fibonacci - Day 8, R","layout":"post","video":false,"comments":false,"date":"2016-01-11","template":"post"},"html":"I looked at quite some\ndifferent approaches to the Fibonacci function,\nand I start to wonder how the Fibonacci number develops with respect\nto its index. To look into this I want to make a 2D plot where the X-axis is\nthe natural numbers and the Y-axis is the corresponding Fibonacci numbers.
\nTo solve this problem I decided to use R. This is less of an obvious\nsolution. Usually one would probably have gone for a spreadsheet, but\nalready did that.
\nR is a good tool for doing numeric analysis and prototyping algorithms\nfor machine learning. For that it provides good tools for visualizing\ndata. This is what I am going to elaborate a bit on here.
\nUsually I would have started implementing Fibonacci as a recursive\nfunction. This was also my first approach and it is certainly\npossible. It is, however, not the idiomatic way. R is an array oriented\nlanguage and as such we work on arrays. Under this paradigm it is better\nto initialize an array, and then populate it with its elements.
\nThe implementation takes offset in a function that takes n as\ninput and returns a list of the n first Fibonacci numbers.
\nfibList <- function(n){\n theList <- numeric(n)\n theList[1] <- 1\n theList[2] <- 1\n for (i in 3:n) {\n theList[i] <- theList[i-1] + theList[i-2]\n }\n return(theList);\n}\n\n# Calling the function\nfibList(10)\nfibList(20)\nfibList(100)It was run using the Rscript command
mads@mads:fibonacci$ Rscript fib.R \n [1] 1 1 2 3 5 8 13 21 34 55\n [1] 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610\n[16] 987 1597 2584 4181 6765\n [1] 1.000000e+00 1.000000e+00 2.000000e+00 3.000000e+00 5.000000e+00\n [6] 8.000000e+00 1.300000e+01 2.100000e+01 3.400000e+01 5.500000e+01\n [11] 8.900000e+01 1.440000e+02 2.330000e+02 3.770000e+02 6.100000e+02\n [16] 9.870000e+02 1.597000e+03 2.584000e+03 4.181000e+03 6.765000e+03\n [21] 1.094600e+04 1.771100e+04 2.865700e+04 4.636800e+04 7.502500e+04\n [26] 1.213930e+05 1.964180e+05 3.178110e+05 5.142290e+05 8.320400e+05\n [31] 1.346269e+06 2.178309e+06 3.524578e+06 5.702887e+06 9.227465e+06\n [36] 1.493035e+07 2.415782e+07 3.908817e+07 6.324599e+07 1.023342e+08\n [41] 1.655801e+08 2.679143e+08 4.334944e+08 7.014087e+08 1.134903e+09\n [46] 1.836312e+09 2.971215e+09 4.807527e+09 7.778742e+09 1.258627e+10\n [51] 2.036501e+10 3.295128e+10 5.331629e+10 8.626757e+10 1.395839e+11\n [56] 2.258514e+11 3.654353e+11 5.912867e+11 9.567220e+11 1.548009e+12\n [61] 2.504731e+12 4.052740e+12 6.557470e+12 1.061021e+13 1.716768e+13\n [66] 2.777789e+13 4.494557e+13 7.272346e+13 1.176690e+14 1.903925e+14\n [71] 3.080615e+14 4.984540e+14 8.065155e+14 1.304970e+15 2.111485e+15\n [76] 3.416455e+15 5.527940e+15 8.944394e+15 1.447233e+16 2.341673e+16\n [81] 3.788906e+16 6.130579e+16 9.919485e+16 1.605006e+17 2.596955e+17\n [86] 4.201961e+17 6.798916e+17 1.100088e+18 1.779979e+18 2.880067e+18\n [91] 4.660047e+18 7.540114e+18 1.220016e+19 1.974027e+19 3.194043e+19\n [96] 5.168071e+19 8.362114e+19 1.353019e+20 2.189230e+20 3.542248e+20When the number is large enough R converts the list into floating point\nnumbers. This conversion is mostly OK when working with probabilities, but\ncan be fatal when we need the exact result. In above example the last element\nhas been cropped. R reports 354224800000000000000 while the 100th\nnumber is 354224848179261915075.
The type conversion does not matter when visualizing. It won't even mean a\npixel when plotted on the screen, so we will continue on and try to visualize\nthe relationship between $n$ and $fib(n)$.
\n![\"100](\"/images/r-fib.png\")
The relationship looks much like an exponential development. This, however,\nis a subject for a later article.
\nI implemented the recursive edition of the Fibonacci algorithm in R. This\nalgorithm is efficient, and R provides efficient subroutines for handling\nthe array.
\nAfter the implementation a simple plot of the relationship between $n$ and\n$fib(n)$ was plotted. This was easily done in R, as R provides good\nabstractions for this.
\n"},{"url":"/100-days-of-fibonacci-day-7-coq/","relativePath":"100-days-of-fibonacci-day-7-coq.md","relativeDir":"","base":"100-days-of-fibonacci-day-7-coq.md","name":"100-days-of-fibonacci-day-7-coq","frontmatter":{"title":"100 Days of Fibonacci - Day 7, Coq","author":"Mads Buch","date":"2016-01-04","template":"post"},"html":"I have been of a couple of days over the Christmas and New Year.\nBut now it is time to start my\n100 days of Fibonacci\nproject again.
\nToday I chose Coq and I decided to look at proving properties about\nprograms. The key idea in this post is to prove that two different\nimplementations of the Fibonacci function indeed are equivalent.\nConcretely I have chosen the direct recursive and the accumulated\nrecursive implementations as the subjects.
\nThese implementations are the same\nas in the first article.\nThis is done deliberately as they are idiomatic to functional programming.\nFurthermore, they showcase quite well why this has a value. The directly\nrecursive implementation is easy to understand and stays close to both\nthe definition of Fibonacci and the common understanding of the function.\nOn the other hand, the recursive function with the accumulator is harder\nto understand but provides a significant speedup.
\nIn this article, I show that the rest of the program can be indifferent\nto which implementation is in use. This is done by proving theorems, which\nis considerably more time consuming that providing tests. The effort returns\nin favor the strongest guarantee we can have for the property, a mathematical\nproof.
\nAs mentioned the two implementations are the directly recursive and\nthe recursive with accumulation. These are both implementations we have\nseen before.\nBut we use them again as they provide a good body for\nshowcasing proving program equivalence. Next we have the two implementations.
\nFixpoint fib_direct (n : nat) : nat :=\n match n with\n | 0 => 0\n | S n' => match n' with\n | 0 => 1\n | S n'' => fib_direct n' + fib_direct n''\n end\n end.Above is the directly recursive implementation and next is the\naccumulated recursive implementation.
\nFixpoint fib_accumulator (n : nat) (a : nat) (b : nat) : nat :=\n match n with\n | 0 => b\n | (S n') => fib_accumulator n' (a+b) a\n end.\n(* An alias to scrape away unnecessary information *)\nDefinition fib_acc (n : nat) := fib_accumulator n 1 0.The results can be calculated by the Compute command. It is\nhereafter visible in the *goals* window (Assuming you use the\nproof assistant).
Compute fib_direct 10.\nCompute fib_acc 10.A couple of things look a bit different. The function signature looks\nkind of weird. Furthermore, we are doing some kind of match stuff with\nsomething that looks a bit like numbers.
\nIn the function signature, we use the Fixpoint to denote a recursive\nfunction. This is because Coq encodes recursion in its type and\nimplement what's called iso-recursion.
For integers, Coq does not use the regular atomic data types we know from\nex. Java. Instead, it has (and only has) inductive data types. In these\nPeano naturals has\nbeen implemented. This means that zero is represented as O, one\nas S O, two as S (S O) and so forth (this does not implement integers\nbut only naturals which is just fine for Fibonacci).
Coq automatically expands syntactic decimal numbers to its\ninternal representation. Hence\n5 is just syntactic sugar for S S S S S O.\nThis is the same representation I\nimplemented in Prolog earlier on.
As usual, the code is available on\nGithub.
\nIt is necessary to be able to reduce data to atomic pieces to do the proving\nwe want to do. This is to create a total dependency between the type and its\nvalue. Imagine Java's int type. This type holds, at least,\n$2^{32}$ different\nvalues without the compiler knowing which. In that case, it is not possible to\nreason about the return value of a function, which we need for the next\nsection.
Coq is not meant as a general-purpose programming language. In fact, it is\na proof assistant. This means that it is not possible to interact with\nthe surrounding world. It is not possible to read command line arguments or\ninvoke system calls. On the other hand, Coq can prove properties.
\nIn the above we had two different implementations of the Fibonacci\nfunction. One might wonder whether these functions always return the same\nvalue. That is, does fib_direct 10 and fib_acc 10 yield the same result?\nThis can easily be checked by running the code. The problem is when we\nwant to check for all values of n. Is it true that\nfib_direct n = fib_acc n? This we can actually prove in Coq, and\nso I have done.
The first step I took to prove equivalence of the implementations was to\ncharacterize the Fibonacci function.
\nDefinition specification_of_fibonacci (f : nat -> nat) :=\n f 0 = 0\n /\\\n f 1 = 1\n /\\\n forall n : nat,\n f (S (S n)) = f (S n) + f n.This is, in fact, a proposition. Is is true if we have a function that behaves\nas the specification. This specification is very close to the directly\nrecursive implementation.
\nThe next thing is to prove that this definition is unambiguous. This means\nthat f will behave identical independent to the actual implementation. In\nCoq this looks like following (The whole code is available on\nGithub).
\nLemma there_is_only_one_fib :\n forall f1 f2 : nat -> nat,\n specification_of_fibonacci f1 ->\n specification_of_fibonacci f2 ->\n forall n : nat,\n f1 n = f2 n.\nProof.\n unfold specification_of_fibonacci.\n intros f1 f2.\n intros [ bc_f1_0 [ bc_f1_1 ic_f1 ] ]. (* Destruct the conjunctive clauses *)\n intros [ bc_f2_0 [ bc_f2_1 ic_f2 ] ].\n \n (* strengthening the induction hypothesis *)\n assert (H_fib : forall m : nat,\n f1 m = f2 m /\\ f1 (S m) = f2 (S m)).\n intro m.\n ...\n apply hf.\nQed.What happens above is that we specify a lemma. Given two functions, that\nboth satisfies the specification of the Fibonacci function, they yield the\nsame result for all values of n.
\nAfter the specification of the lemma, we provide an actual proof. this is a\nseries of commands that generates a function which in turn satisfies the type\nof the lemma. This process is somewhat out of scope, and I will look into this\nin another post.
\nAfter this, all we need to do is to prove that both the implementations indeed\nsatisfies the specification. Hereafter we can use the property that there is\nonly one Fibonacci function to prove the equivalence.
\nLemma fib_direct_satisfies_specification :\n specification_of_fibonacci fib_direct.\nProof.\n...\nQed.\n\nLemma fib_acc_satisfies_specification :\n specification_of_fibonacci fib_acc.\nProof.\n...\nQed.And the proof that they are equivalent
\nTheorem fib_direct_is_equivalent_to_fib_acc :\n forall n: nat,\n fib_acc n = fib_direct n.\nProof.\n intros n.\n rewrite (there_is_only_one_fib fib_acc \n fib_direct \n fib_acc_satisfies_specification\n fib_direct_satisfies_specification).\n reflexivity.\nQed.The signature of there_is_only_one_fib was given above. We\nspecialize it with the arguments so we can rewrite our goal.\nThe goal is then rewritten with forall n, fib_acc n = fib_direct n.\nThis yields a goal which is trivially true. Namely\nfib_direct n = fib_direct n.
We are now sure that for any n we can provide to the directly recursive\nimplementation of Fibonacci, the other implementation yields the same\nresult.
\nIn this post, I implemented the Fibonacci function in the same way\nas in the first article.\nThese are idiomatic to functional programming and as such it makes sense\nto keep using them here.
\nThey key concept introduced here is the notion of proving propositions.\nI proved that the two implementations indeed behave identically. We have\nscratched the surface when it comes to the underlying theory. But\nalready saw the fruits of the efforts: The direct implementation is slow\nbut easy to understand. The other implementation is faster but slightly more\ncomplicated. We have used this to prove that they always return the same\nvalue for the same input.
\n"},{"url":"/100-days-of-fibonacci/","relativePath":"100-days-of-fibonacci.md","relativeDir":"","base":"100-days-of-fibonacci.md","name":"100-days-of-fibonacci","frontmatter":{"title":"100 Days of Fibonacci","subtitle":"Fibonacci in a lot of different ways","img_path":"images/about.webp","template":"page"},"html":"As a small project for rainy sundays I am implementing a function to\ncalculate the fibonacci sequence in various languages. The problem in itself\nis not too interesting and therefore provides a perfect vessel to look at some\npeculiarities about programming languages.
\nHaskell has a flexible type system. It actually is Turing complete\ngiven the right language extensions. This also means that we can do\narbitrary computations, which we are going to exploit in this 10th\nday in my 100 days of Fibonacci\nchallenge.
\nI already did look at Haskell.\nSo strictly speaking I should choose another language.\nHowever, I find that programming in Haskell's type system is different\nenough that I will consider it a different language.
\nToday I implemented Fibonacci in the Haskell type system. That means that I\ncan get the Haskell compiler to generate a type for the n'th\nFibonacci number.
\nI first created a datatype for representing naturals.\nThe approach as in the last part of the\nProlog implementation and\nuse used in Coq was used.\nThis representation\nbuilds on the Peano axioms\nand is straight forward to implement.
\ndata Nat = Z | S NatThis datatype is usable as a kind\nbecause we use the language extension DataKinds. A kind can be\nthought of as a type of a type.
\nIn ghci we can inspect the kind of the type constructor Z by issuing\n:kind Z. The result returned is Z :: Nat.
Next I implemented addition. In Haskell we use the\nlanguage extension TypeFamilies to have a mechanism for implementing\ntype level functions.
\ntype family Add (a :: Nat) (b :: Nat) :: Nat\ntype instance Add Z b = b\ntype instance Add (S a) b = S (Add a b)Again we can try to inspect the kind of the type level function:\n:kind Add (S Z) (S Z) which yields Add (S Z) (S Z) :: Nat as\nexpected.
To actually calculate the Fibonacci type we need Haskell to reduce the Add\nexpression. This is done using the :kind! Add (S Z) (S Z) operation.
*FibType> :kind! Add (S Z) (S Z)\nAdd (S Z) (S Z) :: Nat\n= 'S ('S 'Z)We can now both define type level datatypes (kinds) and do operations on these.\nAlong this line I implemented Fibonacci straight forward in direct recursion.
\ntype family Fibonacci (n :: Nat) :: Nat\ntype instance Fibonacci Z = Z\ntype instance Fibonacci (S Z) = (S Z)\ntype instance Fibonacci (S (S n)) = Add (Fibonacci n) (Fibonacci (S n))To implement above type family I had to add the language extension\nUndecidableInstances. This is because of the use of the Add type\nfamily in the Fibonacci type family.
In this example, however, it is easy to see that the type family will\nalways converge. Add converges (and does not need\nUndecidableInstances) and Fibonacci converges as the arguments\nto the recursive applications are decreasing.
The last thing is to actually calculate Fibonacci. This can be done by\nissuing the :kind! as earlier on and read the result. The returned\nvalue is not easily readable but it is 13 as expected.
$ ghci FibType.hs -XDataKinds\n...\n*FibType> :kind! Fibonacci (S (S (S (S (S (S (S Z)))))))\nFibonacci (S (S (S (S (S (S (S Z))))))) :: Nat\n= 'S ('S ('S ('S ('S ('S ('S ('S ('S ('S ('S ('S ('S 'Z))))))))))))The code is as usual available on\nGithub.
\nTypes alone does, however, not make a program. We need some kind of value\nlevel implementation. In the next section I make a similar implementation\nof the type level functions on the value level. Coupling the type and the\nvalue in an one-to-one correspondence yields\ndependent programming
\nDependent types are used to statically reason about programs and\nput up guarantees that can be checked on compile time.\nIn this case we can set up the guarantee\nthat the code actually calculates the n'th Fibonacci number.
\nWith dependent typing the type of a term depends on its value. In\nHaskell we can benefit from making some parts of the types dependent.\nThis could for example be statically sized lists to make\nmatrix operations type-safe.
\nIn this post I implement complete dependency between terms and their type.\nThe type for the Fibonacci term was implemented above. Now we just need to\nwrite some code that couples it to the value level.
\nFirst we couple the datatype. I implemented a value level datatype,\nSNat, which embeds its size.
data SNat (a :: Nat) where\n SZ :: SNat Z\n SS :: SNat n -> SNat (S n)In the above the value level constructor has the type SNat Z. From\nthis type alone, we can read that it is the zero element.
The successor value constructor has the type SNat n -> SNat (S n).\nHere the type is constructed depending on which number element we\nconstruct.
An important property of above datatype is the bijection between\na datatype and its type. This is what we use to statically reason about\nour programs and make sure certain guarantees are held.
\nAfter that we implement the addition function
\nadd :: SNat m -> SNat n -> SNat (Add m n)\nadd SZ b = b\nadd (SS a) b = SS (add a b) The value level add function stays completely true to the type-level\nadd function and is together with the Fibonacci function below fairly\nself explanatory.
\nfibonacci :: SNat n -> SNat (Fibonacci n)\nfibonacci SZ = SZ\nfibonacci (SS SZ) = (SS SZ)\nfibonacci (SS (SS n)) = add (fibonacci n) (fibonacci (SS n))We now build a Fibonacci function where the returned value is bijective\nto its type. Hence we are sure that what is computed at runtime is something\nwe can predict on compile time.
\n$ ghci -XDataKinds FibType.hs \n...\n*FibType> let f = fibonacci $ SS $ SS $ SS $ SS $ SS $ SS $ SS $ SZ\n*FibType> :t f\nf :: SNat\n ('S ('S ('S ('S ('S ('S ('S ('S ('S ('S ('S ('S ('S 'Z)))))))))))))\n*FibType> f\n13As expected the type of the term fibonacci 7 has the type 13 (translated\nfrom the unary representation to decimal). After evaluating the term we also\nget the value 13.
\nAll above is perfectly good. But why bother writing so much more code\nto just have a dependency between the value and its type? Well, for most\napplications this is not necessary, but the technique can be used to set\nstrict guarantees in certain situations.
\nWhen you know the shape of the data-types on compile-time it can be\nadvantageous to model this shape into the program. This could be\nsome uses of matrices.
\nWhen implementing for example neural networks, the upper bound on\nthe topology is usually known when writing the code. In this case\none could use type safe matrix libraries to implement this functionality.
\nIn this post I first implemented the Fibonacci function on the type level.\nI made a type for the n'th element in the Fibonacci series. This was\ndone through data kinds and type families.
\nAfter this a value level implementation was implemented. It was implemented\nin such a way that its type was bijective to its return value.
\nThe dependency between the terms and the types was carried out through\nGADTs which allows us to encode the type level natural in the types for\nthe values.
\n"},{"url":"/about/","relativePath":"about.md","relativeDir":"","base":"about.md","name":"about","frontmatter":{"title":"About","subtitle":"Rather do it than not","img_path":"images/about.webp","template":"page","indexOrder":1},"html":"Mads Buch is a Computer Scientist. Since\ngraduating his Ms. Science in Computer Science\nform Aarhus University he has\nworked with a variety af companies and developed his skills as a software\nengineer.
\nFor any inquiries contact me on me [@] madsbuch [.] com. Project portfolio\navailable here.
Software developers want to make abstractions, and understandably! It is an intellectual effort to do so, and a craft to elegantly implement. The reasoning behind the abstractions is to make life easier for other software developers – an admirable goal. But there are some things we tend to forget in this process as software developers.
\nThe first thing is that learning abstraction is like learning a new language. Programming languages by themselves are abstractions that are composed. Creating components, functions, classes, etc. can be seen as a means of extending this programming language. They ought to be learned, and in teams, it is a real effort to disseminate and align the use of abstraction.
\nThe next is that some abstractions do not scale with future use cases. An example could be to make a modal overlay that insists on getting a title, a dismiss callback, and a confirm callback as parameters. When writing it, it might seem like a good idea but becomes detrimental the second a developer is making a modal that does not fit that specification. One that does not require the confirm button. Instead, the modal should do only one thing – the modal, and take the entire contents as a child trusting the user of the component to be able to implement the design spec.
\nThe third, and potentially most important, is that abstractions rarely embrace the way we add features, patch bugs, or generally change a codebase. When a developer sees an error on, eg. a website, the first step is to locate the error in the code. One was is to find some text close to the error and search through the codebase for an exact match. This is incredibly effective when the buggy code is also close to the found match. But when layers upon layers of abstractions are applied, it can quite some time locate the buggy code. Finding out that the code is re-used in 3 other places in the codebase can make it virtually impossible to fix without the risk of breaking the code in other places.
\nAll this is not to say that we should not abstract. It is just to say, that we need to be careful when doing so. A good place to start is abstraction elements that have broad consensus. It is like writing an article. One is free to make up their own sections, but following the consensus of abstract, introduction, discussion, related works, conclusion just makes it easy for people to read.
\nUsing well-known abstractions like models, views, services, components, and the like for specific frameworks equally makes things easier. And then, when in doubt, do not abstract, don’t be shy of repeating yourself, and equally don’t shy of refactoring when the right abstraction immerges.
\nAnd lastly, we should embrace the way we know that developers are changing the codebase, not the way we want them to change it. Developers seldomly have context on the entire code base, and as such, we should not create too great of an abstraction distance from the place bugs are realized to the place they are implemented.
\n"},{"url":"/adversarial-statistics/","relativePath":"adversarial-statistics.md","relativeDir":"","base":"adversarial-statistics.md","name":"adversarial-statistics","frontmatter":{"title":"Adversarial Statistics","author":"Mads Buch","date":"2021-03-10","template":"post","excerpt":"Let an adversary add realistic data to your analysis to see if it is resilient."},"html":"Main point: Let an adversary add realistic data to your analysis to see if it is resilient.
\nAt the heart of statistics is the desire to make what we could call question\n/ answer equilibrium. The question has a sound relation to that answer via\nthe observation. The observations should ideally be monotonically increasing\nbut ever true and the question / answer congruence should be resilient to\nadditions to the data. This requires us to be careful about the questions\nin particular and sometimes we need to amend the question to make the answer\nmore resilient.
\nImagine a question like \"what is the life expectancy\". We can calculate that by\ntaking the mean of all ages of all deceased people we have registered and report\nthat as the answer. However, this is not resilient as new data might alter\nthe answer because people get older. To mitigate this we can reiterate on the\nquestion and ask \"what is the life expectancy in 2020\" which would have the\nresilience to new data.
\nA formal method is to apply an adversarial model to statistics. To do this\nwe make a system where we can prove that the addition of new data will\nchange the question / answer relation. A such formalism can be based on typed\ngraphs where we model all that entities and their relations. We prove that\nadding new entities will not change already published results.
\nWe can imagine a system that has the following entities:\nPerson, Country, Year. These entities can be linked by\nPerson -- livesIn --> Country, Person -- deceasedIn --> Year. An example\ndataset to adhere to that ontology could be laid out as follows
![\"deceased.png\"](\"/images/deceased.png\")
To answer questions in the above-pictured dataset we can use the Monte Carlo simulation technique.\nFor the first question, \"what is the life expectancy,\" we draw a deceased person\n10.000 times and average their ages. To answer the other question,\n\"what is the life expectancy in 2020\" we draw a person that has a deceasedIn\nrelation to 2020 10.000 times and average over their ages.
For each of the questions, we invite the meanest adversary we know and allow her to\nput in new entities with one rule: The entities are realistic. Ie. as we are in\n2021 now it is not possible to add more people deceased in 2020. The adversary\nquickly figures out that she can merely decease one of the still-alive people\nto change the answer to the first question. However, for the second question\nno new relations within the specified scope would
\nThe above network would obviously be wildly bigger in reality and also include\nmany more classes of data. Data might be gathered from several different data\nsources which can be modeled using multi-layer networks. Furthermore,\nWhen communicating in real life one should also take\ncontext into account. Ie. If we ask \"what is the life expectancy\" it can\nreasonably be assumed that it is in the year 2020 (and not eg. 1820).
\nI am currently building Fog that is a Haskell\nlibrary to experiment with formalisms for skeptic reasoning. If you are\nalso curious about this field and want to talk, please reach out!
\n"},{"url":"/analyst-book-exploring-data/","relativePath":"analyst-book-exploring-data.md","relativeDir":"","base":"analyst-book-exploring-data.md","name":"analyst-book-exploring-data","frontmatter":{"title":"Analyst Book - Exploring Data","subtitle":"Using an AI platform to understand","img_path":"images/data.png","template":"page"},"html":"This document is a working document using the /data-ai to understand\nfraud patterns and build systems to find these patterns at scale. In contrary\nto previous ways to think about this, we assume no hypothesis in these workflows.
\nWe use a three-step approach to investigate this type of data: Inspect,\nstatistics, predict.
\n"},{"url":"/ai-tools/","relativePath":"ai-tools.md","relativeDir":"","base":"ai-tools.md","name":"ai-tools","frontmatter":{"title":"Thoughts on AI Tools","author":"Mads Buch","date":"2021-05-08","template":"post","excerpt":"AI is hot stuff and many tools are marketed as AI tools. But what is an AI tool and how does it differentiate from a non-AI tools?"},"html":"AI is hot stuff and many tools are marketed as AI tools. But what is an AI tool\nand how does it differentiate from a non-AI tool?
\nIntervention.
\nIntervention is the key differentiator. When developing intelligent tools, the\ninteraction should be intervention - it is, after all, intelligent. Just like\nwe delegate tasks to intelligent beings with the assumption that the person\nis capable, only to intervene when things go wrong.
\nLet's take an example: A system to assist with accounting. The non-AI system\nlets users enter accounts for settlement, potentially recommending accounts.\nThe AI system settles accounts with a key belief that it is done correctly.\nThe user can, however, intervene when the result seems of and let the system\nknow how the correct settlement. The system should be transparent about its\nplanning and easily let the user correct settlements.
\n"},{"url":"/a-practical-introduction-to-haskell-part-1/","relativePath":"a-practical-introduction-to-haskell-part-1.md","relativeDir":"","base":"a-practical-introduction-to-haskell-part-1.md","name":"a-practical-introduction-to-haskell-part-1","frontmatter":{"title":"A Practical Introduction to Haskell, Part 1","author":"Mads Buch","date":"2016-04-08","template":"post"},"html":"\nThis post series provides an introduction to Haskell through a\npractical example. It\nassumes no prior use of the language or functional programming experience.\nA basic understanding of programming, knowledge of using the terminal in Linux,\nand knowing how to install the software is, however, expected.
\n\nThis tutorial will walk you through setting up the environment using\nHaskell Stack, initializing projects, writing\ncode, interactively run it, test it, and build / deploy it.
\n\nAs a body of this investigation we are going to develop a little\ninterpreter. We will be able to do addition, multiplication, subtraction,\nand division on floating point numbers. Interpreters and compilers\noften made in functional programming languages as the paradigm provides\ngood tools for working with the structure.
\n\nA lot of material is presented in this talk. The core elements are as\nfollows:
\nIn the next (still unpublished) articles we will cover the rest:
\nEverything will be brief, but luckily it is greatly documented.\nSo after reading this, if you want to go further, give it away\nand search the Internet!
\n\"I already know Java and it provides a well paying job. Why bother\nspending time on this?\"
\n\nIt shall not be a secret: There exists many paradigms and even more\nways to solve problems (This is evident from my\n100 days of Fibonacci\nchallenge). None of these methods are right or wrong, but some fit better\nin given situations than others.
\n\nMy proposition is that people in general become better problem\nsolvers / programmers by having multiple perspectives on the problem.\nThis is a key assumption for this presentation and can indeed be opposed.\nThis is, however, out of scope.
\n\nFunctional programming is one of the key paradigms. The key benefits of\nfunctional programming are the inherent tools for securing code correctness\nand very good tools for architecting applications.\nThis comes from the use of types. It is furthermore extremely flexible from\nnatural use of higher order functions. This allows to build powerful\nabstractions that are type safe and still intuitive to use.
\nHaskell is a general purpose programming language based in pure\nfunctional programming. By general purpose it is understood that no\nspecific domains of problems, or industries, are targeted rather than\nothers. This is evident from its use in everything from webframeworks\nto embedded software development for micro processors and high\nperformance scientific computing.
\n\nHaskell has mechanism for making embedded domain specific languages\n(EDSL) to target certain tasks. This adds to its flexibility as we\nare able to modify the language syntax to accommodate our needs. This\nis useful if one wants to make a framework for a certain industry or\nclass of problems.
\n\nThe Haskell repositories are also well equipped. We are going to use\nStackage as we use Stack. Otherwise community packages are usually pulled\nfrom Hackage.
\n\nthe Haskell ecosystem is being heavily developed at the moment.\nEspecially the tool chain for writing, testing, and deploying code.\nIn this post we take offset in Stack. It is a large integrated\ntool which depends on the already wide spread cabal. But enough\ntalking. The first thing to get started is to set up the environment\nand get a hold on the first couple of commands.
\nAs mentioned we use Stack to manage our environment. Stack\nautomatically downloads and sets up the\nright compiler, builds, tests, and makes documentation for the project.\nIt is also capable of deploying using docker and much more.
\n\nStack can be installed on all major platform. Instructions are available\non the\nwebsite.
\nHaving Stack setup we can know create our project. This is done by the\nsubcommand new.
$ stack new awesomepreter\nDownloading template ...\n...Stack creates a new folder, awesomepreter, and populates it\nwith boilerplate code and folders.
After the project was created we are going to make Stack download and setup\nthe compilers we need. This is done by cd-ing into the directory and run the sub command setup.
$ cd awesomepreter\n awesomepreter$ stack setupWe can now run the interpreter, stack ghci, and test, stack test. These\nare the only two commands we are using for now.
We furthermore have 3 folders in the newly created project root.
\napp: Contains all code related to the execution. This usually includes\ncode for controlling program flow, reading arguments etc.src: This folder contains all the business logic.test: All our tests are placed in this folder.We use packages in order to leverage on the work of other talented people.\nNobody want to reinvent the deep plate, so we use others inventions.\nFurthermore package systems are also used to organize the code we write.\nFor this organizations might setup their own package management systems.
\n\nFor this project we only use a few packages in order to test our code.\nWe use HUnit and some supporting packages.
\n\nThe packages we need are added by including following in the\nawesomepreter.cabal file. It has to be added to build-depends under the\ntest-suite awesomepreter-test section as it is where we use it.
, HUnit\n , testpack\n , test-framework\n , test-framework-hunitFor the changes to apply to our project we need to ask stack to solve\ndependencies. This is a rather easy process done with a single command.
\n awesomepreter$ stack solver --update-configFrom here the packages are available in our test part of the project. But\nbefore we will start using these packages we will start implementing the\ninterpreter.
\nNow the environment is set up for our purposes, and we will return to some\nsome programming discussing. For this section we will turn our attention\non the src folder, which contains the primary part of our program.
First thing: A bit of cleanup. In the file src/Lib.hs we remove the\nstring (someFunc) from the beginning so it says module Lib where.\nThis is because we don't want to consider the module system at present\ntime.
We can now continue on with the project: We wanted to build an interpreter\nthat interprets expressions like 2 + 5 and 3 + 7 / 8. To do this\nwe consider\nhow to model the problem, and how evaluate instances of that model to a\nresult. In functional programming we model such things in algebraic\ndatatypes (ADT) and implement the evaluation as functions on that datatype.
In this project we see an ADT as a construction which takes an operation\n(the constructor) and some associated data. For the above example, 2 + 5,\nthe operation is addition and the data is 2 and 5. Hence we make an addition\nconstructor taking the two number: Add 2 5.
Above is not the whole story as we need to satisfy out types. We want to\nbe able to build nested expressions, something like Add 2 (Add 2 3). But\nas the number, 2 and 3, have the type Int and Add has some other type this\nis not possible. To get around this we make a constructor which just hold\nthe number: Lit 4. This is also an inhabitant of the same type as Add.
Haskell has ADTs through the data construction. Such a thing consists\nof a type deceleration and a number of constructors each with some\nassociated data.
We implement this in the src/Lib.hs file. First we change the module\nsignature to module Lib where and then we append the following lines\nof code to the file.
data ALang =\n Lit Float\n | Add ALang ALang\n | Mul ALang ALang\n | Sub ALang ALang\n | Div ALang ALang\n deriving ShowThen open the interpreter by issuing stack ghci from the project root.
After a bit of compiling a prompt should be visible and ready to take input
\nawesomepreter$ stack ghci\n...\nOk, modules loaded: Lib, Main.\n*Main Lib> Here we can write Lit 42 for which we will see the evaluated result\nLit 42.0. Haskell did automatic conversion to floats, hence the trailing\n0.
The deriving Show we added in the end of the declaration makes Haskell\nfigure out how to show instances of this data type itself.
\nTo perform the actual interpretation of the expression we need to implement\na function. We want a function that takes an expression as input, and emits\nthe result as output.
\n\nThe first construction we hit when defining functions for algebraic\ndatatypes is pattern matching.
\nawesomepret (Lit x) = xPattern matching is used to two things: Unpacking datatypes and making\nspecialized functions for each case in the datatype, and providing a way\nto unpack data from constructors. The above\ncase is the simplest case, where we simply remove the constructor\nand return the contents.
\n\nIn pure functional programming recursion is how we provide iteration.\nWhere we are normally used to have a language construction to provide this\nfunctionality, we here implement it on our value-level functions
\nThe this case we have a concrete tree. Each node is an operation and\nthe leaves are literals. By recursion we aggregate this tree\ninto a single value by using the build-in\noperations form Haskell.
\nawesomepret (Add a b) = (awesomepret a) + (awesomepret b)Th make the expressions easier to use, we can use a let .. in .. expression\nto make intermediate values. This makes big expressions easier to read and\nwrite.
\nawesomepret (Mul a b) = let\n ae = awesomepret a\n be = awesomepret b\n in\n ae * beThis naturally leads to the where-expression. For our purpose this\nis also an organizational tool. It makes the code easier to read.
\nawesomepret (Sub a b) = ae - be\n where\n ae = awesomepret a\n be = awesomepret bOften we need to do something different based on the value of a variable.\nIn this case we need to check if we divide by 0, and throw an exception if\nwe do so. In Haskell we can use guards for this. This is strictly more elegant than in-lining an if-then-else expression.
\nIn our case we don't want to allow devision by 0:
\nawesomepret (Div a b)\n | (awesomepret b) == 0 = error "Division by 0"\n | otherwise = (awesomepret a) / (awesomepret b) We now have a working interpreter we can use from the Haskell REPL.
\nawesomepreter$ stack ghci \n...\n*Main Lib> awesomepret (Add (Lit 5) (Lit 2))\n7.0We now have a working piece of code, and we can try to dissect it to\nfigure out how we reasoned to get to this result.
\nThe data we worked on was organized as a tree. In pure functional programming\neverything are trees. Even the program we express is a tree. When executing\nthe program these trees are reduced as much as possible. This new tree,\noften just a singly value, is the result of the computation.
\nWe also see that we have no language constructions. Everything can be put in\nvariables and passed around. This provides a high degree of flexibility. We\nhave tools for expressing powerful abstractions, but also to make completely\nunreadable code.
\nComing from an imperative language there are some main differences one should\nhave in mind.
\nThere are no sequential ordering of expressions. In pure functional\nprogramming we solely have functions. When we are not able to reduce a\nfunction expression any further, we have our result. And yes, the result\nis a function. To get greater insight in this the\nLambda Calculus is a\ngood starting point.
\nWe also have a whole new vocabulary about functions:
\nThis vocabulary is also available to mainstream programming languages such\nas Java, C#, etc. But they are central to functional programming.
\nThe last difference to imperative programming is the lack of control\nstructures. That's right, we don't have any while-loops,\nif-expression, etc. But fear not. We can express the same computation\nin functional programming. For the iteration idioms we use recursion\nand for the conditionals we use pattern matching.
When doing imperative programming we have an explicit state. This state\nis concrete variables. When performing computation we modify the state\nin a linear fashion. We might concatenate a couple of strings and add\nsome numbers. In the end we return either a value, a pointer to the\ndata we made, or nothing. The last case assumes that we did some effect\nfull programming and that we are able to read the results from somewhere\nelse. This is not how we do when thinking functional programming.
\nIn functional programming we think about what we have and what we want.\nThese objects are reasoned about as inhabitants of a type. A type is here\nunderstood as set of elements.
\nA function is a map from one type to another. A whole program is understood\nas a map from some initial element of a given type, to another. This map,\nor function, is in Haskell called main.
We have enough to formulate simple expressions and evaluate them in the\ninterpreter. Next thing, for practical Haskell programs, is to set up\nautomated testing. This is to allow great flexibility in software development.\nAfter that we also need to think about how users can access the\nfunctionality we have build. So we look into deploying.
\n"},{"url":"/assumptions/","relativePath":"assumptions.md","relativeDir":"","base":"assumptions.md","name":"assumptions","frontmatter":{"title":"The Easiest-Assumptions Solution","author":"Mads Buch","date":"2021-02-04","template":"post","excerpt":"Developing solutions for problems is hard. Make it a little easier by choosing the assumptions that allows to do so."},"html":"Main point: When confronted with the need to make assumptions on software\ndevelopment, pick the one that is easiest to implement.
\nI am working with software and understanding data for a living. The processes\nsurrounding that are highly dependant on learning fast, predictable and\nreliable to be able to deliver before specified deadlines. This partially\nrelies on faith but mostly on an iterative approach where I move\nforward before finishing a step with the expectation of iterating back\nlater on with a deeper understanding. I embrace it and let\nit lead the way I work.
\nKnowledge is partial and requirements vague. Hence, it is important\nto be aware of assumptions vs. knowledge. As for the assumptions we should\nalways choose those that makes our life the easiest; We should choose the\nassumption that yields the lowest lift solution.
\nAt Spor we often need to make data we do not fully\nunderstand available for exploration without rails. Data is made available by\nwriting an ontology that assigns semantics to the data. As with\nother software development, we are at liberty to only implement semantics\nwe are certain about. And so we do. We choose the assumption that data we\ndo not fully understand is not important. As soon as that assumption is\nconflicted, we have new knowledge and use that to direct our efforts.
\nAt another instances I was implementing a minimum viable product for a client.\nThe platform was serving customers and a default assumption is that we need a\nsign-up flow for new users. I refrained from\nimplementing it as the easiest assumption was that new users did not do self\nsign-up. To this day, the platform does not allow people to enter a sign-up\nflow.
\nWorking this way has the bi-effect of recognizing that there\nare things in life that is more important than re-implementing the same feature\nover and over again. Like spending time with friends and family.
\n"},{"url":"/blockchain-product-toolbox/","relativePath":"blockchain-product-toolbox.md","relativeDir":"","base":"blockchain-product-toolbox.md","name":"blockchain-product-toolbox","frontmatter":{"title":"The Blockchain Product Toolbox","author":"Mads Buch","date":"2022-09-21","template":"post","excerpt":"This article is my attempt to collect my thoughts and the use of blockchain and smart contracts for product development."},"html":"Blockchain technology is unfolding for our eyes. I work with some bright people\nand we actively use blockchains as a part of our product offerings which has prompted\nthoughts. This article is my attempt to collect my thoughts and the use of\nblockchain and smart contracts for product development.
\nI am also trying to refrain from making puristic comments in this article.\nThere are a lot of critiques being circulated about blockchain technologies,\nand mostly well founded. But like with all other technologies\nit will take decades to reach maturity and adoption.
\nFirst, we bought products in a single transaction -- a coin for an item.\nThis has developed into simple relations governed by subscriptions, retainers,\nand such. Now we are developing the blockchain economies that\nwill let us build even more fine-grained customer relations into the products.\nas a consequence, blockchains are becoming more than just a mechanism to\nmake consensus on state among disparate parties. It is representing a new\nparadigm for products.
\nPayment infrastructure: an obvious use case for blockchain technologies\nis payment infrastructure. The current downside is that it requires a bit of\nonboarding to let people pay with tokenized currencies, and depending on\nthe market segment for the product it might or might not be wise.
\nA feasible flow would be to let users pay with a stable coin. Currently, some\nof the popular ones are USDC and USDT.
\nThis would be as an alternative to setup an agreement with a more traditional\npayment provider such as Stripe or one of the others. The value proposition\nis that there is no 3rd party risk -- the business will not rely on the payment\nprovider's service, neither technically nor exposing them to other types of\nservice disruptions.
\nThe Membership NFT:\nTraditionally we have created application users by asking for email and password.\nA new tool in the toolbox is the membership NFT.\nThe idea goes as follows: The user either mints a membership NFT\nor buys one from the secondary market. When the user connects to the app using\nthe wallet that also holds the NFT token, she will get privileged access by\nthe token she holds.
\nThe value proposition of this is to allow users to retain value for their\nmembership. This also introduces an alignment of incentives. The user has\nan incentive to make the service provider better. This is a positive incentive\nto post truthful reviews, provide valuable and actionable product feedback,\nand take the time to do so.
\nThe Application Token:\nA product can have its currency. The great thing about this is that it can\nbe programmed to cater to the need we have. Do we need a subscription at 10 cents\na day? No biggie, we just automatically make the currency reduce by 10 cents\na day.
\nThe subscription model: combine the membership NFT and the application\ntoken to build a subscription service. Instead of charging the customer's\ncredit card each month, the holding of the NFT owner deducts in real-time.\nWhen it reaches 0, then it is time to top up the account. The user can\nbuy more application tokens either on a secondary market or directly from\nthe service provider to instantiate the account and get access to her\nwork.
\nArchitecting software for the above solutions would probably benefit from\nupgradable contracts which, on the other hand, limits the decentralized news\nof such a product. This is not a problem per se as the solutions sketched\nout our product add-ons.
\nThis is contrasted to open protocols where trust is central to the value\nproposition of putting things on-chain. Creating those requires another\ntype of diligence and has other worries.
\nOne of the main features of putting product features on-chain is integration\ninto the existing blockchain ecosystem. This includes letting users trade their\ntokens and NFT assets on DEXes, taking payment in the form of other\nblockchain-represented currencies, etc.
\nFor closed product features the inherent value is less than with open\nprotocols, as the trust and transparency for the code are both of lower value\nand usually circumvented. Whether the code runs decentralized or on a\ncentralized infrastructure does not make a big difference when the code can\nbe upgraded.
\n"},{"url":"/building-a-scraper/","relativePath":"building-a-scraper.md","relativeDir":"","base":"building-a-scraper.md","name":"building-a-scraper","frontmatter":{"title":"Building a Scraper","author":"Mads Buch","date":"2020-12-24","template":"post","excerpt":"Scrapers are integral to data intensive applications. They span real development projects, and, as such, there are key architectural decisions to make."},"html":"This is a few notes on building a scraping pipeline. A scraping pipeline is\nan application that takes data from a website and spits it out in a format\nsuitable for another project.
\nThese thoughts are based on a current project where I need to scrape various\nwebsites and build a triple store. And example is the website ug.dk that holds\nDanish educations, institutions, jobs, campuses etc. I have build a setup that\ncan create an updated triple store with fallback on old data for resources that\nis not available.
\nTo build this scraper, there are some core principles that has lead decision\nmaking.
\nGet a full minimal pipeline up running ASAP. From there it is a matter of\nenriching data and incrementally enhance the pipeline.
\nCheck both the code and the data into git. When a full version of the scraper\nis done, and data is scraped, commit the resulting data. Diffs can be used to\nsee what data has changed since last scrape or it can be used to revert data\nback when introducing bugs in the pipeline. For that reason, save data in\na human readable format eg. JSON. Make sure that serializer saves it in a\nprettified format to make beautiful diffs.
\nFind a good tradeoff between saving entities as individual files or bundling\nthem in individual files. GitHub handles files up to 100MB, on the other hand,\nhaving several hundred thousands files can be less practical.
\nMake a script to save data to the disk in a format that closely mimics the\nformat from the source website. Make sure that runs are non destructive,\nenriching / updating existing entities instead of destroying existing data\nand re-fetching.
\nMake another script that takes data saved from the website and transforming\nit into the target format. Let the scraper fetch files while working on this.\nWork on this script on a subset of the source files to ensure fast iteration\ntimes.
\n"},{"url":"/data-ai/","relativePath":"data-ai.md","relativeDir":"","base":"data-ai.md","name":"data-ai","frontmatter":{"title":"Data-Driven AI","subtitle":"On the ideal AI development platform","img_path":"images/data.png","template":"page"},"html":"This document is a working document elaborating on a system to employ\nartificial intelligence (AI) generally. The system is based on a layered network approach\nwith an SDK for ingesting new data and an interface to interact and setup the\nAI. In the end, the goal of the system is to:
\nThe system works on a number of premises
\nThe problem space is characterized by the article on AI Tools and\nthe following case studies.
\nA number of case studies show the potential for the technology.
\nIdentity theft is becoming a larger and larger problem as we move more\nfunctionality to the web. To counter this, we employ various techniques to\nsafeguard systems against identity theft and techniques to detect identity theft.
\nThe domain is highly complex to make automated solutions to, as most\nfeatures that decide whether a loan application is related to identity theft\nare not in the specific loan application itself. That is, we can not see from\nthe requested amount, the name, or other features that we deal with fraud.\nWe need to find features that decide fraud outside of the application itself.
\nHence, a system to support the task of constantly being able to accommodate\nnew threats should possess a number of properties:
\nIt should be easy for a human user to teach the system something new. This\nincludes
\nIn particular, the abstracted knowledge is the important part. It is here\nwe encode what \"fraud\" means. Abstracted knowledge could be an entity called\nSuspiciousEmployment which is an entity that is related to a Person that\nis related to an Employment, where the employment is related to a company\nwithout any activities.
\nLastly, the system should be able to uncover this abstracted knowledge whenever\nnew data is provided. This both means when a batch of existing applications are\nput in and when just a single loan for a live check is provided. This is the\nservice loan providers integrate against.
\nThe system connects the work between many different stakeholder: Domain experts,\ninfrastructure specialists, etc. To make sure this is done properly we follow\na run book defined in following chapters.
\nPart 0: Working with an AI Platform
\nPart 1: Analysts Book
\nPart 1: Developers Book
\nThe short version is that the system works by juxtaposing networks. These\nnetworks represents the real world, they are also known as knowledge graph,\nthey can represent derivatives of the real world known as layers, or they can\nrepresent decisions, actions, etc.
\nThis provides an AI platform as laid out in\nExplainable AI with Layered Networks.
\nThe system contains following components:
\nIngestors take information from the surrounding world and makes it available\nto the system. The engine takes several files representing ingested data and\nintegrates it and abstracts it. Lastly the applications and services make it\navailable for actual use.
\nInstead of creating one knowledge graph to rule them all, we create several\nknowledge graphs and maintain them individually. In order to have the highest\ndata leverage it needs to be dead simple to ingest new data.
\nA knowledge graph has 2 components: a triple store and an ontology. The triple\nstore has the actual information while the ontology is and abstract\nunderstanding of this data.
\nThe application layer considers the interaction with other systems. Currently\nwe are developing an Explorer and an API layer for this.
\n"},{"url":"/data-platform/","relativePath":"data-platform.md","relativeDir":"","base":"data-platform.md","name":"data-platform","frontmatter":{"title":"The Data Platform","author":"Mads Buch","date":"2021-03-27","template":"post","excerpt":"We need good data platforms to ingest, process, and analyze data."},"html":"Main point: We need good data platforms to ingest, process, and analyze data.
\nUnderstanding our surroundings is an art. Good artists need good tools,\nnot making art is not possible without good tools, but because good tools\nenable expression.
\nThe same is the case for data science. We need a good data platform. It should\nhelp us separate concerns. It should assist in and assure the quality of the\ndeliverables, and it should let people focus on their work and not too many\nother things.
\nBut what concerns are central to understanding data? The first concern is\ntaking the data from the source and process it into a format we can use.\nThis is called ingestion. Next is the intermediary representation. This acts\nas an indirection and lets us disregard the data source. this will integrate\ndata so we can work on data across data sets and wit will apply anonymity for\ndatasets where it is needed. Lastly, we need a product. This is the concern of\neither understanding the data, getting models that are trained and can be used\nin applications, or something third.
\nIngestion:\nThe first step is to ingest data into the system. This consists of figuring out\nhow the data should be modeled and build the data package. Concerns here are\nin particular data hygiene and local integrity.
\nAn ideal data platform should give the fullest freedom to express the model.\nIe. the engineer should not be made to fit the data on an existing model.\nFurthermore, the data platform should use the ontology to assist with\ndata hygiene.
\nWe might even want to work with data under different ontologies. The data\nplatform should enable the ability for the user to handle multiple\ningestions of the same data modeled slightly differently to accommodate different\nneeds.
\nInternal Representation:\nThe internal representation should provide an indirection to the source.\nit should with as little effort as possible make sure that identical\nentities are resolved to the same or at least make sure that reasonable\nrelations are setup. In particular, this is a place to keep track of\nprovenance ie. where data comes from and what intermediary steps it has been\nthrough.
\nThis is also the place to apply differential privacy to the data in need.\nThis ensures that the analysts can work with the data free of friction and release\nthe results they see without further redaction. This is highly important\nwhen training statistical models such as neural networks in personally\nidentifiable data as there is a risk to covertly release sensitive data\nin the model.
\nAnalysis:\nThe last part is where the data is utilized to create value. This involves\ntooling to quickly get an intuitive sense of the data, the ontology,\nhow data interrelates, what data is available, and the quality of the data.
\nThe data scientist would need tools for extracting the data for their needs.\nThis could be exemplars to train models on etc.
\nAt Spor we are trying to solve some of these problems.\nIn particular, we have devised methods for resolving data from disparate\ndatasets while still retaining the ability to reason about the data locally.\nWe are developing everything to work in the browser but scale to the cluster.\nWhere data resides is important. Especially when you want to work on private\ndata such as emails or personal notes.
\n"},{"url":"/deorganize-yourself/","relativePath":"deorganize-yourself.md","relativeDir":"","base":"deorganize-yourself.md","name":"deorganize-yourself","frontmatter":{"title":"Deorganize Yourself","author":"Mads Buch","date":"2021-01-12","template":"post","excerpt":"We often don't need that much organization. Organizational structures should be afterthoughts."},"html":"Main point: We often don't need that much organization. Organizational structures should be afterthoughts.
\nHave you ever taken yourself in building intricate folder structures for data\nthat doesn't exist yet? And then found yourself in doubt on where to put a\nfile next time you need to add one? Or maybe you have worked on a project and\nthen, months later, you need to reenter the project structure just to find that\nyou intuition on the subjects has changed enough that the old organization does\nnot make sense anymore.
\nWell, I am confident that it is normal and we all do it. Cleaning up is nice.\nShowing underwear in the underwear drawer also cleans out our inner mess. but\nwith most intellectual thoughts it is not so easy to put them in single boxes.\nThey usually fit into intricate networks where a thought, or all kinds of\nintellectual work, can be reached from several thought fibers.
\nHence, instead of organizing work into conceptual boxes, it makes sense to\nthink about rediscovery and explorability.
\nMost operating systems are already now attempting to banish folder structures\nin favor of search mechanisms. For many it is more normal to press the\nwindows button and just search for the program or file they want\n(nostalgia alert: In my youth we had windows 98 with only nested menus with\nprograms and folders with files).
\nWriting my own notes and my journal I basically just have all files in one big\nfolder with text files. I can search in the file-content using VS Code. I\ncan search for specific filenames and I can link files together using tags.\nHere I have 2 means of information retrieval: The exploitative where I\nremember exact strings of what I need and the more\ncontextual / explorative where I find the material based on it\nbeing \"something along the lines of ...\".
\nI find it interesting to explore what the best tools are to explore information\nwithout knowing what I want. Currently I do that in Spor.
\n"},{"url":"/data/","relativePath":"data.md","relativeDir":"","base":"data.md","name":"data","frontmatter":{"title":"Understanding Data","subtitle":"On the craft and art of understanding data","img_path":"images/data.png","template":"page","indexOrder":3},"html":"\nThis page collects my thoughts on the theme of data science and engineering.\nData science is multi-disciplinary. Ranging from philosophical and theoretical\ntopics of ontology to practical considerations about scaling a platform to meet\nrequirements.
\nThis page is evolving. It takes my individual posts on the subjects and aggregates\nit into a coherent whole. A whole that often changes shape.
\nWe can consider everything stored on a computer data. Everything that can be\nrepresented binary. Programs, configuration files, images, sound, documents,\netc. In essence everything on a computer is data and might constitute insights\nused to solve a problem.
\nOne dimension of data characterization is the signal/noise ratio. The ration is\nsaid t be high, ie. high signal low noise, when small amounts of data is valuable\nwhile noisy data has many bits that does not provide data.
\ncanonical examples of high noise data would be sound and images, while a\nsemantic triple, usually, has a high signal.
\nAI applications mostly consider high signal data. It should be noted, that the\nsignal can be increased. This is the task og machine learning. Ie. instance\nrecognition in images reduces noise by constructing triples. This triple\ncould be image.png depicts a chair.
Depending on the nature of the data there are several ways to interpret data.\nSometimes statistical aggregation suffices, other times we employ an\nexplorative approach to assess the potential.
\nAs for statistical methods, the most widely used are probably those available\nin spreadsheets. However, more generally the Probability Monad\nprovides tooling for writing these distributions as programs.
\nOther techniques are those based on networks. Modeling data as networks\nformatted under an ontology can be advantageous as it lays out clear\nsemantics of the data. It clearly specifies what classes entities in the data\nbelong to and how they relate to other entities.
\nThese techniques are being used in fraud detection. Fraud and Networks\nis an article that touches on some of the aspects of doing that. Furthermore,\nthe network approach can also be used to increase trust in statistical results.\nI investigate some of the opportunities in adversarial Statistics.
\nData processing concerns how to process large amounts of data. But more than\nthat is als concerns how to reuse existing assets. This is essential as it\nallows fore serendipity and finding patterns across different data sets.\nTo do this an organization can employ a data platform. A common place to put\ndata assets for cross leverage between use cases.
\nFurthermore, an integral problem to data processing is scale. Data often comes\nin large amounts. For this, both the storage and processing architectures need\nto scale. Scaling can only to an extend be separated from the data and processing\ntechniques and is a serious concern when thinking up data processing architectures.
\nFor practical purposes the data platform is essential. Not only does it reduce\ntime when changing analysis etc. It also provides the needed foundation to\nscale data analysis to span appropriate data sets.
\nOne part is about processing and ingesting data.\nThis could be loading data into data frames, scraping websites,\nutilizing APIs, but also using techniques such as entity recognition and\nlinking for extracting information from text, object recognition to extract\ninformation from image material, and speech recognition in conjunction with\nNLP techniques to get data out of auditory resources. The problems in this\nlevel are very engineering-specific. It is about keeping code up to date, etc.
\nNext is processing it into an intermediary representation. This is necessary\nwhen the amounts of data and sources are considerable. This step does a few\nthings. First and foremost, it integrates data. It relates entities from\ndifferent data sources that are related. This is desirable as we do not want\nto do this for large amounts of data every time we want to ask a question.\nSecondly, it ensures scalability. For sufficiently large amounts of data and\nsufficiently complex pipelines, it is not feasible to run everything from\na single laptop (or phone). Problems here are on scale.
\nLastly, the production step. This step produces data for further use. This\ncould be for reports, it could be data for training models, or the actual\nmodels to integrate into an application. The data platform could also\nproduce endpoints for real-time data insight etc. Problems here are of semantic\nnature. How do we ensure the correctness of produced claims? Articles relevant\nto this are.
\nThere are a number of ways data is put to use. One way is through pieces of\nwritten works. This can be data journalists who make a piece using data they\ninterpret. It can also be assembling predictive models using machine-learned\nmodels.
\nThose pesky signatures. Hard to debug, hard to get right. Therefore, I have\ncreated a template repository for the next project needing
\nnpm install to install dependenciesnpx hardhat test to compile the contract and runs testsFull source available on GitHub
\nAs a demo we EIP-712 wrap a function with the following signature:
\nsomeFunc(address sender, address receiver, uint256 amount)The core function is implemented as the _someFunc which is private to\nensure that is is not being called directly.
The wrapper is a function with the same initial signature, and the a whole lot\nof fields more:
\nfunction someFuncGasless(\n address sender,\n address recevier,\n uint256 amount,\n uint256 deadline,\n uint8 v,\n bytes32 r,\n bytes32 s\n) external { ... }Note the deadline, and v, r, s. These are the\nprotocol specific values needed to securely accept the function invokation\nfrom a third party signer. The nonce is verified implicitly via the signature.
\n// Check deadline\nrequire(deadline >= block.timestamp, "EIP712: Expired");We implicitly use the sender and the one we expect signed the message.
Next happens that packing, hashing and signing. This is the tricky part of the\nprotocol.
\nbytes32 digest = keccak256(\n abi.encodePacked(\n "\\x19\\x01",\n DOMAIN_SEPARATOR,\n keccak256(\n abi.encode(\n SOME_FUNC_TYPEHASH,\n sender,\n keccak256(abi.encodePacked(receivers)),\n amount,\n deadline,\n nonces[sender]++\n )\n )\n )\n);This is an example of a non-nested structure. It is a good starting point to\nincremenatally add more complext datatypes to it. For full reference see\nthe EIP-712 specification.
\nAlso note the nonces[sender]++. This is the nonce check that inline increments\nthe nonce to ensure replay attacks are not possible.
Last thing to do is to check the signature and call the function body.
\naddress recoveredAddress = ecrecover(digest, v, r, s);\n\nrequire(\n recoveredAddress != address(0) && recoveredAddress == sender,\n "EIP712: Invalid signature"\n);\n\n_someFunc(sender, receivers, amount);And that's it!
\nA number of implementations of this is available in the tests that are\navailable on GitHub.
\nThe core is to generate a signature either using a direct ETH RPC call to the\nwalllet
\nconst signature = await ethers.provider.send("eth_signTypedData_v4", [message.sender, data])or by calling the experimental _signTypedData
const signature = await otherAccount._signTypedData(data.domain, data.types, data.message)Note: These functinos have different signatures. In particular, _signTypedData\ndoes not expect to have the tyoe of the domain passed.
The signature is split into it's parts for cheaper processing on the EVM side.
\nconst r = signature.substring(0, 66);\nconst s = "0x" + signature.substring(66, 130);\nconst v = parseInt(signature.substring(130, 132), 16);And lastly the contract is being called by
\ngaslessContract.someFuncGasless(message.sender, message.receivers, message.amount, message.deadline, v, r, s)Explainable AI is the hype! Or maybe not so much. But depending on the use case\nthe AI has to be explainable. Imagine if your loan broker rejected you without\nproper reason and you would have to move out of your house, or if the insurance\npremium were to be set by a black box with no real way to know what effects\nthe resulting premium. Hence the need for explainable AI systems.
\nWhat is a system that provides explainable AI? It is a system that supports\ntheir decisions with compelling arguments. In essence, the system should\nbe able to spit out a report that presents the proofs. These proofs should\nbe verifiable without access to the AI system. But how do we create\nsuch a system?
\nOne way to create explainable AI systems is to create strong isolation between\ndifferent types of knowledge. Some knowledge is of factual nature, some\nknowledge is objects recognized in image material / sound etc. Some knowledge\nis based on trustworthy sources while others are highly circumstantial.\nA way to create this division is by using multi-layer networks.\nA layer is merely a network graph constructed in a way such that it is possible\nto consolidate individual layers and traverse the multilayered graph.
\nEach layer has a single knowledge responsibility, such a responsibility could\nbe information about who owns which companies, or what landmarks are present\nin pictures. Furthermore, each layer includes information about provenance,\nconfidence, verification steps, etc.
\nFor the example about a layer that holds responsibility about the company ownership, we\nconstruct the lay by reading the relevant company register. We note that\nwe have high confidence in the correctness of the data represented (this\nmight be different for different jurisdictions). The verification step\nwould be to log in to the registry and very the stated ownership.
\nFor the example about landmarks present in pictures, we can construct the\nlayer by using image recognition techniques. Ie. we would contain the use of\nblack-box techniques (eg. neural networks) to that layer only.\nProvenance would include information about the source image,\nconfidence would be low to medium depending on the evaluation metrics of the\nalgorithm in use, and verification steps would include visual inspection of\nthe source image.
\nWhen combining these layers we can do complex reasoning. We can make chains\nlike\nPicture P features Landmark L, Landmark L has address A,\npicture P was taken at time T, Picture P was shared by Person G to support\nthe conclusion that a person was present at a specific place and time.\nThis syllogism is verified manually such that:
The next step would be to add compound layers which is a product of existing\nlayers. Besides enabling more complex reasoning for the system, they would\nalso inherit provenance, confidence, and verification from previous layers.
\n"},{"url":"/elixir-extended-context-framework/","relativePath":"elixir-extended-context-framework.md","relativeDir":"","base":"elixir-extended-context-framework.md","name":"elixir-extended-context-framework","frontmatter":{"title":"The Extended Context Framework","author":"Mads Buch","date":"2022-11-01","template":"post"},"html":"I have done several projects in Elixir with great teams. In the beginning,\nit is usually just about writing some code. But as more and more developers\nget onboard and more and more code is churned, erhm refactored,\nthe architecture becomes increasingly important.
\nWe tend to start with a single Phoenix app. We then see that modules start\nto grow to unbearable sizes. We need to implement various supporting services\nand internal subscribers to queues, but it is not apparent where these go. The\nnext natural step would be to employ something like Umbrella and\nmanage it as multiple microservices. However, that is one heavy beast and makes\nit harder to reuse components.
\nThe extended contexts framework came to be in collaboration with Aleksander\nRendtslev. We relax the ownership of the persistency layer and the web layer\nto support velocity and as a pragmatic trade-off.
\nWe use this framework with high-velocity teams. This means a couple of things.\nFirstly, code is never staged. We trust that when the code passes tests,\nis reviewed, and is approved by the developer, it is ready for production.\nSecondly, we deploy the production environment several times a day.\nLastly, our time is prioritized towards developing software.\nIn particular, we avoid spending too much time on low-level technical\ndiscussions and trust that each individual asks if there are any questions.
\nThis approach puts particular strains on a codebase and the team:
\nThe extended context framework is a tradeoff between the Umbrella-type\nmicroservice infrastructure and a single Phoenix app. We still divide code\ninto semantic chunks but build them in a way that highly supports horizontal\nscaling. The folder structure of aa implementation looks like the following.
\n/persistency\n schemas/user.ex\n repo.ex\n/web\n /controller\n /graphql\n/context_one\n /actions\n perform_some_actions.ex\n /jobs\n internal_subscriber.ex\n /service\n external_service.ex\n /logic\n parse_some_thing.ex\n validate_something_else.ex\n /workflows\n place_reservation.ex\n module.ex\n/context_two\n ...On the top level, we share the persistency layer and the web layer between the contexts.\nWe do this as they tend to be very hard to divide into semantic categories –\nas a developer we often need that blog-posts object even though we are working on the discord context.\nThe same is the case with the web interface.\nThey are very shallow and would introduce unnecessary noise in the context.
\nA context collects functionality regarding a single semantic domain for the\napplication. Because of the context's construction, we prefer fat contexts.\nThe context consists of the following parts:
\nmodule.ex file: This file is the context external interface. This\nfile should merely contain defdelegate's to the code in the others files.\nIn particular, functions that should not be exposed outside of\nthe context, should not be added to this file.Data fecthing: We prefer to fetch data as far up in the hierarchy as\npoassible. Some data is provided on the outer layer, that is in resolvers\n/ controllers / listeners etc. other data is fetched in the workflow.\nWe do this to avoid loading data mutliple places.
\nAs developers, we spend a lot of time changing and tweaking code.\nIt is said that developers spend time \"reading code\".\nBut for most commercial projects reading the code is boring, and is an activity\nwe want to reduce. Instead, we focus on optimizing for changing the code.\nThis involves the following:
\nTo identify what parts of the code should be changed we investigate from a\nknown endpoint. Indifferent to have painful this sounds it\nis usually the case for developers of commercial software.\nTo assist this process we architecture around two principles: 1) Reduce\nindirections and 2) Contain branching.
\nThis is where the workflows come in. They act as the entry point and\nare directly called from resolvers and controllers.
\nReading the workflow allows us to concisely identify the side effects of the change.\nIf the workflow uses another workflow, we need to expand our analysis to that\nworkflow also.
\nWe can then implement the change. This requires a couple of things:\nWe alter existing code, we add new code, or we do both. In a traditional\none-file-for-a-module approach we tend to have ever-expanding files. The\ncanonical answer to this is that \"if a module becomes too big, it is two modules\".\nHowever, in high-velocity environments, this is not feasible.\nInstead, we use a \"one file, one responsibility\" approach. This ensures that\nno single file needs to be split as they usually stay very small. The tradeoff\nis that we risk getting a lot of files, though this does not appear to be\nthe case in the real world.
\nLastly, we ensure that the changes do not introduce regressions and that\nthe new features are implemented correctly. We do this by testing. For tests,\nwe mirror the application folder hierarchy. This makes it easy for us to\nunderstand the test coverage at a glance. When a file is missing a test file,\nit is easy to create one and implement it with a single simple test. Are\ntests failing after the change, then either the test of the implementation is\ncorrected.
\nVersatility: As pointed out by my colleague Matti, this architecture is\nnot bound to Elixir. It can be used with most languages. The main point to\nwhere this fits, is the high-velocity team settings.
\n"},{"url":"/forgetting/","relativePath":"forgetting.md","relativeDir":"","base":"forgetting.md","name":"forgetting","frontmatter":{"title":"Remember to Forget","author":"Mads Buch","date":"2022-01-07","template":"post","excerpt":"We need to forget to pursue a purpose"},"html":"Developing Minimum Viable Products is some of the most rewarding development work out there. We create hugely impactful projects and let inspiration and aspiration flow through our veins. In the heat of the moment, we remember to write everything down, creating vast backlogs of potential new avenues for the project.
\nHowever, most of these avenues are, in the best case, indifferent to the project, and in the worst case, they become darlings we hold on to. We get an attachment and a need to put it into the project, and it gets prioritized even though the impact is not proportional to the value it brings to the project.
\nHence it is important to forget. To boldly erase stuff or throw the material as far away as is not possible to retrieve it again easily.
\nThe truth is that when customers are brought on to the project, plenty of people will have plenty of ideas worth pursuing. And definitely, ideas that are better and more aligned with the commercial raison d’etre of the project.
\nForgetting is also the often forgotten but essential aspect of learning. We need to lose focus and get rid of details detrimental to progress, whatever progress means in a given setting. We need to forget to pursue a purpose.
\n"},{"url":"/fraud-and-networks/","relativePath":"fraud-and-networks.md","relativeDir":"","base":"fraud-and-networks.md","name":"fraud-and-networks","frontmatter":{"title":"Fraud and Networks","author":"Mads Buch","subtitle":"A case study on detecting identity theft in lending applications","excerpt":"The Case: As a financial institution we want to avoid fraud. Fraud is a broad term, so in this case, we focus specifically on identity theft. Ie. We want to be able to quickly detect oddities signaling that someone's identity is being used illegally.","date":"2021-03-18","template":"post"},"html":"The Case: As a financial institution we want to avoid fraud. Fraud is a broad\nterm, so in this case, we focus specifically on identity theft. Ie.\nWe want to be able to quickly detect oddities signaling that someone's identity is\nbeing used illegally.\nFor this case study, we have discovered a fraud vector where applicants use\nsimilar email addresses. We want to add this check to our existing system\nwith minimal effort and we want to be able to let it utilize all data we\nhave.
\nFraud is interesting. Not only because we as societies lose billions of\ndollars a year, but also because fraud finds its way through the cracks.\nBoth characterization and techniques of fraud change as fast as it is profitable\nand that is fast in a globally connected world. But this also sets the bar\nhigh for the system to detect and flag fraud. It should always be able to\nembrace new patterns while not decreasing in performance. In this case study, we\nlook at network technologies and how we can horizontally expand on the\ntechniques. We also see how we implement these techniques in a way that allow\nfor horizontal performance scaling.
\nFirst the data. In this example, we look at lending applications. We do not\naugment with data from other data sources although this can be added in\ntransparently later and augment the results.\nAn example of the applications could be as follows:
\nCaseId, Email, Amount, Name, Birth Date, Application Time\ncase007, tanjatt@example.com, 5000, Tanja, 1992-05-05, 2021-03-07 12:12:34\ncase008, astriddd@example.com, 150000, Astrid, 1985-02-09, 2021-03-08 12:12:34\ncase009, gert1970@example.com, 50000, Gertrud,1970-01-01, 2021-03-09 12:44:54\ncase010, gert1971@example.com, 50000, Gertrud,1971-01-01, 2021-03-10 12:54:53This yields a network where the nodes are either an Application that has\na case ID, an amount, and the time of application.\nThese case IDs are linked to Applicants. An Applicant has a name, a birth\ndate,
\n![\"fraud-net-1.png\"](\"/images/fraud-net-1.png\")
Next, we add in the email address layer. Normally emails would simply be\na data field on the entities, but to detect similar emails, we can\npull them out and build a new dedicated network that can be juxtaposed\nwith the old one.
\nThe email network is constructed such that similar email addresses are\nconnected. We say that email addresses are similar when their\nLevenshtein distance is\nat most 2. This means that two emails are considered similar when only 2 edits\nare needed to make them identical.
\n![\"fraud-net-2.png\"](\"/images/fraud-net-2.png\")
The email network and the lending applications network are connected such that\napplicants have a link to the email they possess. Now we can go from applicants\nto their respective email, go to a similar email and back to applicants again.
\nTo efficiently use this product network we use a random walk technique. From\na given entity, say case015 we take a random link out. We keep navigating\naround in the network randomly until we find a new entity of a specified type.\nIn this case Application. By doing this thousand, or hundred of thousands of\ntimes we can draw a picture of how cases are interlinked. The blow picture is\na result of that.
\n![\"fraud-net-3.png\"](\"/images/fraud-net-3.png\")
This picture is the result of 1000 random walks without excluding the walks\nthat never ended in an Application. As we can see, it is quite efficient at\nfinding a network of similar emails. This network will be flagged and an\nexpert will take it on to assess an appropriate action.
\nWhy This Solution?\nThere are several ways to achieve this. A more obvious way would be to issue\na SELECT query in SQL to get all applicants with similar emails. However, this\napproach does not scale very well with new fraud vectors and constantly has to\nbe updated. The network approach is fluid to new datasets. It will simply start\ntraversing new layers when these are added. The algorithm will find fraud\npatterns with a probability proportional to the out-degree per hop. This is\nreasonable as we can assume that entities connected in a long chain have less\nin common. If that is not the case, we can simply add in new links to\nstrengthen a connection.
Orig: Music to hear, why hear’st thou music sadly?\nComp: 00100010111011111100101101110010100010100101110000111000000101101001001111111100111000101110000111000000100100011111110000101000111010101101101000100111011111100101101110010111111001011010010011100011011101\nDeco: Music to hear, why hear’st thou music sadly?\nSize uncompressed 44\nSize compressed 26# This is part of my anti-atrophy tasks. As most of my professional software development\n# tasks are now is done through agentic development. This is fitness for the brain!\n#\n# Solely based on what's here: https://en.wikipedia.org/wiki/Huffman_coding\n\nimport requests\nimport pprint\nimport heapq\nimport math\n\n# Fetch the file, this is our corpus\nresponse = requests.get("https://www.gutenberg.org/cache/epub/100/pg100.txt")\ntext = response.text\n\n# Calculate frequencies\n\nfreqs = {}\ncount = 0\n\nfor c in text:\n if not c in freqs:\n freqs[c] = 0\n freqs[c] += 1\n count += 1\n\n# Normalize\nfor k in freqs:\n freqs[k] = freqs[k] / count\n\n# How priority queues aka head queues work\np1 = []\n# heapq.heapify(p1) - No need to run for empty lists\n\nheapq.heappush(p1, (5, "not so important"))\nheapq.heappush(p1, (1, "Really important"))\nheapq.heappush(p1, (20, "Forget it"))\nheapq.heappush(p1, (24, ("t1", "t2", "t3")))\n\nimportant_task = heapq.heappop(p1)\n\nassert important_task[0] == 1\n\n# For heapq when using the tuples, it will go onto next element if the first element is identical.\n# The docs are framing the type construction as a payload to attach a payload.\n# This is over loaded semantics (shane on you, Python)\ntie_breaker = 0\ndef next_tie_breaker():\n global tie_breaker\n tie_breaker += 1\n return tie_breaker\n\n\nleafs = []\nfor k in freqs:\n heapq.heappush(leafs, (freqs[k], next_tie_breaker(), k))\n\n# Alternatively\n# leafs1 = [(v, next_tie_breaker(), k) for k, v in freqs.items()]\n# heapq.heapify(leafs1)\n\n# Representing the tree:\n# Leaf (frq, _, symbol)\n# Node: (frq, _, (left, right))\n\nwhile True:\n if len(leafs) == 1:\n break\n\n a = heapq.heappop(leafs)\n b = heapq.heappop(leafs)\n sumProp = a[0] + b[0]\n node = (sumProp, next_tie_breaker(), (a, b))\n\n heapq.heappush(leafs, node)\n\nhuffman_tree = heapq.heappop(leafs)\n\nhuffman_dict = {}\nrev_huffman_dict = {}\n\nstack = [("", huffman_tree)]\nwhile len(stack) > 0:\n next = stack.pop()\n\n match(next):\n case (prefix, (frq, x, (left, right))):\n stack.append((prefix + "1", left))\n stack.append((prefix + "0", right))\n case (prefix, (frq, x, symbol)):\n huffman_dict[prefix] = symbol\n rev_huffman_dict[symbol] = prefix\n case _:\n pprint.pprint(next)\n\n\n\n# Let's compress something!\n\nstring = "Music to hear, why hear’st thou music sadly?"\n\n\n# compress\ncompressed = ""\nfor c in string:\n compressed += rev_huffman_dict[c]\n\ndecompressed = ""\ntree_traverser = huffman_tree\nfor c in compressed:\n # Traverse the tree\n if c == "1":\n tree_traverser = tree_traverser[2][0]\n if c == "0":\n tree_traverser = tree_traverser[2][1]\n\n # Are we at a leaf?\n if isinstance(tree_traverser[2], str):\n decompressed += tree_traverser[2]\n tree_traverser = huffman_tree\n\n\nprint(f"Orig: {string}")\nprint(f"Comp: {compressed}")\nprint(f"Deco: {decompressed}")\n\nprint(f"Size uncompressed {len(string)}")\nprint(f"Size compressed {math.ceil(len(compressed) / 8)}") # We approximate hereIngesting data is a crucial part of building AI systems. AI systems require to\nbe able to do two things: Use context and abstract. The context comes from\nthe ingested data.
\nIngesting is the process of interpreting the data into something the AI engine\nunderstands. Traditionally this meant fitting the data onto a specific model.\nAnother approach, however, is to ingest in terms of relations, data fields,\nand think in modalities.
\nThink multi-modal learning. The idea is that information is experienced under\na particular modality. Such that a person can be experienced visually,\nauditorially, be felt, smelled, etc.
\nThe story is the same regarding pieces of information about an entity. It\ncan exist in terms of text, location, imagery, time, etc. The fundamental\nrealization is that entities span multiple modalities and that modalities\nrepresent the interface to the surrounding world.
\nIn the simplest for ingestion happens as data transform from a simple source\ninto an internal representation. An example is tabular data with no need for\na context to understand and ingest it.
\nFor more complex cases, we need contextual information to ingest it.\nThe canonical example of this is entity linking when extracting data\nfrom written text.
\n"},{"url":"/introducing-a-second-brain/","relativePath":"introducing-a-second-brain.md","relativeDir":"","base":"introducing-a-second-brain.md","name":"introducing-a-second-brain","frontmatter":{"title":"Introducing Second Brains","author":"Mads Buch","subtitle":"Ongoing thoughts on second brains","excerpt":"Seconds brains have reached quite the hype. Both with tools like RoamResearch, Obsidian and friends. Needless to say, it is a good tool. Since I started building my second brain, I have been journalizing more often than not.","date":"2021-01-06","thumb_img_path":"images/sb-graph.png","content_img_path":"images/sb-graph.png","template":"post"},"html":"Main point: Second brains are great in particular because they require no structure.
\nSeconds brains have reached quite the hype. Both with tools like RoamResearch,\nObsidian and friends. Needless to say, it is a good tool. Since I started\nbuilding my second brain, I have been journalizing more often than not. This\nis healthy for me.
\nOn of the strength about second brains is that they are naturally without\nstructure. That is, thoughts do not need to go into particular folders. They\ncan go in todays journal. If it makes sense, they might occupy their own file.\nThey might be constituted in a tag, and expanded to a full file whenever\nthere is juice enough to do so.
\nThis is not to say that cleanups and organization is not possible and should not\nbe aspired to. It is just another process, saved for another time. Like a\nboring sunday afternoon with nothing more important to do, whenever they come.\nA deep consequence of thinking this way is also the acceptance that thoughts\nand ways of doing thins change on a structural level. For a personal second\nbrain this is perfect. Tools I need naturally emerge from my text. When I\ndon't need the tools anymore, they evaporate.
\nOne aspect I am especially keen about is what leverage I will be able to get:\nWill I be able to derive some deeper truths about myself? Will I be able to\nfind insights I was not able to see before? Currently I am merely producing\nthe data. Along with this, my work with Spor.ai hopefully\nwill bring forward tools needed for such inspection.
\n"},{"url":"/knowledge-graph-based-research/","relativePath":"knowledge-graph-based-research.md","relativeDir":"","base":"knowledge-graph-based-research.md","name":"knowledge-graph-based-research","frontmatter":{"title":"Knowledge Based Research and Vague Ideas","author":"Mads Buch","subtitle":"On managing, disseminating, and condensing knowledge","excerpt":"Knowledge graphs based research give overview on vague ideas, assists knowledge discovery, and is a strong collaboration tool.","date":"2021-02-17","template":"post"},"html":"Main point: Knowledge graphs based research gives overview on vague ideas,\nassists knowledge discovery, and is a strong collaboration tool.
\nCurrently I am researching for at proposal on a project within machine learning\nand type theory. The idea, however, is not entirely condensed and figuring out\nwhere to pick the low hanging fruits is difficult. My process has often been\nthat I create different documents that represent different aspects of the idea.\nIn the end I eventually get lost in my own production to move on to more\npressing tasks to forget about the project for weeks at the time.
\nThis represents a class of ideas are also some that I get back to infrequently.\nI often revisit them after a long walk where I got some realization.\nObviously, at that point I do not have the head space to put the new insight\nin context and rework old material.\nSo it'll often just get chucked in there for later review. When I finally reach\nthat point where I cam do a later review, the task might still be daunting.\nEven worse, one might have miscalculated the actual effort to clean up. In\neither direction. Sometimes I thought I had much more material than was actually\nthe case.
\nThis is a part of the create process and should not be discourages. But I\ndefinitely think there is room for tooling around it. This is why we are\ncreating Spor Research. It is a tool that solves the\noverview and context problem. In particular we remove the meat of the research\nto leave on the skeletal structures. It is then significantly easier to\nfigure out where to add in new insights, where to put a weekends worth of\neffort, and to serendipitously discover new connections.
\nFirst and foremost we integrate the tool with seconds brains,\nZettelkasten, and linked notes. This is based on the assumption that research\nstarts with what we know ourselves.
\nSecondly we integrate with public sources such as Wikipedia, arXiv (my hood),\nand business databases. This allows to explorer the context in-app. We have\nthe idea that we need to remove barriers on thinking up search queries. So if\nwe can just remove a fraction of dead-end searches we see that as an impact.
\nLastly, we also know that research is not carried out individually. We also\nknow that it is a big ask to make colleagues read and provide feedback on\ncomplicated texts. For these tasks we work on ways to share a research\noverview and also provide information on what participant of the teams has\ncontext and specific knowledge on each part.
\nWe share updates on the progress on our LinkedIn Page.
\n"},{"url":"/lambda-calculus-interpreter/","relativePath":"lambda-calculus-interpreter.md","relativeDir":"","base":"lambda-calculus-interpreter.md","name":"lambda-calculus-interpreter","frontmatter":{"title":"Lambda Calculus Interpreter","author":"Mads Buch","date":"2022-11-01","template":"post","category":"technicalRef"},"html":"Draft
\nLambda calculus, often regarded as the cornerstone of computational theory,\nis a mathematical system of function abstraction and application.\nSince its inception, it has served as a research vehicle.\nBeyond its theoretical significance, lambda calculus is also the\nfoundation for many modern programming languages. Furthermore, its longstanding\nhistory and impact have made it a well-studied field.
\nOne of the languages particularly building on the lambda calculus is Haskell.\nHaskell is a functional language that has captured the attention of developers for\nits elegance and mathematical soundness.
\nClone the repository, make sure you have the latest version of haskell stack\ninstalled. It will take care of the rest from there.
\n$ stack build\n$ stack test\n$ stack exec lambda-exe\nLambda Calculus Interpreter!\nλ: (\\x.x) (\\y.y y)\n(λy.(y) (y))In particular this example executed that lambda expressions (\\x.x) (\\y.y y).\nLambda calculus works in the way that the expressions is reduced until it\ncan not be reduced anymore. The resulting term is the value. This differs from\n\"normal\" programming languages where we would expect to get a string or a number\nout.
The core insight is that everything can be encoded as a lambda term.
\nAs a part of my degree as Masters in Science in Computer science I wrote my\nmasters thesis on the subject of formalizing differential privacy.
\nThe outcome what a thesis report and\na thesis site.
\n"},{"url":"/leadership-imperatives/","relativePath":"leadership-imperatives.md","relativeDir":"","base":"leadership-imperatives.md","name":"leadership-imperatives","frontmatter":{"title":"Leadership and Imperatives","author":"Mads Buch","date":"2021-09-15","template":"post","excerpt":""},"html":"Here's an idea: Leadership is about managing imperatives.
\nWell, not just leadership as in corporate leadership, but also people management and collaboration.
\nThis idea has some consequences. First of all, managing imperatives also requires one to know what needs to be done. It would appear that a foundational craft in leadership is the ability to produce and articulate units of imperatives.
\nAnother craft is the ability to agree on imperatives. There are several ways to do that. From the simple \"you are being paid to do this\" the the \"We have an implicit alignment of imperatives based on the organizational values.\" From the \"I appreciate your help on this matter\" to \"This is a part of your job.\" And the choice of strategy is orders up depending on the mandate, goodwill, and other hardly measurable elements a relation possesses.
\nAlso, some imperatives are constructive, while some a destructive. Mixing up internally imposed and externally imposed imperatives can have dire consequences for the mental health of people. Letting people think they have a choice, when in fact, they might not be sustainable. This is worth keeping in mind when the leader creates sustainable organizations.
\n"},{"url":"/library-vs-diy/","relativePath":"library-vs-diy.md","relativeDir":"","base":"library-vs-diy.md","name":"library-vs-diy","frontmatter":{"title":"Library vs. Do It Yourself","author":"Mads Buch","subtitle":"On learning and libraries","excerpt":"One reason to not use external libraries is based on the learning outcome of the task","date":"2021-03-06","template":"post"},"html":"Main point: One reason to not use external libraries is based on the learning outcome of the task.
\nThis is one of the persistent questions when developing software. When should\nwe get an external library to solve problems and when should we write the\nfunctionality ourselves. The answer has many facets: What is the security\nrequirement, does it add or reduce complexity, does it pose a recruitment\nrisk, and, in my case, the goal of writing software.
\nI have recently started to implement my own Haskell library to do probabilistic\nprogramming and explore data. There already exists a couple of alternatives\nthough I still insist on making my own. The main reason is that I am working\nwith the cores of probabilistic programming and need to develop my abstract\nunderstanding of the field rather than a concrete competence to use a tool.\nI opt-in for the abstract understanding as professional opportunities within\nHaskell are scarce (even more so in Scandinavia) and I can therefore leverage\nthe abstract understanding cross-technology better.
\nHad this project been developed in a language like Java or C# then it would\nprobably have been wiser to focus on the problem domain, like how to analyze\nspecific data, and defer the development of the tools. In particular, because it\nis easier to leverage tool competencies professionally writing in these\nlanguages.
\n"},{"url":"/minimal-psi-rust/","relativePath":"minimal-psi-rust.md","relativeDir":"","base":"minimal-psi-rust.md","name":"minimal-psi-rust","frontmatter":{"title":"Minimal Private Set Intersection Implementation in Rust","author":"Mads Buch","date":"2023-08-27","template":"post"},"html":"As a toy weekend project I have implemented a minimal version of the private set\nintersection protocol (PSI) in Rust using homomorphic encryption. There are\nnumerous ways to implement protocols to achieve this. Though homomorphic\nencryption is interesting as it gives as asymmetric implementation it is\nalso resource intensive.
\nPrivate set intersection is interesting in a new realm of privacy engineering.\nWith more regulation companies have the responsibility to not reveal data. A\nplethora of new techniques attempts to make that practical.
\nThe main applications are in the ad-industry where companies want to\nintegrate data from different ad-companies without holding to any personally\nidentifieble material. There are also applications in the anti-money laundering\nindustry where banks want to ensure that people are not present in various\nregistries without revealing the person they consider to said registries.
\nAnyways, this is my short exposition from a airport terminal in Munich.\nThe code can be found here.
\nHomomorphic Encryption is the name for the schemes that allow running\ncomputations on encrypted data, which in the game of mathematics means addition\nand multiplication. There are a number of schemes and it is an\nentire research field. To keep this simple, we will merely focus on the\nproperties that we need:
\n$$\n\\begin{align*}\n E(a) - E(b) &= E(a - b) \\\\\n E(a) \\times E(b) &= E(a \\times b) \\\\\n r \\times E(b) &= E(r \\times b)\n\\end{align*}\n$$\nWhere \\( E(x) \\) is the enrypted value of x.\nThese are the ones we will focus on.
\nPrerquisite for this, elements are fixed-width integers. This make entirely\nsense for this field as it is set intersection we are solving. All classes\nof entities can reasonably be hashed to a fixed-width integer.
\nSo! Alice has the number a and Bob has the number b. They want to test whether\nthey have the same number without revealing the numbers (unless they actually\nhave the same number).
\nTo my best knowledge, there are no Rust implementation for tensored\nhomomorphic libraries. It is a tad out of scope to implement that, so for\nthe exposition, we will experiment with the library\nTFHE-rs.
\nFor this to work, the client encrypts the value it wants to check intersection\non and send the encrypted value to the server. In this example, the server only\nallow a single value. But it should be clear that we can run the algorithm\nmultiple times to find the intersection between a client set and a server set.
\n// Hash to test\nlet client_hash = 123456u32;\n\n// Hash is encrypted using the (private) client_key and sent to the server\nlet e_client_hash = FheUint32::try_encrypt(client_hash, &client_key)?;\nprintln!("CLIENT: Encrypts the value and sends it to the server");\n\n// Let the server to its work\nlet server_response = server(e_client_hash);\n\n// Decrypt the returned value\nlet clear_res: u32 = server_response.decrypt(&client_key);\n\nif clear_res == 0 {\n println!("CLIENT: value is in the database 👏");\n} else {\n println!("CLIENT: value is NOT in the database 👎");\n}By virtue of the client secret being encrypted, the server has no knowledge of\nit. It will work on the encrypted value.
\nThe server calculates \\( ((c - db_1) * (c - db_2) * (c - db_{...}))^r \\),\nor ideally should. In this test, we merely multiply on r. This would be\nnon grata for production usage.
\n// Represent a database by a list\nlet server_hashes = vec![...];\n\n// Generate a number to disguise server values\nlet server_r: u32 = random();\n\n// Encrypt the values so we can make homomorphic operations on them. This\n// is not secure and does not require the client key.\nlet e_server_r = FheUint32::encrypt_trivial(server_r);\nlet e_server_hashes = server_hashes\n .iter()\n .map(|&server_hash| FheUint32::encrypt_trivial(server_hash));\n\n// calculate the difference between the server values and the client values.\n// If they are identical, the result will be 0. Multiply it all together, if\n// a single value was zero, the resulting value is 0\nlet test_equal = e_server_hashes\n .map(|e_server_hash| &e_client_value - &e_server_hash)\n .fold(FheUint32::encrypt_trivial(1), |acc, e| &acc * &e);\n\n// Exponentiate on r to avoid releasing information about the servers database\n// Note: We multiply instead of taking the power as no exponentiation function\n// is present and iteratively adding would be too computationally expensive.\nreturn &test_equal * &e_server_r;The resulting value can be decrypted and tested by the client.
\nThis piece of technology fits in the realm of privacy engineering. It is a sub\nproblem of doing generalized privacy preserving operations.
\nIn particular this is one tool out of several that allows to release\nonly specific information in a privacy preserving manner, in this case the\nidentity of an intersecting set.
\nOther tools exists for other types of data. Homomorphic encryption allows for\na broad range of protocols to be build on it due to its general nature.\nUnfortunately the schemes are still slow and for some schemes values decay\nquickly making elaborate computation difficult.
\nAnother tehnique to release data in a privacy preserving way is by using\ndifferential privacy. There are different schemes for\ndifferential privacy though the key idea to to add noise in a way to disquises\nthe original values. In comparison to homomorphic encryption schemes,\ndifferential pricavy works when release data for aggregate analysis.
\nA more practical way would be to take the same path as the BitML people and\nimplement the scheme using TenSEAL\nin Python or another vectorized implementation of homomorphic encryption.
\nTo further understand this field, I can really recommend BitML's article:\nPrivate Set Intersection from Homomorphic Encryption: A Python Implementation.
\n"},{"url":"/probabilities-and-statements/","relativePath":"probabilities-and-statements.md","relativeDir":"","base":"probabilities-and-statements.md","name":"probabilities-and-statements","frontmatter":{"title":"Probabilities and Statements","author":"Mads Buch","subtitle":"On the probability of dying","excerpt":"One should be skeptic when presented by statistics. One way to articulate well-founded skepticism is by following 3 steps of reasoning.","date":"2021-03-04","template":"post"},"html":"Main point: One should be skeptic when presented by statistics. One way to\narticulate well-founded skepticism is by following 3 steps of reasoning.
\n\n\nThe average American is expected to live seventy-three years. Therefore if\nyou are sixty-eight you can expect to live five more years, and should plan\naccordingly.
\n
The above quote is from Nassim Talebs book Fooled by Randomness where he quotes\na journalist for those exact words. Taleb points out the error that one\nconclusion has been moved to another context. The conclusion has been lifted\ninto a higher order without taking that order into account. For this exact example,\nwe see that the expected years to live are used both in a conclusion for all\nAmericans and Americans who already have reached the age of 68.
\nThese pitfalls can be detected and assessed and we can build small programs that\ncan validate statements and to what extent they can be trusted. Like Taleb I\nuse Monte Carlo simulations and follow 3 easy steps to do so:
\nI have done so just with Danish deaths and not the American ones.
\nFrom the Danish institute for statistics, I can download a list of deaths\nfrom 2020dst. The information I get is gender, age, year of death, and, by\ninference, that they are Danish nationals. The list looks like following
\nobservations = [(0, Men),\n ...\n (73, Women),\n (73, Women),\n (73, Women),\n (74, Men),\n (74, Men),\n (74, Men),\n (74, Men),\n ...\n ]where the first number is the age and the middle element the gender. The list\nlong. exactly 54.645 deaths were recorded in Denmark in 2020. From that\nlist we simply draw a random element, that's it. We now have our distribution.\nI like to think of this as the deathRealm. In Haskell it can be defined as\nfollowsmonad.
deathRealmRaw :: P (Age, Gender)\ndeathRealmRaw = uniform observationsWhen we want to calculate the expected age we simply draw 10.000 elements from\nthat list at random and average over their age. When I do that I get\n77.65 years as the expected value. This is a bit different from the Americans'\nexpected age but the idea is the same.
\nThe statement of interest from the quote was the second half:
\n\n\nTherefore if you are sixty-eight you can expect to live five more years, and\nshould plan accordingly.
\n
Understanding the orders is the craft as there might some indirect ones and\nsome direct ones. Regardless, it is mentioned that\nyou are 68 years old, so we will at least incorporate that into our\ndistribution. This is done swiftly by discarding all deaths that do not\nsatisfy that claim that the person is 68 years old. To be a bit more general,\nI built a function that can do this for any provided age.
\ndeathRealmPerAge :: Age -> P (Age, Gender)\ndeathRealmPerAge age = do\n (sampledAge, gender) <- deathRealm\n if sampledAge >= age\n then return (sampledAge, gender)\n else deathRealmPerAge ageIn the code we draw a sample, check if it is more that the declared age. If so\nthen we uge it, otherwise we try again. Again we draw 10.000 elements and take\nthe average of their age.
\n> expectedAge $ deathRealmPerAge 68\n82.76From here we see that expected age is more than 5 year more. Ie. if you have\ndocumented that you are able to reach a certain age, you are expected to\nbecome a bit older.
\nNaturally one is not able to build computational models and evaluate statements\non the fly. But the main takeaway from Nassim Talebs example is the implicit\nlift that was done. Doing that should give som form og skepticism.
\n\nThe death statistics in Denmark for 2020
\n↩\nI have use the probability monad to model the problems.
\n↩\nLet's set up a scenario: We have a company that builds models for machine\ntranslation. The data scientists in work in their own Python notebooks\nand the data engineers take these notebooks and implement them as production-ready\nmodels that can do inference. This process looks something like the following:\nThe data engineer understands the architecture of the production system. She\nrewrites the notebook into an architecturally coherent unit that is being\npackaged as an image. This image is being deployed to the production system.
\nAs an experiment, we are going to do just that. As the example notebook, we use the\nPyTorch tutorial on\nsequence to sequence learning.\nThis notebook needs to be made production-ready for the scalable ml service\nproject as the inference engine for doing French to English translations.
\nThe commit introducing this change is available here.
\nStep one is to make it possible to run the model on the infrastructure using the\nlowest lift. This requires that we export the notebook\nto a stand-alone Python file, we make wrapper code that makes a minimal\ninterface to the transport layer and we package it in a way so that we can\ndeploy it to the infrastructure.
\nWe prioritize getting the system to a working state. This means that we defer\nconcerns about architectural soundness of the code, brittle parsing,\nreadability, etc. We simply need to some something working in a production-ready\nstate (Hey! Sometimes this is even enough, why we should never anticipate\nwork).
\nThe transport layer consists of a RabbitMQ message broker. There is a queue\nfor doing RPC calls which we hook into. In particular, we are listening to the\nrpc_queue-queue. As for the current architecture, the messages sent over\nthe queue are merely the string to be translated and the translation is sent\nback.
To respond to messages we simply use the evaluate function the original author\nhad already put in place and make sure it never fails.
\ndef translateSentence(input_sentence):\n try:\n output_words, attentions = evaluate(encoder1, attn_decoder1, input_sentence)\n return ' '.join(output_words)\n except:\n return "Could not translate. Try 'je vais domir .'"Lastly, we package everything using a Dockerfile in order to run it as a\ncontainer on the infrastructure. This yields and up and running state and\nwe can translate.
\nPlaying around with the minimal setup clearly yields a number of problems.
\nje vais dormir . translates into i am going to sleep . <EOS>:\nWe definitely do not want these special symbols in the output string.Je vais dormir. simply fails. The tokenization is wonky and\nneeds to be updated.To carry out these refactorings, we do the following:
\nnormalize function as was used on the training data.Lang objects: In order not to re-parse the raw training data\nto build an internal representation every time an image boots, we merely\nsave the dumped representations and deserialize it whenever the image boots.We now have an image that translates strings such as Je vais dormir. which\nseems much more natural.
Should we test this code? Or probably a better question: How should we test this\ncode?
\nAs for unit testing, there are arguments for and against it. The arguments\nfor are in particular those of dogmatic nature: We should test because it is\nbest practice. The arguments against are those that this should probably be\nseen as an asset. It is mostly model weights packaged just with enough code\nto run inference and push it back to the client. The production prepared image\ncan be sent back to the data scientist for her to do some final verifications\nthat the code is indeed preserving semantics.
\nHowever, we do want to test this image. In particular we want to test it as\na black box. That we can spn it up, that it returns sensible results when\ninvoked, and that it panics properly when subjected to erroneous inputs, ie.\nthat it closes down so that the infrastructure can spin new instances up.
\nThis is by far a final implementation of a translation model. The output is\nstill not syntactically up to speed. It misses proper casing and spacing\nbetween symbols. Furthermore, it would be advantageous to implement a system\nthat guesses misspelled words. Eg. when writing Je vais formir the system\nshould be able to correct the f to a d_in the formir word. These\nchanges are not going to be implemented in the post.
Furthermore, this image is self-contained and non-persistent. In the\nindustry, it is seen that inference images pull their model weights from\na data store before spinning up. In my opinion, the better solution is to use the\nimage registry for this. There are a number of reasons:
\nUpdated: Noevmber 11th 2022
\nI have relocated to Lisbon to be with the Arkive team and develop the tech\nneeded for the first decentralized museum.
\nI still spend a considerable amount of time writing. I aspire to release more of\nthe notes I have laying around.
\nAside from doing fulltime software engineering, my work is more and more focused\non the society and how decentralized technologies can work in tendam with existing\ntechnologies.
\nOtherwise, by all means write me on me [@] madsbuch [.] com and say hi!
I consider programming languages one of my healthy hobbies. being able to\nclearly formulate logical arguments is of utmost importance as an engineer.\nAfter all, when we claim we are able to implement a solution it should be\npossible to implement. Programming languages span many different areas.
\nThe first aspect of programming languages is semantics. What can we say about\nprograms? How do we build programming languages where we can guarantee\nproperties about a program. The relevant article here are
\nPatterns in programming is also interesting. The programming language always\nexposes patterns. These are typically functions, ie. abstraction and\napplication, but can also be iteration and other control structures along\nwith sequencing as we see in imperative programming languages.
\nLesson #1 from the real world
\nOften, it can be tempting to let a single variable have multiple functions.\nSuch as letting the absence (or null value) denote some boolean decision.\nAn example of such could be for a uid field on an object denoting feedback.\nHere, the initial attempt to model the object could be to let the absence of the field denote whether the user wants notification about feedback received.
However, this makes it hard for another developer to enter developments on the project.\nIf she is tasked with adding reminders for feedback, she will be in trouble: Who is the user, and what is the notification state of the said user?\nThe uid field on the feedback object is optional (nullable), and the comment says that absence means that the user does not wish to receive notifications.
Now the field has one more meaning:\nIf defined, there will be sent a reminder, and the requester will be notified about new feedback.\nOtherwise, no notification and no reminders are sent.
\nInstead, allow multiple fields.\nAvoid conflating diverse meanings into the same field and keep side effects to single fields to a minimum.\nThis enables faster engineering onboarding.
\nPlease remember always to have compassion for other programmers and be\ncurious about lessons.\nAn obvious point for one programmer might be an epiphany for another.
\nOver and out\nMads
\n"},{"url":"/programming-lesson-2-tests-and-streams/","relativePath":"programming-lesson-2-tests-and-streams.md","relativeDir":"","base":"programming-lesson-2-tests-and-streams.md","name":"programming-lesson-2-tests-and-streams","frontmatter":{"title":"Programming Lesson 2 - Tests and Streams","author":"Mads Buch","categories":"Programming Lessons","date":"2021-08-05","template":"post"},"html":"Lesson #2 from the real world
\nWorking with streams is hard.\nIn particular, they are not as composable as I initially thought.\nA small peculiarity is closing streams: I had a stream sink in stdout and kept getting an error.\nIt turns out that closing a stream in the library cascaded.\nHence, it also closed the stdout stream.\nNaturally, my testing library kept writing to stdout which, in turn, yielded a write after close error.
It turns out the solution was to apply good testing habits: A test should not write to stdout.\nInstead, a simple sink was written, and the stream was directed to it.\nThat allowed the increased benefit of measuring the stream and adding assertions to have the stream is expected to behave.
Sometimes problems can be solved by progressing over them. Weird.
\nPlease remember always to have compassion for other programmers and be\ncurious about lessons.\nAn obvious point for one programmer might be an epiphany for another.
\nOver and out\nMads
\n"},{"url":"/project-portfolio/","relativePath":"project-portfolio.md","relativeDir":"","base":"project-portfolio.md","name":"project-portfolio","frontmatter":{"title":"Project Portfolio","template":"page"},"html":"This page contains the projects and examples I have been doing.
\nCurrent Projects:
\nExpositions:
\nWritings:
\nThis blog: General writings. I am in particular proud of following\npieces:
\n\nLegacy:
\nThe most exciting property of the blockchains is that they allow us to bake state\ndirectly into open, transparent protocols. This means that we can build\nprograms where everyone can, not just read the source code, but also trust\nthat the running program adheres to that source code.
\nThis means that we can build open protocols without needing to trust any single\nparticipant. Not just for its working, but also its state.
\nSo what types of protocols is this useful for?
\nThe protocols listed above are special in the sense that they require two\nthings. 1) soundness of interaction: only I can vote or transfer money on my\nbehalf (unless I explicitly allow otherwise) and 2) completeness of\ninteractions: When I cast a vote or transfer money, it stays like that.\nBlockchain protocols allow developers to make protocols to adhere to these\nelements.
\nStateful Protocols: Blockchains allow for states directly on the protocol.\nThis allows us not only to make sure that the state we have recorded is\nauthentic but also that no state has been lost.
\nWe have long been able to ensure the integrity of messages using cryptographic\nsignatures. What blockchains allow us is to record the completeness of messages\nby recording them in blocks that are committed and can not be altered.
\nThe canonical example is voting: Using traditional cryptography, we can ensure\nthat votes that are cast are authentic. But recording these with a single\nauthority would also allow votes to be dropped without anybody noticing.\nBlockchains can guarantee that no votes are dropped. This is essential to\nhave an honest voting system.
\nTransparency: Open source software solved the source-code transparency.\nFor all public projects on GitHub, we can see their source code. But that does\nnot guarantee that the code the computers run is the same as the source code.
\nBlockchains solve this problem by distributing the source code to all nodes\nthe blockchain is running on. Every time somebody interacts with the\non-chain program all nodes run the code and verify they get the same result.
\nThe support DAO: Programs need upgrades. If the program runs a currency,\nwe might need to change the interest rate. If it runs a provenance protocol\nwe need to be able to change provenance events when a new consensus is achieved.\nTo do this, protocols set up their own DAOs or distributed autonomous\norganizations, which are the stewards of the protocol. They discuss and decide\non the changes to go in. How DAOs work is different from DAO to DAO. Currently,\nthey tend to use a governance token that can be used for voting and is\ntradable on a secondary market.
\n\nCentralizedness of the blockchain: Folks raise concerns about\nto what extent blockchains are centralized. There have been several examples\nof blockchains that can be controlled by a single entity.\nThis is a huge concern for open protocols when transactions are\nbeing rolled back. But this is also an isolated concern. The blockchain\nis the technical infrastructure and can be changed. Ie. these concerns should\nnot be a game-stopper for the development of this technology. However,\nit should be considered another problem that is being solved as we speak.
\n"},{"url":"/proving-stuff-in-haskell/","relativePath":"proving-stuff-in-haskell.md","relativeDir":"","base":"proving-stuff-in-haskell.md","name":"proving-stuff-in-haskell","frontmatter":{"title":"Proving Stuff in Haskell","author":"Mads Buch","date":"2016-10-27","template":"post"},"html":"Main point: Haskell has the capacity to carry out proofs as languages.
\nupdated april 2021 for clarity.
\nThis article is my give on the relationship between mathematical proofs and\nprogramming languages. Many details on specific implementation have been\nleft out with the aim for clarity and conceptual coherency.
\nThe source used in this article is available as\na Gist.
\nWhat is a proof? A proof is a series of deductive arguments, such that the\nproposition is justified. This description might seem quite\nabstract, so let us look at a concrete example using the Peano naturals for\nrepresenting natural numbers (here written in number syntax).
\n$$\n 1+1 = 2\n$$\nAs the proposition has no quantifiers, we can directly begin to reduce on\ndefined operations. For Peano numerals addition (+) is well defined and we\ncarry out steps as long as it is possible. In the end we should arrive at\nsomething akin to
\n$$\n 2 = 2\n$$\nWe still have a mathematical object, a propositional claim.\nWe know from the Peano axioms, that\nsyntactical equivalence satisfies reflexivity, symmetry, and transitivity.\nHenceforth the properties of equality are satisfied, and we end our\ndeductive sequence. QED.
\nThis can be translated into programming utilizing the type system to verify that\nwe are not \"cheating\" on deductive arguments. This translation has basis in\nwhat known as the Curry–Howard correspondence.\nFrom that we know that propositions corresponds to types and proofs corresponds\nto programs. Alright, so we need to make an expression that has above\nproposition as its type, and an implementation that satisfies the type.
\nFirst, we need to define our objects: Peano naturals and Equality. We implement\nPeano naturals the usual way. I elaborate on this in a\nprevious post.\nEquality is defined as follows.
\ndata :~: where\n Refl :: a :~: aWe can see that the value Refl is the only inhabitant of the type a :~: b.\nFurthermore, it only inhabits the type when a and b are identical.\nConcerning the Curry-Howard correspondence, the Refl value also\nhas the unit type - it is not possible to attach further data to\nthe constructor.
We have defined equality in terms of reflection. However, we need equality\nalso to satisfy symmetry and transitivity. In the source, we have the code\nneeded for that.
\nWe now want to make the type for our proof, or, the equivalent to the\nproposition stated above:
\nonePlusOneEqualsTwo :: Add (S Z) (S Z) :~: S (S Z)The Add in the type definition is a type family defined in the source. It is\ndefined as we would usually define addition over Peano naturals.
To prove it we need to make an inhabitant to that type. The program\nis very simple\nfor this case as the Haskell compiler reduces the type level expression\nper semantics of type families.
\nonePlusOneEqualsTwo = ReflAs it compilescompiler it shows that Haskell is content with the proof.
\nReusing proofs seems like a convenience, though it is completely\nnecessary for some classes of proofs. These are namely the\nproofs by induction which we will have a look at later. For this to work\nwe need to be able to lift a proof into Haskell's type solver.
\nWe do that by the gcastWith operator. This operator has the type\nsignature gcastWith :: a :~: b -> (a ~ b => r) -> r. It should be read\nas something like: Given a proof that a equals b, use that fact to decide\nif the type r is solvable and return the proof for r.
We want to abstract our proofs. In proving terminology, we do this through\nquantifiers.
\nTo have a more graspable problem that includes only quantification,\nwithout induction, we detour to boolean algebra. Here we can\ntry to formalize De Morgan's theorem:
\n$$\n \\forall a, b \\in : \\lnot( a \\land b ) = \\lnot a \\lor \\lnot b\n$$\nhere a and b can only assume two values, true and false.
\ndeMorgan :: SBool a -> SBool b -> Not (And a b) :~: Or (Not a) (Not b)\ndeMorgan STrue STrue = Refl -- The first case\ndeMorgan STrue SFalse = Refl\ndeMorgan SFalse STrue = Refl\ndeMorgan SFalse SFalse = ReflWe simply provide an inhabitant to the type based on\npattern matching. This is the same as proving by case analysis.
\nTo understand what goes on we instantiate the type expression\nin each case. Afterward, the compiler reduces per the semantics\nof the Not, And, and Or type families. In the first case we instantiate\nthe type expression such that.
deMorgan :: SBool Tru -> SBool Tru -> Not (And Tru Tru) :~: Or (Not Tru) (Not Tru)This instantiation is from the value STrue which has the type SBool Tru.\nThe compiler then reduces the expression and derives that\nRefl :: Fls :~: Fls. From the interpreter, we get that.
*Proof> :t deMorgan STrue STrue\ndeMorgan STrue STrue :: 'Fls :~: 'FlsMany interesting properties we want to reason about includes unbound data.\nThat is, the data we think about is inductively defined. We now go back to the\nexamples considering natural numbers as they are a good medium for\ndiscussing inductively defined data.
\nplus_id_r is the property that adding zero to\nn on the right side is the identity of n. plus_id_l is when we add 0\non the left side.
plus_id_l is given directly from our definition of addition. But plus_id_r\nneeds to be proven, and we can do this inductively using following code.
plus_id_r :: forall n. SNat n -> (Add n Z) :~: n\nplus_id_r Zero = Refl\nplus_id_r (Succ x) = gcastWith (plus_id_r x) ReflThe first case is the base case. We know that the value is Zero and\nhence we can derive the type to Z. It is immediately visible that Refl\ninhabits the type Refl Z Z.
The next case is the induction case. Here we fold out the value such that if\nn = Succ x, then x = n-1 - we reduce this on our argument. We justify that\nRefl also is an inhabitant in this case by calling plus_id_r on the\nreduced value.
It is indeed possible to prove stuff in Haskell. But it is not further\npractical. The reason is in particular because the language\nis not designed with\nthe constructions we need, such as dependent types. We simulate\nthem through GADTs.
\nThe closest languages to Haskell that are suited for\nthis is languages such as Idris and Gallina (Coq). They have all the facilities\nneeded for incorporating proofs into one's code.
\nIf one has a software\ndevelopment background firmly grounded in OOP (Java, C#), it requires quite\nsome time to wrap one's head around the new way to understand types.
\nThat we can do above is mostly of academic interest: How do make sure that\ncertain compilers indeed do what they should do etc. But the techniques are\nbecoming steadily more accessible to all programmers.
\nNew languages, like Idris, come with type constructions to formally\nreason about our software.
\nFirst, thanks to Aslan Askarov for providing\nvaluable feedback on this article. It has been incorporated to provide a\nmore coherent article.
\nThis article was a precursor for a presentation at a\nspare time teaching event\nat Aarhus university. Thanks to them for letting me host the presentation.
\nAlexandros Peitsinis has written a much more in-depth article on this subject.\nIf this article intrigued then take a look at his work.
\n\nWell, we need to set some compiler flags to make sure that all cases are covered.
\n↩\nQuestions are to Data Science what User Stories are to Applications. That's it.
\nWhen developing user-turned applications, user stories is a tool to make sure\nthe implemented user interface is aligned with the users expectations.\nThey focus the development towards what is important and allows to filter\nout tasks that are not supporting the user stories.
\nThe same is the case for data science: A team puts forward a number a questions.\nSome grand questions, and some smaller one that lead to the answer to the\ngrand one. Having those questions in mind always aligns the data scientist\nwith their stakeholders.
\n"},{"url":"/reliability-engineering-in-startups/","relativePath":"reliability-engineering-in-startups.md","relativeDir":"","base":"reliability-engineering-in-startups.md","name":"reliability-engineering-in-startups","frontmatter":{"title":"Reliability Engineering in Startups","author":"Mads Buch","date":"2024-03-09","template":"post"},"html":"Draft
\nI am currently working in a startup where a part of the value proposition is a resilient product.\nThe product is used in an interactive setting between a seller and a buyer and manages compliance requirements in this phase.\nAs such we can not afford to be down in this phase.
\nStartups are typically characterized by being resource constraint such that all team memebers need to do diverse tasks.\nFurthermore, the requirements tend to chance fast
\nWe have, at least, 6 different shields we can use when considering reliability.\nEach of the shields will defend certain attacks an adversary can have on the product.
\nThe shields are as the following
\nFor each of these shields a team can decide to invest more or less resources into it.
\nIn startups the key is to manage the amount of effort that foes into each shield.\nThe resources allocated should be proportional to the requirements from the business.\nNot more, not less.
\nFor each shield there is the free tiers, the paid tier and the enterprise tier.
\nThe free tier is where it takes the same amount of resources to do it as to not do it - given a software developer that has basic training.
\nThe paid tier is where certain rules are applied in shield as a response to certain issues that has been observed.
\nThe enterprise tier it to dogmatically use state of the art techniques or to go above basic requirements in order to solve large classes of issues that has never been experiences.
\nFor the typing shield: The free tier is to use a types programming language and stick to its typing primitives.
\nThe paid tier is to model business logic in types to the extend that this removes issues that has been seen in production.
\nThe enterprise tier for typing would be to use special languages or DSLs to model parts of the domains in order to ensure that incorrect code can not be deployed.
\nTypes
\nTests:
\nArchitecture
\nRequirements:
\nMonitoring
\nProcesses:
\nMoving tiers is a response to two things: Resource allocation and need.
\nThe free tiers are typical for new startups or small projects with small teams.
\nThe paid tiers are typically a response a growing team or a requirement to develop features faster.
\nThe enterprise tier is called so because it is often in enterprises these are needed.\nThey are characterized by being resilient to employee churn. But they are also known to such out the lives of the team participants.
\nThe main thing is to understand the associated costs by moving up a tier.\nFor a lot of owners and projects managers in might seem to be beneficial to employ the enterprise tier on the process when starting new projects.\nHowever, the result will often be alienated teams with low performance and a lot of asks on cleaning up code.
\nReliability issues can often be solved using various shields.\nA common example would be to use typing, but rely on some sort of manual testing to catch the errors occurring from the missing types.
\nProcess shields are typically easier to setup. They don't require changing code and their risk is low.\nFurthermore, these can typically be done by non- engineering members of the teams.
\nThe down side, however, is that a team can only lift so much process. So process mitigations ought to move into the other shields as time pass.
\n"},{"url":"/reusing-insights-with-ai/","relativePath":"reusing-insights-with-ai.md","relativeDir":"","base":"reusing-insights-with-ai.md","name":"reusing-insights-with-ai","frontmatter":{"title":"Reusing Insights with AI","author":"Mads Buch","subtitle":null,"date":"2021-07-13","template":"post","excerpt":"..."},"html":"You work in a big organization, thousands of suppliers, and tens of thousands of\ncontracts. Your goal is to save some bucks in the company. But how do you do\nthat? Start by reading one contract after another and see if there are new\nsuppliers with better deals? This requires an extensive toolbox!
\nIn the company, a project to find similarities for products is commenced. The\nidea is that we can figure out whether two products serve the same purpose\nif they result from the same need. When that is discovered, we can\ndecide to prioritize the cheaper option over the more expensive one.
\nThe project goes well. The algorithm is developed, a huge list of obsolete\nproducts is constructed and implemented in the procurement system. Now it will\nflag the cheaper option to the user every time the expensive one is requested.
\nBut was that it? Is the code for the product abandoned now? The final asset was\nthe code that recommends the cheaper option, but there is much more value\nto take home from the constructed code. Imagine that another team, later on,\nneeds to find some suppliers for a given product to support a need. The\norganization has the policy to get quotes from at least five suppliers to get the\nbest price. Now, they decide to set up an algorithm that\ncan find similarities for products to find related products to get a quote on.\nSomething a system to reuse existing insights could have saved.
\nIn order to reuse these insights, a knowledge graph based system could have\nbeen employed. The code written in the first project would have been made into\na pipeline that takes products already present in the knowledge base and sets\nup new relations based on their similarity. Eg.\nPen A -- canBeExchangedFor --> Pen B or\nHeadPhone A -- isSimilarTo --> HeadPhone B.
This layer is committed to the layer repository for the organization such that\nwhenever the next team comes around and ask the system to generically find\nrelated suppliers, the system will utilize these product relations to make\nrecommendations.
\n\nWhen the knowledge base is constructed correctly we can keep adding new insights\nwithout cluttering anything up. The knowledge base should realize a\nmulti-ontological view of the world such that it can reuse insights from one\ndomain in another domain without the system feels unstructured to work with.
\n"},{"url":"/sample-code-guidelines/","relativePath":"sample-code-guidelines.md","relativeDir":"","base":"sample-code-guidelines.md","name":"sample-code-guidelines","frontmatter":{"title":"Sample Code Guidelines for a Typescript Project","template":"page"},"html":"This is a set of demo code guidelines for a Typescript project. They are used to exemplify how I go about writing code guidelines.
\nWhile Typescript is only rarely mentioned, each language have weaknesses and strengths. Code guidelines are a set of rules that in\nparticular mitigates the weaknesses of a language.
\nContext: The entire code base
\nAdvice:\nPrefer to keep code close to where it is used. Eg, when writing a utility\nfunction that turns an enum \"FINANCE\" into the string \"Finance\" refrain\nfrom putting that into a utility code. Instead put it in the same file\nwhere it is used.
\nSome qualification of this rule:
\nutility.ts (or _utility.ts in the page hierarchy)\nand save it there.If the semantically equivalent function is need somewhere else in the code, find\na place that is between these place.
\nAdvice: When there are two competing solutions that solve the same problem. Choose the simplest one.
\nContext: Local and complex data structures used for rich user interaction.
\nAnti-context: Database models, API data structures.
\nAdvice:\nPrefers using sub objects indexed using a intrinsic ID of each elements.
\n[\n { id: "abc",\n elements: [\n { id: "123",\n field: "value" }\n ]\n }\n];vs.
\n{\n "abc": {\n id: "abc",\n elements: {\n "123": {\n id: "123",\n field: "value"\n }\n }\n }\n}The former requires complex iteration if we want to update the value in a type safe manner while\nthe latter requires v[\"abc\"].elements[\"123\"].field = \"New Value\".
Extra notes:
\nObject.values(v) and we are back!UUIDv4Context: API development (GraphQL here)
\nAdvice: Prefer that API that POST or Mutate data does not return the entity in question.
\nBackground: Systems at scale takes time to propagate change. This is usually not long time\nbut enough that we don't want to wait for it being written to the database before we can respond\nin the API.
\n"},{"url":"/planning/","relativePath":"planning.md","relativeDir":"","base":"planning.md","name":"planning","frontmatter":{"title":"When there is nothing to do, there is planning to do","author":"Mads Buch","date":"2022-01-06","template":"post","excerpt":"Maybe the first item on the ignition list is to build the ignition list?"},"html":"\n\nLet all your effort be directed to something, let it keep that end in view.\nIt is not activity that disrupts people, but false conceptions of things that\ndrive them mad.
\n
– Seneca, on tranquility of life, 12.5
\nOne of the hardest problems of building something large is reducing it to\nmanageable bits and pieces that can be made in the time between meetings for\nactual work, or in the after-hours for side gigs and spare time projects.
\nOne thing that often puts off people working is not having any of these\nmanageable bits to finish up. Another thing that can put of working on a\nproject is being at the mercy of the road map already planned 10\nyears ahead.
\nIt’s a balancing act.
\nOne thing that is for sure is that important projects need traction.\nThey need regular attention, also when everything else in life comes\ncrashing down. When a project gets attention, it is so much easier to get\ncaught up in the project the days when the stars align and we get into the flow.
\nMaybe the trick is to have an “ignition list”. A list of small pieces of work\nthat can be done in half an hour or so. For the stressful days, this is merely\nwhat is done. For the other days, these items are what ignites the flow process.
\nIt is kind of leaving a small fixable syntax error in the code overnight.\nThis ensures something easy to get started with in the morning bootstrapping\nthe day.
\nMaybe the first item on the ignition list is to build the ignition list?
\n"},{"url":"/scalable-ml-service/","relativePath":"scalable-ml-service.md","relativeDir":"","base":"scalable-ml-service.md","name":"scalable-ml-service","frontmatter":{"title":"Scalable Machine Learning Service","author":"Mads Buch","subtitle":"To deploy large-scale machine-learned models, we need to be careful about our architecture.","date":"2021-04-05","template":"post","excerpt":"Machine learned models can be really big, like the multi-billion weight GPT models; there is a chance they contain sensitive data, and their output needs to be sanitized or something third. This post is on the fundamentals of a scalable ML architecture."},"html":"\nMachine learning is becoming ubiquitous. More and more services rely on\nit, and while embedded systems increasingly can run the models\nthemselves, there are good reasons to execute models in the cloud. Models can\nbe huge, like the multi-billion weight GPT models; there is a chance\nthey contain sensitive data, and their output needs to be sanitized or something\nthird. This post is on the fundamentals of a scalable ML architecture.
\nAs a demo, I have implemented the core of a scalable system to build on online\nAPI to execute a model. The architecture is relatively straightforward: We use an\nElixir frontend, which is expected to carry out responsibilities like\nauthentication etc. We use RabbitMQ as a queue system and a Python service\nto execute the models.
\nFirst, the code is available at GitHub.\nPrincipally, there are three components to pay attention to: The Elixir GraphQl\nAPI server, the Python model runner, and the infrastructure defined in\nrespective docker files and the docker-compose.yml.
The application server is a standard Elixir Phoenix setup using\nAbsinthe to handle the GraphQl interface and AMQP to handle the interface\nto the RabbitMQ message broker. One of the things to keep in mind for services\nthat are a part of a more extensive setup is that we need to develop it and test it\nin isolation. Hence the module that implements functions for RPC over RabbitMq\nid mocked and has an IO implementation that merely echoes what it gets. This\nyields a solution where the only code that can not be tested on the service\nlevel is the production implemented of the RPC module, which is sufficient.
\nWe use a machine-learned model written in Python using PyTorch. The example\ncode is moved over and augmented by the glue, making it responsive\nto new requests in the queue.
\nLastly, everything is orchestrated using docker-compose. this includes\nDocker files for each project and a docker-compose.yml file to start\neverything.
When developing complex solutions, there are a plethora of concerns to be\nthoughtful about. These are simply some of them.
\nAPI design: The API has a single query to translate. This choice is mainly\nfor convenience and can certainly be challenged. We would probably use mutations\nfor ML model invocations as they have sufficient side effects. For some models,\nit might return different outputs per invocation, and for all cases, it incurs\na const to invoke why we probably want to avoid letting clients re-invoke\nseveral times as retry strategies.
\nIndirection: Using a queue system introduces indirection. Signals are sent,\nand we wait for the return. These systems do not have any runtime call stack,\nand it is even less so possible to follow a call in the code editor. Ie.\nIndirection makes code harder to read. Use indirection sparingly and only when\nthere is a good reason.
\nScaling: The core decisions have been made for this architecture\nto scale. We can freely add as many model runners to the system as we see fit.\nA natural next step would be to add auto-scaling to the model runners in order\nto respond fast in peak time and save money when demand is low.
\nModels: In this example, the model weights have simply been added\nto the docker image. If the model is updated, it is an orchestration concern\nto make sure that the running containers are updated. This should be as\nstraightforward as just starting new containers and signal the old ones to shut down.
\nHowever, if we have large enough churn on the models, say we have individual\nmodels per user, we probably need another strategy. Depending on the use case,\nwe might let all the models run in parallel and have multiple topics in\nRabbitMQ or we can download models as files on demand and cache them.
\nThis implementation is representative and by no means production-ready.\nA lot of tweaking is needed to be done. However, it shows the basic\nstructure for services that has a disconnect between resource-intensive parts\nand light resources.
\nWhen developing these types of infrastructures, it is expected that they will\nchange when exposed to real-life usage patterns. Furthermore, this simple\nexample touches on many different technologies. In a scale-up scenario, this\nsystem would probably be managed by at least three people: the data scientist/engineer\ndeveloping the model runner, an application engineer developing the API\nservice, and somebody with the infrastructure as their primary concern.
\n"},{"url":"/spor/","relativePath":"spor.md","relativeDir":"","base":"spor.md","name":"spor","frontmatter":{"title":"Spor","template":"page"},"html":"Spor was a, now closed, knowledge base startup.
\n"},{"url":"/tech-debt-tax/","relativePath":"tech-debt-tax.md","relativeDir":"","base":"tech-debt-tax.md","name":"tech-debt-tax","frontmatter":{"title":"Tech Debt is Tech Tax","author":"Mads Buch","date":"2023-06-17","template":"post"},"html":"There is this saying about tech debt: When you move fast in a software team,\nyou build up debt that you must pay off later. The engineering team uses this\nto get a break and align the current understanding of the product with the code.
\nThe TL;DR of this post is that it is often inaccurate to talk about tech debt.\nInstead, we should consider the tax a project accrues –\nA self-incurred tax based on the decisions and culture of an organization.
\nTraditionally, tech debt is understood as the \"short-cuts\" an engineer makes\nto reach a solution. Sometimes these are actually short-cuts, but rarely.\nThere is usually a deeper meaning to this introduction of tech debt and it can\nbe divided into the following categories:
\nThese elements are all completely natural and will happen in all software\nprojects regardless of size. However, I think this notion of debt is flawed.\n\"Debt\" can be fully settled however \"tech debt\" can not.\nDebt has a single-dimensional target: to reach 0 in owed funds. The above issues\ndoes not.
\nThough the word debt somewhat works, I think the notion of a tech-tax is more\nfitting for a number of reasons:
\nSoftware engineers need to prioritize tasks that does not yield business value.\nThese are a tax. But how is the tax decided?
\nArchitecture tax: In some teams, members have a high variance\non architectural aspiration leading to architectural incoherency.\nSome teams can handle spaghetti code while others struggle to even release\nminor updates or onboard new engineers. They should pay more in taxes on the\narchitectural incoherence.
\nA team should allow incoherence and learn from it.\nI spend some hours a week to remove unused code, and do various refactorings.\nBut to what extend this should be done is teams specific? Some teams prefer\nmore individual freedom while others prefer stronger rules on the architecture.\nKnowing what the architectural target is, is a good start, without being\ndogmatic about implementation.
\nInfrastructure tax: The infrastructure is necessary as a software\nproduct does not run without it. But there is a vast difference in running\na static website on Netlify and setting up an entire cluster using\nTerraform and Kubernetes. However, a company is forced to pay the\ninfrastructure tax when the product is being used. The more usage,\nthe higher tax.
\nIn my experience, to manage the infrastructure tax, the infrastructure should\nbe implemented for realistic usage (as opposed to ideal or aspirational).\nThere are no reasons to build out\na microservice architecture before it has been proven that there is a need. Make\na monolith. When the product is successful, there are usually also more funds\nto pay extra on this tax.
\nRequirement tax: Requirements change. The app changes. Everything changes.\nMaking sure that all new and existing features live up to requirements, and\nchanging requirements, imposes a tech tax. In particular in larger organizations\nwith dedicated QA teams to discover these discrepancies.
\nTo counter this tax, take one step back and look at who you are developing for\nand what you are developing. Are satisfying requirements becoming a bureaucratic\nexercise? Or does it solve actual business needs? Product leads should appreciate\nwhen engineers push back on features or requirements. Take the time to really\nunderstand why a requirement is important.
\nMost software engineers get exhausted by doing things that do not move the\nneedle. Spending days implementing an animation widget that is seen by only\na handful of people. Maintaining a Kubernetes cluster with less than a single\ndaily visitor. Not only are these bad business expenses, but they are also\nhard for the software engineer.
\nPeople tend to enjoy meaningful work more. Managing tax will yield a better\nproduct for less cost at higher flexibility and higher velocity.
\n"},{"url":"/tech-lead-philosophy/","relativePath":"tech-lead-philosophy.md","relativeDir":"","base":"tech-lead-philosophy.md","name":"tech-lead-philosophy","frontmatter":{"title":"Tech Lead Philosophy","template":"page"},"html":"This document outlines my philosophy on technical leadership. Its purpose is twofold:
\nNot everything is always perfect. It's entirely okay for not all aspects of the project to be constantly perfect. Priorities are set in collaboration with stakeholders, and aspects of the project that do not directly align with key objectives should be accepted or validated against the priorities.
\nCase: Instability:
\nProblem: The platform is unstable.
\nBusiness Objectives: Feature velocity.
\nApproach: Initially, it must be accepted that the platform is not stable. However, it should constantly be validated whether the instability hinders business objectives of feature velocity. If so, the platform stability should be adjusted to a state where it no longer obstructs the objective, but no more than that.
\nStakeholder Alignment: We don't have a stable solution as long as this is not prioritized. It can be prioritized, but it will affect other objectives or require more resources.
\nLeading a project is about setting direction. For example, if there are inappropriate constructions in the code, more suitable patterns should be devised. The new patterns should be documented, disseminated, and integrated.
\nCase: Component Properties
\nProblem: Bugs often occur because properties are not set on components. Our data model allows a lot of data to be optional, and a decision was previously made to accept optional properties on components deeper in the hierarchy.
\nApproach: Find a pattern that eliminates the error vector inherent in having optionality. This can be done by creating a sum type that either takes the optional value or a \"value does not exist\" value.
\nStakeholder Alignment: Co-developers should know that this is the construction we will use in the future. It should be clear that if a property on an object is not optional, this pattern should be used.
\nSoftware development is a journey. Decisions have previously been made consciously or not, and oftentimes we see the effects later when the decision has had severe impacts. However, it is important to understand the grounds for the decisions that have been made. This should be done in a way that evokes no defense. It is important to be conscious and compassionate about the situation and open-minded about the reasons.
\nEach team member generally own their own code. This is something to be proud of and something to be responsible for.
\nNot all projects should be led in the same way. A significant part of managing a project is identifying gaps and filling them. In particular, these gaps are highly dependent on the resources available to a project and the objectives of the projects.
\nThe landscape of methodology is large. Some work well in certain teams and contexts. I have had success using the following methods:
\n...to work on ideas from inception to buy-in.
\nWriting code is like playing the piano. A pianist does not consider each individual key strokes but rely on practiced chord progressions.
\nIn software development team, nobody gets to be Beethoven. Instead we share and maintain a list on what good chord progressions are - the code guidelines.
\nWhen writing software the importance of rule-adherence is as the following:
\nCode guidelines take into account that there might be certain circumstances where this does not make sense.
\nI work with code guidelines are demonstrated in my sample code guidelines for a typescript project.
\n"},{"url":"/statistics-knowledge-graph/","relativePath":"statistics-knowledge-graph.md","relativeDir":"","base":"statistics-knowledge-graph.md","name":"statistics-knowledge-graph","frontmatter":{"title":"Proposal - Statistics on the Knowledge Graph","author":"Mads Buch","subtitle":"Execute probabilistic programs on the knowledge graph.","excerpt":"If we are a bit careful about provenance, we can view a knowledge graph as the virtual machine for a probabilistic program with the ontology defining the semantics.","date":"2021-06-27","template":"post"},"html":"TL;DR: If we are a bit careful about provenance, we can view a knowledge graph as the virtual machine for a probabilistic program with the ontology defining the semantics.
\nThe fundamental idea is that we can write programs in a simple probabilistic programming language. As such, we require the probability monad as the only composition pattern for the language. We allow functions, written as distributions, to draw from themselves to yield the possibility of traversing inductive structures. In the end, we wite distributions over entities.
\nWe provide an expectation function. This function takes a distribution and a measure function and returns the average measure over the distribution. An example could be on companies, and the measure function would yield 1.0 when the company is bankrupt and 0.0 when it is not. The result would yield the weighted proportion of bankrupt companies in the distribution.
\nBuild-in operations are based on the meta ontology. Here we define what values properties of an ontology can take. An example is a text-field. This will have an equality function. Another property could be a location-field. These could have an in-range operator such that we can write in-range (location company) (location address) 50m or the like.
We augment the system with two basic distributions — one for the ontology classes and one for entities. The first one yields random elements at uniform distribution from a class, the second one yields exactly and only the entity from which it has been constructed — It is the singleton distribution.
\nFurthermore, relations between classes in the ontology represent functions from distributions to distributions. A scenario is when we have a knowledge graph representing companies with a hasEmployee relation liking companies to persons. The language would provide a function hasEmployee : Dist Company -> Dist Person, which from a distribution over companies returns a distribution over persons.
Lastly, error handling: Distributions might be empty. Handling those empty distributions in different ways can have a tangible impact on the resulting distributions, and we need to be careful about how we do it. In the initial version of the language, we handle these situations explicitly in order to surface decisions.
\nOutside of the core language, there are some concerns we also need to address in the execution system. One such is provenance. The statistical results are only as precise as the data program is run on. A library is made available to create the dataset (execution runtime). This library comes with many tools to ensure the soundness and completeness w.r.t. to the data source and ways to indicate the soundness and completeness.
\n"},{"url":"/the-mvp-engineer/","relativePath":"the-mvp-engineer.md","relativeDir":"","base":"the-mvp-engineer.md","name":"the-mvp-engineer","frontmatter":{"title":"The MVP Engineer","author":"Mads Buch","subtitle":"An engineer creating minimum viable products.","excerpt":"An MVP engineer helps scope a product, build the product to verify its business potential, set up a team and lastly scope a road map for further product development.","date":"2021-02-23","template":"post"},"html":"Main point: The MVP engineer is a part of the initial team who scopes out a product, builds the first iteration of the product to verify its \"raison d'etre\".
\nA minimum viable product is a minimal implementation of an idea. An\nimplementation that can verify the value-add of the idea. This first\nimplementation should be cost effective while implementing the core features\nand functionality required to decide whether to continue on developing the\nproduct or to reject the hypothesis.
\nThe MVP engineer is one of the core people on the team making this happen. This\nperson undertakes the technical responsibility for this phase in the product\ncycle.
\nBefore the MVP engineer comes almost nothing. The only thing that precedes the\nMVP engineer is the decision that a product should be made and some vague\nideas on what kind of value the product should provide. The MVP engineer will assist\nin scoping initial versions and build them to validate the business potential.
\nThe MVP engineer is an expert in this initial phase of a product life cycle.
\nTechnically, the MVP engineer is a one-stop-shop and does what it takes to\nbuild the product: Application development, continuous integration, external\nintegrations, machine learning, smart contract development, etc. The person\npossesses all competences required to build this initial product that\nshowcases viability.
\nConsequently, this also means not attending to a lot of other concerns. What\nconcerns these are are unique to the project. An example is scaling concerns\nthat are deferred to the point where the product scale is eminent.
\nAnother one is the architectural elegance, or architectural clarity.\nThe point is, that MVPs tend to pivot heavily in the initial phases.\nInvesting in the architecture at this points risks imposing\nthe sunk cost fallacy – Nobody likes to throw out a big investment.
\nThe MVP engineer makes it easy to kill your darlings and retains the\nproject scope at a level where this is easy.
\nShould the project reach a validation point where further development is needed\nthen the MVP engineer takes the project into the next phase.\nThis is important as knowledge needs to be handed over and a team culture\nneeds to be built around the mission. Hence, the MVP engineer will do\nrecruiting and engineering interviews, and hire for the new technical roles.\nThe engineer will also disseminate knowledge about the tech stack and the\nproject to new participants to ensure the productivity of the team.
\nThe last thing the MVP engineer does is scoping further development not to\nleave the product in a vacuum and also recognizing the elements that were\npreviously not attended to, but are important to ensure the success of\nthe product.
\n"},{"url":"/three-pillars-of-software-development/","relativePath":"three-pillars-of-software-development.md","relativeDir":"","base":"three-pillars-of-software-development.md","name":"three-pillars-of-software-development","frontmatter":{"title":"The 3 Pillars of Software Development","subtitle":"On implementation, tests, and verification","excerpt":"Decomposing the testing process quickly shows that it consists of two components. First a specification is formulated, which is later verified.","date":"2014-10-01","template":"post"},"html":"Test driven development is for many programmers a well-known concept.\nTests are written, and procedures are implemented trying to satisfy the tests\nproviding in a little green mark. When the green mark is not easily obtainable,\ndivide and conquer is applied with more and easier tests.\nIn this article, I try to decompose the process of testing to that of specifying\nand verifying. I relate this notion to places where verification are\nmathematically used to bind a specification and an implementation.
\nIn the software development community, it has become obvious that software has to\nbe tested. The reasons are in plural: Keeping a maintainable codebase, assurance\nof software correctness, up-to-date documentation, continuous\nsomethingcstar, etc.
\nFor me, the two most important reasons to do software testing are the following:
\nIn the above I did a slight transition from using the term testing to use the\nterms specifying and verifying. Decomposing the testing process quickly\nshows that it consists of two components. First a specification is formulated,\nwhich is later verified against the actual implementation.
\nThis split is necessary to be able to talk about the process in a broader term.\nWithin proven software, specifications are mathematically proven to be\nimplemented in a correct manner, hence the term testing is too vague (at least in\nmy consciousness) as we do not necessarily test a finite set of the input for a\ngiven procedure.
\nImplicitly, and now explicitly, I advocate testing. My opinion is that testing\nshould take up as many resources as implementing. Of course, this opinion is not\nstrict, and many conditions are in play when deciding the number of resources\nspent on verifying code. I trust the reader in knowing when to test. At least,\nit is not the main aim for this article.
\nI have drawn examples from two worlds: One from the engineering world\nrepresented by examples in Java. The other one is Coqcoq. Coq is a theorem\nprover performing formal proof verification. That means that we can be sure what\nis expressed also holds.
\nThe premise for the article is now set, and the three pillars can be\nintroduced. I will allow to start with the specification. Intuitively it might seem\nmore obvious to start with implementation as it is the most commonly thought of\npart of the programming process. But for being able to start implementing, a\nspecification of some form must be present, implicitly or explicitly.
\nAfter the specification, the implementation is introduced and at least they are\nbound using the verification.
\nSpecifications ranges from the informal human readable text string used to\nspecify the name of a test function in a given test suite, to a formal definition.\nNo matter by which means the specifications is expressed, the process of\nwriting it is still very important. It forces reasoning about the application.
\nimport org.junit.*;\n \npublic class TestAddition {\n @Test\n public void testThatAddAdds(){\n //[...]\n }\n}The above is an example drawn from Java, where a method is named to specify what\nwe are going to test. The function name is here seen as the specification for\nwhat we are going to verify. It is given that the specification is informally\ndefined.
\nDefinition specification_of_addition (f: nat -> nat -> nat) :=\n (forall b : nat,\n f 0 b = b)\n /\\\n (forall a b : nat,\n f (S a) b = f a (S b)).This example of a specification is, on the other hand, thoroughly expressed in\na specific syntax.
\nIt should be noted that there is a difference on the two examples. The first one is\naddition in Java's type system, integers with a given precision. In Coq, we\nshow that it holds for all natural numbers.
\nThe implementation is, usually, the well-known part. Following is a suggestion\nfor some code that implements their specification. So far, though, you only have\nmy word that what I have expressed is also what is implemented.
\npublic class Addition {\n public int add(int a, int b){\n return a + b;\n }\n}The Java example should come as no surprise.
\nFixpoint add a b : nat :=\n match a with\n | 0 => b\n | S a' => add a' (S b)\n end.The implementation in Coq is on the other hand not as straight forward. Two type\nconstructors are given: $S : nat \\rightarrow nat$ and $O : nat$ (which have the\nalias 0). The addition is here build on top of this.
\nFor the last part, we have the verification. Here we bind the implementation to\nthe specification.
\npublic class TestAddition {\n @Test\n public void testThatAddAdds(){\n //Assignment\n Addition adder = new Addition();\n \n //Action\n int shouldBe5 = adder.add(2, 3),\n shouldBe7 = adder.add(-2, 9),\n shouldBe5 = adder.add(8, -3),\n shouldBeMinus7 = adder.add(-4, -3);\n \n //Assert\n assertEquals(shouldBe5, 5);\n assertEquals(shouldBe7, 7);\n assertEquals(shouldBe5, 5);\n assertEquals(shouldBeMinus7, -7);\n }\n}For the Java, you still have to accept that you only have my word for\ncorrectness regarding the specification. As the specification is completely\ninformal, the assertions is a product of my interpretation of the specification\nand programming skills.
\nLemma add_satisfies_specification_of_addition :\n specification_of_addition add.\nProof.\n unfold specification_of_addition.\n split.\n intro b.\n unfold add.\n reflexivity.\n \n intros a b.\n induction a as [|a' IHa'].\n unfold add.\n reflexivity.\n \n unfold add.\n fold add.\n reflexivity.\nQed.For Coq, on the other hand, the specification are read by the theorem prover.\nHere I provide a certificate that binds the specification to the\nimplementation. Coq afterwards verifies that this certificate is valid.
\nThis is one way of relating the testing process to the process of building\nformally verified software. Testing should be applied in both cases, as\nspecifications need to be verified. This is a tool for humans to verify\nsemantic preservation when communicating their thoughts to a computer, hence\nthe KISS principlekiss applies; It is, after all, simpler to invoke a function\nwith a given input and provide the expected result than formulating a formal specification.
\nMy offset in this article was a basic approach to testing using Java and formal\nverification using Coq. That said, all mainstream languages have their own means\nof testing. For formal verification other tools exist. This is evident from the\nexisting project, e.g. the seL4 microkernel does not use Coq for the verification\npart.
\nResources for formal verification using Coq are plenty. Some good ones are\nSoftware Foundationssoftfound and Certified Programming with Dependent\nTypescpdt.
\nThere are also some interesting projects using the formal verification on very\nreal problems. The CompCertcompcert certified compiler is a formally\nproven compiler for C.
\nIn a bigger perspective, the seL4sel4 is a formally proven microkernel.
\nWhy are these necessary? one might ask. We have the GNU compiler and Linux. They\nare both stable and performs quite well? The thing is that some applications\ncan't afford that a bug is not found until running that very specific instance\nof code.
\nEven though it might seem kind of magic that we can formally verify a piece of\nsoftware, we still have to remember what we verify. We do not verify that the\nsoftware does what it is supposed to do. We verify that the software does\nwhat we have specified in the specification.
\nBy this, I emphasise the importance of doing simple and easily understandable\ntesting, were one can easily verify that the output is correct. I encourage\npeople to play with their software and try to break it. After all, they could\nhave expressed the specification wrong.
\n\nBenjamin C. Pierce et al., Software Foundations
\n↩\nAdam Chlipala, Certified Programming with Dependent Types
\n↩\nen.wikipedia.org/wiki/KISS_principle
\n↩\nIntegration, delivery, deployment, etc.
\n↩\nRecently I started writing a\nbook on Leanpub.\nThis was a first and, frankly, I had\nno real idea about what to write about.
\nPresently I have spend quite some time studying type systems. That includes\nboth formal studies and the Haskell type system. I found that after i began\nto enjoy increased knowledge about types, I became a much better programmer\nin languages like JavaScript, Java, and C#.
\nFurthermore I saw that my ventures into new languages was strictly more\nsuccessful. It was much easier to learn a new language when I had the\nability to boil everything down to the typing concepts.
\nMy thinking and research began. I concluded that the type system is\na latent framework for reasoning which is similar across programming\nlanguages. After learning types the link between Java interfaces and\nHaskell type classes was a much more coherent unit.
\nMy initial ventures into types was through a hard path. I spend hours with\nPierces books and numerous papers. The lingo is in most\ncases more confusing than\nresolving, and it was very hard to link it to any existing knowledge.
\nTherefor I decided to write a book that explains type theory for the\nprogrammer who has a strong foundation in languages such as JavaScript\nand Java. Programmers who haven't ventured into Haskell or other\nfunctional programming languages, but really want to consider these languages.
\nThe book is written using the lean methodology. This means that it will\nbe gradually published, and that I am very keen on getting feedback all the\ntime.
\nI will publish a chapter when it is initially finished for publishing. That\nis when I am content with the writing, have done copy writing and the chapter\nis coherent.
\nA published chapter is not written in stone. This means that I am more than\nwilling to rewrite a chapter when I get good arguments on alternative material.
\nAs for the pricing I have initially decided that the book will cost 5$ pr.\nchapter. This means that the book will increase in value when more chapters\nare added. I find this quite fair and it also incentivises to buy the book\nearly on, which gives me more time to finish it.
\nFollowing is my progress on the book. Even this is not written in stone.\nSo if anybody wants a special chapter, please let me know, and I might\nchange the curriculum of the book.
\n| Chapters | \nCurrent Status | \n
|---|---|
| Introduction | \nWriting | \n
| Basic Types | \nWriting | \n
| Intermedio - Application | \nStaging | \n
| Polymorphic Types | \nStaging | \n
| Existensial Types | \nStaging | \n
| Reference Types | \nStaging | \n
| Intermedio - Application | \nStaging | \n
| Sub Typing | \nStaging | \n
The book is available on\nleanpub.com/types-for-the-eager-language-learner. I appreciate any encouragement.\nThat does not have to be of monetary art, but just a word that my work is\nappreciated.
\n"},{"url":"/types-with-ts-io/","relativePath":"types-with-ts-io.md","relativeDir":"","base":"types-with-ts-io.md","name":"types-with-ts-io","frontmatter":{"title":"Types with IO-TS","author":"Mads Buch","date":"2021-08-08","template":"post","category":"technicalRef"},"html":"Type safe programming is often broken on the edge to the real world. Typescript\ndoes not come with any batteries to mitigate this. A cleverly designed library\ncalled io-ts fixes this problem. This is\nhow I use it:
A generic parser function:
\nimport { pipe } from "fp-ts/lib/function"\nimport { fold } from 'fp-ts/lib/Either'\nimport { Decoder, Errors } from "io-ts"\n\nexport const parse = <A>(codec: Decoder<any, A>, value: any): A => {\n // failure handler\n const onLeft = (errors: Errors) => {\n throw new Error(`Could not parse ${JSON.stringify(errors)}`)\n }\n\n return pipe(codec.decode(value), fold(onLeft, v => v))\n}A quick example of rewriting typescript types into their equivalent io-ts\ndefinitions goes as follows:
Before:
\ntype User = {\n name: string\n uid: string\n description?: string | undefined\n metadata: {\n [m: string]: string\n }\n gender: "male" | "female" | "other"\n}After:
\nconst User = intersection([\n type({\n name: string,\n uid: string,\n metadata: record(string, string),\n gender: union([literal("male"), literal("female"), literal("other")])\n }),\n partial({\n description: string\n })\n])\ntype User = TypeOf<typeof User>And lastly we do type safe decoding as follows:
\ntry {\n const u = parse(User, ...)\n ...\n} catch (e) {\n console.error("Could not parse")\n}Couple of notes:
\nUsr and User are mutually assignable. This means that\nnot changes will have to be made to the rest of the application.u is correctly typed.Main point: Programs can be interpreted as probabilistic distributions using the probability monad. This yields, amongst other things, foundations for easier to understand statistical models.
\nupdated february 2021 for clarity.
\n\nA probability distribution is in fact a program. Thinking about it in this\nway makes them considerable more understandable and easier to work with. now\na probabilistic model is simply a program that make all assumptions clear as\nthe sun - no more assumption that data adheres to certain distributions.
\nIn order to lift programs into a probability distribution we use the\nprobability monad. It has for a long time been known that probability\ndistributions are monads. This article builds on the work by\nRamsey and Pfeffer on\nStochastic Lambda Calculus and Monads of Probability Distributions
\nThe source for this article is available as a\ngist on Github.
\nI tend to think of a probability distribution as a black box. A mysterious\nthing we will never be able to completely open. However, we do have different\nlenses that lets us see aspects of the distribution and lets us understand it.\nThese lenses, from here on queries, are the support query, the expectation query,\nand the sample query.
\nThe support of a probability distribution is simply the set of elements in the\ndistribution which are probable. Ie. the elements with a non-zero probability of\noccurring.
\nThe expectation query is implemented as a function that takes a probability\ndistribution, and function representing an event and returns the mean\nthat said event will happen. For the famous dice example where we want to\ncalculate the expectation of rolling a six, the function will return 1 for\nsix and 0 for all others. Taking the mean yields 1/6 with is the expectation\nfor rolling a six.
\nThe sample query yields one of the elements from the support with a given\nprobability. The samples are usually not that interesting in small quantities\nand we need to be able to draw thousands. But when we do that we are in fact\nable to say interesting things about distributions that are recursive or\nhave infinite support. This happens easily when we lift entire programs into a\nprobability distribution.
\nWhen constructing probability distributions we need an intuitive way to tap\ninto all the randomness. When working with discrete distributions we can\ndefine
\nLastly, we also need an operation for building distributions. In this work,\nwe take offset in a single function called choose which act as a construct\nthat binary chooses between two distribution with a certain probability. It\nis easy to understand. A coin toss is implement as choose 0.5 Tail Head.\nFrom here it is merely about convincing oneself that we can approximate all\ndistributions with arbitrary precision using that single operator.
A monad is a mathematical structure with its roots in\ncategory theory. Monads can be understood as an abstraction over a\ncomputational context. This computational context is in this case the\nconcrete probabilities. Ie. notions about categories and their explicit\nprobabilities etc.
\nThe monad needs to implement two operations: The bind operation for\ncomposition and the return operation to lift values into the monad.\nIn the Haskell syntax these functions are declared as follows
(>>=) :: m a -> (a -> m b) -> m b -- pronounced bind\nreturn :: a -> m aIn terms of probability distribution these should be read respectively as\ndraw and as make this single value a distribution. Admittedly, the\ndistribution return 4 is not in particular interesting as we will always\ndraw the number 4 with a 100% probability.
The raw probability distribution furthermore implements the choose function.\nThis is the function
To get an overview of the implementation of the probability monad\nit makes sense to look at the class hierarchy we are considering.
\nThe following figure shows the monads we are implementing.
\n\nThe lowermost three boxes are the most interesting. Those are the queries, the\noperations we can use on a distribution to make sense of it.
\nThis section elaborates on a measure theoretic approach to the\nprobability monad. We represent the distribution as a continuation\nthat takes a measure function and returns an expectation.
\nFirst, we will take a look at our monad type.
\n-- Probability Monad\nnewtype PExp a = P (( a -> Double) -> Double)It is worth looking into what happens here. We have the constructor\nPExp, that takes a function, a measure function, and gives the\nexpectation.
The monadic structure of probability distributions is in this setting\nimplemented as follows.
\ninstance Monad P where\n return x = P (\\h -> h x)\n (P d) >>= k =\n P (\\h -> let apply (P f) arg = f arg\n g x = apply (k x) h\n in d g)From here the expectation monad is easily implemented as the whole\nmonad type is built around it.
\ninstance ExpMonad PExp where\n expectation h (PExp d) = d hWe could now start to do experiments base on this. But we would much\nrather like to play with support and sample also. These, however,\nare quite difficult to implement using the type of PExp so we are\ngoing to attack this from another angle.
The above implementation of the monad type is not very suited for other than\nthe expectation query. To make something more suited, we will try to stay true\nto the paper and implement a type such that we can hold data as it is defined
\ndata P a where\n R :: a -> P a\n B :: P a -> (a -> P b) -> P b\n C :: Probability -> P a -> P a -> P aThe quick reader will see that we now use GADTs instead or ordinary ADTs. This\nis due to the Bind constructor. This poses a change of the type, and can not\nbe implemented by ADTs.
\nIn the instances for the monad and probability monad we simply defer everything\nto used directly by the queries.
\n-- P is a monad\ninstance Monad P where\n return x = R x\n d >>= k = B d k\n\n-- P is a probability monad\ninstance ProbabilityMonad P where\n choose p d1 d2 = C p d1 d2This allows for definitions of the queries to be directly copied from the\npaper. In addition to the expectation query we had before, we can now also\ndo support and sampling.
instance SupportMonad P where\n support (R x) = [x]\n support (B d k) = concat [support (k x) | x <- support d]\n support (C p d1 d2) = support d1 ++ support d2\n...For the full source I once again refer to the\ngist on Github..
\nIn this section we will take a look on how to construct some interesting\ndistributions and how the queries work on them.
\nAs often when working with probabilities we will look on dices. To make\nit easy we make a data type deriving Enum for easy enumeration.
data Dice = One | Two | Three | Four | Five | Six\n deriving (Enum, Eq, Show, Read, Ord)We can from here make a uniform distribution over the sides of a dice\nlike following.
\ndist :: P Dice\ndist = uniform [One .. Six]The uniform method is a simple function that makes a uniform distribution\nover a list using the choose function and the length of the list.
A support query can be performed as follows.
\nexample01a =\n let dist :: P Dice\n dist = uniform [One .. Six]\n in support distYielding the result of [One,Two,Three,Four,Five,Six]. To create a posterior\ndistribution from a prior, we use the bind. This translates into elegant and\neasily readable dependent distributions.
example02a =\n let dist :: P Dice\n dist = do\n d <- uniform [One .. Six]\n return (if d == Six then One else d)\n in support distThis yields the result [One,Two,Three,Four,Five,One] Note how One appears\ntwice. This make immediate sense from the definition of the distribution\nthough we would have expected duplications removed. However, this is quite\neasily done in Haskell.
The last example in the gist is one of the more interesting. The distribution\ndefined is potentially infinite. Intuitively it counts up with a probability\nof a half and continues doing that.
\nwalk x =\n do bit <- uniform [True, False]\n if bit then\n return x\n else walk (x + 1)So what happens when we throw the various queries on it?
\nThe support query should return a list of all potential outcomes of the\ndistribution, and so it does. running example03a returns\n[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,^CInterrupted.. If not\nstopped it would continue counting up.
An important remark here is that\norder of the True and False in the inner distribution. If we switch it\nsuch that the inner distribution reads uniform [False, True] it will never\nreturn anything. Intuitively one can understand it as the last element is\nunfold first. In the current ordering the walk function creates a list which\nis reducible though infinite.
Secondly we have the expectation query. issuing this yields an infinite\ncomputation without any result. This is because we attempt to unroll the full\nstructure to get the expectation of an event.
\nLastly we have the sample query. This query works completely as expected yielding a list of samples. Issuing example03c will return\n[0,1,3,0,0,2,0,1,0,1] which intuitively makes sense.
Though the expectation query is not possible through the current implementation\nwe could actually still get an idea about the expectations using the Monte\nCarlo Technique. Sampling 10.000 elements of the walk distribution and taking\nthe frequency gives us following.
\n> mc\n[(0,4937),\n (1,2483),\n (2,1294),\n (3,630),\n (4,326),\n (5,159),\n (6,87),\n (7,34),\n (8,27),\n (9,10),\n (10,5),\n (11,5),\n (12,2),\n (15,1)]Which is what we would expect.
\nWe have discussed Ramsey and Pfeffer's paper in this article. It provides a\nfundamental understanding based in programming languages on distributions and\nprobabilities. It is interesting because it makes languages like Hakaru much\neasier to understand. Furthermore it also greatly simplifies the hole world of\nprobabilities.
\n"},{"url":"/why-we-dont-need-authorization/","relativePath":"why-we-dont-need-authorization.md","relativeDir":"","base":"why-we-dont-need-authorization.md","name":"why-we-dont-need-authorization","frontmatter":{"title":"Why We Don’t Need Authorization","author":"Mads Buch","date":"2022-01-02","template":"post","excerpt":"Yet"},"html":"A comment on doing what's necessary when necessary.
\nImage this: You start out on a new project. You don't entirely know what you want to build, but you have a rough idea.\nThe energy is fierce and it is just about getting started. You think to your self: \"I might as well just get a couple of things in that I know I will need\". You have an idea, that probably a user needs to be able to create a user. And so the work begins!
\nSomething similar happened when I worked with a previous client.
\nWe were implementing a minimum viable product (MVP) based on their previous work. While scoping out the initial layout\nwe added in the sign-up flow for users. Upon deliberation with the client, we found that it was not strictly needed,\nso we removed it from the scope.
\nTo this day I am quite sure it still has not been implemented and is not needed. Money saved, more time with the family!
\nAnyways, on the contrary, case complexities arise, we spend time tweaking the passwordless signup flow. We implement JWT cause, hey, we want to support microservices, and so on.
\nAs is usual, we lose interest in the problem, or we have to attend something else for a while, and the idea leaves us and flies to another person, or even worse, never gets built. Now managers are stuck with their inefficient ways of doing roadmaps and the scientists will need to figure out another way to organize their knowledge.
\nAn alternative is, at least in the beginning, to remove authorization from the idea and focus on what is essential. This requires us to make some realization, to change the vision, to build something different. This is hard, we need to get rid of our darling. But how is this possible?
\nSay you want to make a shared word editor. Something like Google Docs. Would this be possible without an authorization system? Indeed it is. Actually, the predecessor to Google Docs was made without authorization. One would merely go to a website, start a new document, and share the link with their friends. The security would be in the random name of the document. Good enough for enterprise and national secrets? Merely, but good enough to showcase collaborative editing which has since been refined, with fully featured authorization into successful products.
\n"},{"url":"/objects-and-state/","relativePath":"objects-and-state.md","relativeDir":"","base":"objects-and-state.md","name":"objects-and-state","frontmatter":{"title":"Objects and State","author":"Mads Buch","subtitle":"On objects vs. pure functions","excerpt":"Object oriented programming is inherently stateful. This fits well for some applications and can confuse and reduce reliability for others.","date":"2021-02-20","template":"post"},"html":"Main point: Object oriented programming is inherently stateful. This fits well for some applications and can confuse and reduce reliability for others.
\nTake a look at following code snippet:
\noptimizer = new SGD(...)\nmodel1.train(example, optimizer)\nmodel2.train(example, optimizer)A question bids: Should i initialize an optimizer for each model, or can I\nexpect the optimizer to be stateless and merely reference static functions?
\nFrom the above example, it is not clear if the newly initialized object is stateful\nor stateless. Whether a computation unit is stateful or not is architecturally\nimportant. In the above example, the difference would yield bugs that are near\nimpossible to locate.
\nOn the other hand, take a look at following example:
\noptimizer = lambda x : ...\nmodel1.train(example, optimizer)\nmodel2.train(example, optimizer)In that example, it is much more clear that the optimizer indeed is pure (if\nthat was intended). However, this is not idiomatic in a language like Python.\nFurthermore, we are not ensured that the optimizer function as defined is\nstateless. In languages like Python, JavaScript, Typescript, variables\noutside of scope can be mutated.
In some languages, like Haskell, all functions are pure and all state has to\nbe supplied directly to the function. Here mutable structure can be implemented\nin monads. But when just skimming a program, the programmer always knows what\ndata a function has access to.
\nPure functions are nice to use when statelessness is guaranteed. They are\nversatile, can be reused and worked into programs in flexible ways. The\nknowledge that a function is pure gives us peace at night. It is easier to\nverify that we did not overlook something.
\nStateful objects are useful when working on complex data structures\nthat benefit from mutability. The class definitions allow for a clear separation\nbetween a clean interface a messy internal state. Classes provide the tools\nto ensure only operations that satisfy the invariants are publicly available.\nKey examples are tensors where we don't want to be wary about access to\nindividual elements but want to expose functions like addition, subtraction,\nmultiplication, dot product, etc.
\n"}],"site":{"siteMetadata":{"siteUrl":"https://www.madsbuch.com","description":"Mads Buch - A personal blog","header":{"title":"Mads Buch","tagline":"A personal blog","background_img":"images/header-bg.webp","has_nav":true,"nav_links":[{"label":"Home","url":"/","style":"link"},{"label":"About","url":"/about","style":"link"},{"label":"Now","url":"/now","style":"link"},{"label":"Understanding Data","url":"/data","style":"link"}],"has_social":true,"social_links":[{"label":"Mastodon","url":"https://functional.cafe/@madsbuch","style":"icon","icon_class":"fa-mastodon","new_window":true},{"label":"GitHub","url":"https://github.com/madsbuch","style":"icon","icon_class":"fa-github","new_window":true},{"label":"LinkedIn","url":"https://www.linkedin.com/in/madsbuch/","style":"icon","icon_class":"fa-linkedin","new_window":true}]},"footer":{"content":"© All rights reserved.","links":[]},"palette":"yellow","title":"Mads Buch [dot] Com"},"pathPrefix":"","data":{}}}},"staticQueryHashes":[]}