Back in 2014 I was helping my girlfriend’s sister with her maths homework and a particular question sparked my imagination. The original question, as posed by her teacher, has a trivial solution (If you’ve already done A level maths). The question is about a farmer trying to find the optimal way to arrange their fence. Their fence is to be placed against the wall and they want to be able to enclose the largest area for their sheep to graze. However, they only have a fixed length of fence. Representing this fixed length of fence as s we can find the optimal x and y lengths the farmer should use as follows: This is the solution the teacher was looking for but that got me thinking what if, rather than straight lines, you had circles. This led me to the problem I have spent a long time since trying to grapple with.  The problem can be described as the same farmer who is now trying to use a fence which can be arced into a segment of a circle. Instead of a wall the farmer is now using a circ

Computational omnipotence ; unlimited computing speed and memory such that if a result is computable, it can be computed. Computable ; There exists an algorithm which can produce the result in a finite number of steps Uncertainty is a topic I think everyone understands to a certain degree. There is a field of mathematics dedicated to demystifying its nebulous nature. This is, of course, the field of probability theory. There is, however, a limit to probability theory which comes from one of the assumptions that underpins it. Computational omnipotence is assumed when dealing with the calculations. That is to say that given the information you have, you can calculate all of the resulting probabilities that are possible to calculate with the starting information you have. Your uncertainty is limited to uncertainty about the environment. For example, when a die is rolled you are uncertain of which face will land up. If n dice are thrown you are only uncertain about which faces will be on t

In creating a post explaining the relevance and prospect of using prediction markets in the study of logical uncertainty I produced a graph showing an example of how the answer to the question of if the 100th digit of pi is a 7, might be evaluated if each digit of pi needed to be expanded one after the other. This is an accompanying post, something of an appendix to the future post, so might not make much sense on its own. A possible graph of the stock price over time, assuming that to get to the 100th digit you need to expand each digit. I’ve included a few different models: You can see that here for all models the price starts at 50¢ falls to 10¢ and from that point, the models diverge somewhat in their price prediction.  Explaining the models There are two underlying models which lead to the production of all the lines in these graphs. The first is the model that as there are 10 possible values a digit of pi could take, that the probability of the 100th digit being 7 is 10%. The oth

DRY - Don't repeat yourself One of the things I did wrong when I started to write software for a career is to try and optimise before I had a chance to understand. Having worked a little longer I feel I have a better appreciation for what should be automated and when.  There are a lot of things that I felt I was repeatedly doing that according to my understanding of the DRY principles at the time, I thought I should be abstracted away, so as not to have to repeat myself. I kept telling myself that if I was finding a project boring that the boredom was a notification from my mind that there is unnecessary repetition. I still feel that there is a level of truth in the idea of boredom being the mind picking up on repetition however I now realise that is that there is a level of repetitiveness that is inherent in working as a software developer. That is not to say that we shouldn’t strive to remove the repetitiveness but that the job of a developer when working on a project must be fir

A dovetail joint requires expertise but can allow for glue and nails to be done away with. A lot of the work done in software engineering is menial. Often the profession is portrayed as people solving the complex problems that are posed in the academic discipline of computer science, and don’t get me wrong, having a foundational understanding of computer science upon which to develop your craft is important. It helps you to understand why some of the frustrations exist and to, although not often the case anymore, optimise code to be performant enough for a given task. Software engineering has always been the craft of translating the spirit of a requirements document (or sentiment of the client) into a language free of ambiguity for the machine to understand. The shift in grammatical style from English (or any other natural language) to that of a particular programming language notwithstanding almost the entirety of the job of a developer is providing clarification. Moreover

Conversational agents or chatbots have been an interest of mine for a very long time. I wrote my first chatbot LIRA with a friend back around 2008. It used the Alicebot dataset to try and match what the user had said with one of the tens of thousands of pre-programmed replies. In fact, all the program did was take the user input and remove a word from the end until the SQL query: This led to some funny responses albeit not very useful ones. My latest attempt to understand natural language processing and produce a chatbot has been slow progress but there are two main ideas at the core of where I want to take the project. To parse a sentence means to break the sentence into its components and generate the structure from a grammar (Find what rules make that sentence). A grammar is a series of rules that define the structure of a sentence. A parse tree is a representation of the sentence after the structure from the grammar has been added. Dealing with ambiguous grammars T