Peter Landin: Elegance from Logic

Celebrating LGBTQ+ Greats

Thousands of programming languages have been invented in the many decades since the first. But what makes a good language? A key idea behind language design is that they should make it easy to write complex algorithms in simple and elegant ways. It turns out that logic is key to that. Through his work on programming language design, Peter Landin as much as anyone, promoted both elegance and the linked importance of logic in programming. 

Pride flag with lambda x.x (identity) superimposed
Pride image by Image by Pete Linforth from Pixabay. Composite by PC

Peter was an eminent Computer Scientist who made major contributions to the theory of programming languages and especially their link to logic. However, he also made his mark in his stand against war, and support of the nascent LGBTQ+ community in the 1970s as a member of the Gay Liberation Front. He helped reinvigorate the annual Gay Pride marches as a result of turning his house into a gay commune where plans were made. It’s as a result of his activism as much as his computer science that an archive of his papers has been created in the Oxford Bodleian Library.

However, his impact on computer science was massive. He was part of a group of computing pioneers aiming to make programming computers easier, and in particular to move away from each manufacturer having a special programming language to program their machines. That approach meant that programs had to be rewritten to work on each different machine, which was a ridiculous waste of effort! Peter’s original contribution to programming languages was as part of the team who developed the programming language, ALGOL which most modern programming languages owe a debt to.

ALGOL included the idea of recursion, allowing a programmer to write procedures and functions that call themselves. This is a very mathematically elegant way to code repetition in an algorithm (the code of the function is executed each time it calls itself). You can get an idea of what recursion is about by standing between two mirrors. You see repeated versions of your reflection, each one smaller than the last. Recursion does that with problem solving. To solve a problem convert it to a similar but smaller version of the same problem (the first reflection). How do you solve that smaller problem? In the same way, as a smaller version of the same problem (the second reflection)… You keep solving those similar but smaller problems in the same way until eventually the problem is small enough to be trivial and so solved. For example, you can program a factorial method (multiplying all numbers from 1 to n together),in this way. You write that to compute factorial of a number, n, it just calls itself and computes the factorial of (n-1). It just multiply that result by n to get the answer. In addition you just need a trivial case eg that factorial of 1 is just 1.

factorial (1) = 1
factorial (n) = n * factorial (n-1)

Peter was an enthusiastic and inspirational teacher and taught ALGOL to others. This included teaching one of the other, then young but soon to be great, pioneers of Programming Theory, Tony Hoare. Learning about recursion led Hoare to work out a way, using recursion, to finally explain the idea that made his name in a simple and elegant way: the fast sorting algorithm he invented called Quicksort. The ideas included in ALGOL had started to prove their worth.

The idea of including recursion in a programming language was part of the foundation for the idea of functional programming languages. They are mathematically pure languages that use recursion as the way to repeat instructions. The mathematical purity makes them much easier to understand and so write correct programs in. Peter ran with the idea of programming in this way. He showed the power that could be derived from the fact that it was closely linked to a kind of logic called the Lambda Calculus, invented by Alonso Church. The Lambda Calculus is a logic built around  mathematical functions. One way to think about it is that it is a very simple and pure way to describe in logic what it means to be a mathematical function – as something that takes arguments and does computation on them to give results. This Church showed was a way to define all possible computation just as Turing’s Turing machine is. It provides a simple way to express anything that can be computed.

Peter showed that the Lambda Calculus could be used as a way to define programming languages: to define their “semantics” (and so make the meaning of any program precise).

Having such a precise definition or “semantics” meant that once a program was written it would be sure to behave the same way whatever actual computer it ran on. This was a massive step forward. To make a new programming language useful you had to write compilers for it: translators that convert a program written in the language to a low level one that runs on a specific machine. Programming languages were generally defined by the compiler up till then and it was the compiler that determined what a program did. If you were writing a compiler for a new machine you had to make sure it matched what the original compiler did in all situations … which is very hard to do.

So having a formal semantics, a mathematical description of what a compiler should do, really makes a difference. It means anyone developing a new compiler for a different machines can ensure the compiler matches that semantics. Ultimately, all compilers behave the same way and so one program running on two different manufacturer’s machines are guaranteed to behave the same way in all situations too.

Peter went on to invent the programming language ISWIM to illustrate some of his ideas about the way to design and define a programming language. ISWIM stands for “If you See What I Mean”. A key contribution of ISWIM was that the meaning of the language was precisely defined in logic following his theoretical work. The joke of the name meant it was logic that showed what he meant, very precisely! ISWIM allowed for recursive functions, but also allowed recursion in the definition of data structures. For example, a List is built from a List with a new node on the end. A Tree is built from two trees forming the left and right branches of a new node. They are defined in terms of themselves so are recursive.

Building on his ideas around functional programming, Peter also invented something he called the SECD machine (named after its components: a Stack, Environment, Control and Dump). It effectively implements the Lambda calculus itself as though it is a programming language.ISWIM provided a very simple but useful general-purpose low level language. It opened up a much easier way to write compilers for functional programming languages for different machines. Just one program needed to be written that compiled the language into SECD. Then you had a much simpler job of writing a compiler to convert from the low level SECD language to the low level assembly language of each actual computer.  Even better, once written, that low level SECD compiler could be used for different functional programming languages on a single machine. In SECD, Peter also solved a flaw in ALGOL that prevented functions being fully treated as data. Functions as Data is a powerful feature of the best modern programming languages. It was the SECD design that first provided a solution. It provided a mechanism that allowed languages to pass functions as arguments and return them as results just as you could do with any other kind of data without problem.

In the later part of his life Peter focussed much more on his work supporting the LGBTQ+ community having decided that Computer Science was not doing the good for humanity he once hoped. Instead, he thought it was just supporting companies making profit, ahead of the welfare of people. He decided that he could do more good as part of the LGBTQ+ community. Since his death there has been an acceleration in the massing of wealth by technology companies, whereas support for diversity has made a massive difference for good, so in that he was prescient. His contributions have certainly, though, provided a foundation for better software, that has changed the way we live in many ways for the better. Because of his work they are less likely to cause harm because of programming mistakes, for example, so in that at least he has done a great deal of good.

by Paul Curzon, Queen Mary University of London

More on …

Magazines …


Subscribe to be notified whenever we publish a new post to the CS4FN blog.



EPSRC supports this blog through research grant EP/W033615/1. 

A puzzle, spies … and a beheading

A puzzle about secrets

Ayo wants to send her friends Guang and Elham who live together secret messages that only the person she sends the message to can read. She doesnt want Guang to read the messages to Elham and vice versa.

An ornate padlock with key
Image by Bernd from Pixabay

Guang buys them all small lockable notebooks for Christmas. They are normal notebooks except that they have a lock that can be locked shut using a small in-built padlock. Each padlock can be opened with a different single key. Guang suggests that they write messages in their notebook and post it and the key separately to the person who they wish to send the message to. After reading the message that person tears that page out and destroys it, then returns the notebook and key. They try this and it appears to be working, apparently preventing the others from reading the messages that aren’t for them. They exchange lots of secrets…until one day Guang gets a letter from Ayo that includes a note with an extra message added on the end by Elham in the locked notebook. It says “I can read your messages. I know all your secrets – Elham”. She has been reading Ayo’s messages to Guang all along and now knows all their secrets. She now wants them to know how clever she has been.

How did she do it? (And what does it have to do with the beheading of Mary Queen of Scots?)

Breaking the system

Elham has, of course, been getting to the post first, steaming open the envelopes, getting the key and notebook, reading the message (and for the last one adding her own note). She then seals them back in the envelopes and leaves them for Guang.

A similar thing happened to betray Mary Queen of Scots to her cousin Queen Elizabeth I. It led to Mary being beheaded.

Is there a better way?

Ayo suggests a solution that still uses the notebooks and keys, but in which no keys are posted anywhere. To prove her method works, she sends a secret message to Guang, that Elham fails to read. How does she do it? See if you can work it out before reading on…and what is the link to computer science?

Mary Queen of Scots

Mary Queen of Scots
Image by Gordon Johnson from Pixabay

The girls face a similar problem to that faced by Mary Queen of Scots and countless spies and businesses with secrets to exchange before and since…how to stop people intercepting and reading your messages. Mary was beheaded because she wasn’t good enough at it. The girls in the puzzle discovered, just like Mary, that weak encryption is worse than no encryption as it gives false confidence that messages are secret.

There are two ways to make messages secret – hide them so no one realises there is a message to read or disguise the message so only people in the know, are aware it exists (or both). Hiding the message is called Steganography. Disguising a message so it cannot be read even if known about is called encryption. Mary Queen of Scots did both and ultimately lost her life because her encryption was easy to crack, when she believed the encryption would protect her, it had given her the confidence to write things she otherwise would not have written.

House arrest

Mary had been locked up – under house arrest – for 18 years by Queen Elizabeth I, despite being captured only because she came to England asking her cousin Elizabeth to give her refuge after losing her Scottish crown. Elizabeth was worried that Mary and her allies would try to overthrow her and claim the English crown if given the chance. Better to lock her up before she even thought of treason? Towards the end of her imprisonment, in 1586 some of Mary’s supporters were in fact plotting to free her and assassinate Elizabeth. Unfortunately, they had no way of contacting Mary as letters were allowed neither in nor out by her jailors. Then, a stroke of good fortune arose. A young priest called Gilbert Gifford turned up claiming he had worked out a way to smuggle messages to and from Mary. He wrapped the messages in a leather package and hid them in the hollow bungs of barrels of beer. The beer was delivered by the brewer to Chartley Hall where Mary was held and the packages retrieved by one of Mary’s servants. This, a form of steganography, was really successful allowing Mary to exchange a long series of letters with her supporters. Eventually the plotters decided they needed to get Mary’s agreement to the full plot. The leader of the coup, Anthony Babington, wrote a letter to Mary outlining all the details. To be absolutely safe he also encrypted the message using a cipher that Mary could read (decipher). He soon received a reply in Mary’s hand also encrypted that agreed to the plot but also asked for the names of all the others involved. Babington responded with all the names. Unfortunately, unknown to Babington and Mary the spies of Elizabeth were reading everything they wrote – and the request for names was not even from Mary.

Spies and a Beheading

Unfortunately for Mary and Babington all their messages were being read by Sir Francis Walsingham, the ruthless Principal Secretary to Elizabeth and one of the most successful Spymasters ever. Gifford was his double agent – the method of exchanging messages had been Walsingham’s idea all along. Each time he had a message to deliver, Gifford took it to Walsingham first, whose team of spies carefully opened the seal, copied the contents, redid the seal and sent it on its way. The encrypted messages were a little more of a problem, but Walsingham’s codebreaker could break the cipher. The approach, called frequency analysis, that works for simple ciphers, involves using the frequency of letters in a message to guess which is which. For example, the most common letter in English is E, so the most common letter in an encrypted message is likely to be E. It is actually the way people nowadays solve crossword like code-puzzles know as Cross References that can be found in puzzle books and puzzle columns of newspapers.

When they read Babington’s letter they had the evidence to hang him, but let the letter continue on its way as when Mary replied, they finally had the excuse to try her too. Up to that point (for the 18 years of her house arrest) Elizabeth had not had strong enough evidence to convict Mary – just worries. Walsingham wanted more though, so he forged the note asking for the names of other plotters and added it to the end of one of Mary’s letters, encrypted in the same code. Babington fell for it, and all the plotters were arrested. Mary was tried and convicted. She was beheaded on February 8th 1587.

Private keys…public keys

What is Ayo’s method to get round their problems of messages being intercepted and read? Their main weakness was that they had to send the key as well as the locked message – if the key was intercepted then the lock was worthless. The alternative way that involves not sending keys anywhere is the following…

Top Secret written on a notebook with flowers

Image by Paul Curzon

Suppose Ayo wants to send a message to Guang. She first asks Guang to post her notebook (without the key but left open) to her. Ayo writes her message in Guang’s book then snaps it locked shut and posts it back. Guang has kept the key safe all along. She uses it to open the notebook secure in the knowledge that the key has never left her possession. This is essentially the same as a method known by computer scientist’s as public key encryption – the method used on the internet for secure message exchange, including banking, that allows the Internet to be secure. In this scheme, keys come in 2 halves a “private key” and a “public key”. Each person has a secret “private key” of their own that they use to read all messages sent to them. They also have a “public key” that is the equivalent to Guang’s open padlock.

If someone wants to send me a message, they first get my public key – which anyone who asks for can have as it is not used to decrypt messages, just for other people to to encrypt them (close the padlock) before sending them to me. It is of no use to decrypt any message (reopen the padlock). Only the person with the private key (the key to the padlock) can get at the message. So messages can be exchanged without the important decryption key going anywhere. It remains safe from interception.

Saving Mary

Would this have helped Mary? No. Her problem was not in exchanging keys but that she used a method of encryption that was easy to crack – in effect the lock itself was not very strong and could easily be picked. Walsingham’s code breakers were better at decryption than Babington was at encryption.

by Paul Curzon, Queen Mary University of London, updated from the archive

More on …

Magazines …


Subscribe to be notified whenever we publish a new post to the CS4FN blog.



EPSRC supports this blog through research grant EP/W033615/1. 

Designing an interactive prayer mat

Successful interactive systems design is often based on detecting a need that really good solutions do not yet exist for, then coming up with a realistic solution others haven’t thought of. The real key is then having the technical and design skill and perseverance to actually build it, as well as the perseverance to go through lots of rounds of prototyping to get it right. Even then it is still a long haul needing different people and business skills to end up with a successful product. Kamal Ali showed how its done with the development of My Salah Mat, an interactive prayer mat to help young children learn to pray.

A child in prayer bowing low to God in the direction of Mecca
Image by Samer Chidiac from Pixabay

He realised there was a need watching his 4-year old struggling to get his feet and hands, forehead and nose in the right place to pray: correctly bowing low to God in the direction of Mecca. Instead he kept lying on his tummy. Kamal’s first thought was to try and buy something that would help.

He searched for something suitable: perhaps a mat with the positions marked on in some child friendly way, and was surprised when he could find nothing. Thinking it was a good idea anyway, and with a background in product design, he set about creating a Photoshop prototype himself. One of the advantages of prototyping is that it encourages “design-by-doing” and just in doing that he had new ideas – children need help with the words of prayers too, so why not write them on the mat in child friendly ways. From there realising it could be interactive with buttons to press so it could read out instructions was the next step. After all young children may struggle with reading themselves: it is important to really know your users and what will and will not work for them!

As he was already running a company, he knew how to get a physical prototype made so after working on the idea with a friend he created the first one. From there there were lots more rounds of prototyping to get the look and feel right for young kids, for example, and to ensure it would fill their need really, really well.

He also focussed on the one clear group: of young children and designed for their need. Once that design was successful the company then developed a very different design based on the same idea for adult / reverts. That is an important interaction design lesson. Different groups of potential users may need different designs and trying to design one product for everyone may not end up working for anyone. Find a specific group and design really well for them!

In the process of creating the design Kamal started to wonder why he was doing it. He realised it was not to make money – he was really thinking of it as a social venture. It was not about profit but all about doing social good: as he has said:

” I finally realised that my motivation was to create a high quality product that could help children learn how to pray Salah. Most importantly, children would want to pray and interact with the different aspects of Salah. This was my true motivation and the most important thing to me.”

Great interactive system product design takes inspiration, skill and a lot of perseverance, but the real key is to be able to identify a real unfulfilled need, and come up with realistic solutions that both fill the need and people want. That is not just about having an idea, it is about doing rounds and rounds of prototyping and trial and error with people who will be the users to get the design right. If you do get it right and you can do all sorts of good.

by Paul Curzon, Queen Mary University of London.

More on …

Magazines …


Subscribe to be notified whenever we publish a new post to the CS4FN blog.



EPSRC supports this blog through research grant EP/W033615/1. 

A sound social venture: recognising birds

Dan Stowell was a researcher at Queen Mary University of London when he founded an early version of what is now known as a Social Venture: a company created to do social good. With Florence Wilkinson, he turned birdsong into a tech-based social good.

A Eurasian Wren singing on the end of a branch
A Eurasian Wren: Image by Siegfried Poepperl from Pixabay

His research is about designing methods that computers can use to make sense of bird sounds. One day he met Florence Wilkinson, who works with businesses and young people, and they discovered they both had the same idea: “What if we could make an app that recognises bird sounds?” They decided to create a startup company, Warblr, to make it happen. However, unlike many research driven startups its main aim was not to make money but to do a social good. Dan and FLorence built this into their company mission statement:

…to reconnect people with the natural world through technology. We want to get as many people outdoors as possible, learning about the wildlife on their doorstep and how to protect it.

Dan brought the technical computer science skills needed to create the app, and Florence brought the marketing and communication skills needed to ensure people would hear about it. Together, they persuaded Queen Mary University of London’s innovation unit to give them a start-up grant. As a result their app Warblr exists and even gained some press coverage.

It can help people connect with nature by helping recognise birds – after all one of the problems with bird watching is they are so damned hard to spot and lots that flit by just look like little brown things! However, they are far easier to hear. Once you know what is out there then it adds incentive to try to actually spot it. However, the app has another purpose too. It collects data about the birds spotted, recording the species and where and when it was seen, with that data then made freely available to researchers.

Social ventures are a relatively new idea that universities are now supporting to help their researchers do social good that is sustainable and not just something that lasts until the grants run out. As Dan and Florence showed though, as a researcher you do not need to commit to do everything. To be a successful innovator you need more than technical skills, though. You need the ability to be part of a great team and to recognise a sound deal!

Updated from the archive, written by Paul Curzon, Queen Mary University of London.

More on …

Magazines …

The front cover of issue 21 of CS4FN called Computing Sounds Wild

Subscribe to be notified whenever we publish a new post to the CS4FN blog.



EPSRC supports this blog through research grant EP/W033615/1. 

Oh no! Not again…

What a mess. There’s flour all over the kitchen floor. A fortnight ago I opened the cupboard to get sugar for my hot chocolate. As I pulled out the sugar, it knocked against the bag of flour which was too close to the edge… Luckily the bag didn’t burst and I cleared it up quickly before anyone found out. Now it’s two weeks later and exactly the same thing just happened to my brother. This time the bag did burst and it went everywhere. Now he’s in big trouble for being so clumsy!

Flour cascading everywhere
Cropped image of that by Anastasiya Komarova from Pixabay
Image by Anastasiya Komarova from Pixabay (cropped)

In safety-critical industries, like healthcare and the airline industry, especially, it is really important that there is a culture of reporting incidents including near misses. It also, it turns out, is important that the mechanisms of reporting issues is appropriately designed, and that there is a no blame culture especially so that people are encouraged to report incidents and do so accurately and without ambiguity.

Was the flour incident my brother’s fault? Should he have been more careful? He didn’t choose to put the sugar in a high cupboard with the flour. Maybe it was my fault? I didn’t choose to put the sugar there either. But I didn’t tell anyone about the first time it happened. I didn’t move the sugar to a lower cupboard so it was easier to reach either. So maybe it was my fault after all? I knew it was a problem, and I didn’t do anything about it. Perhaps thinking about blame is the wrong thing to do!

Now think about your local hospital.

James is a nurse, working in intensive care. Penny is really ill and is being given insulin by a machine that pumps it directly into her vein. The insulin is causing a side effect though – a drop in blood potassium level – and that is life threatening. They don’t have time to set up a second pump, so the doctor decides to stop the insulin for a while and to give a dose of potassium through a second tube controlled by the same pump. James sets up the bag of potassium and carefully programs the pump to deliver it, then turns his attention to his next task. A few minutes later, he glances at the pump again and realises that he forgot to release the clamp on the tube from the bag of potassium. Penny is still receiving insulin, not the potassium she urgently needs. He quickly releases the clamp, and the potassium starts to flow. An hour later, Penny’s blood potassium levels are pretty much back to normal: she’s still ill, but out of danger. Phew! Good job he noticed in time and no-one else knows about the mistake!

Two weeks later, James’ colleague, Julia, is on duty. She makes a similar mistake treating a different patient, Peter. Except that she doesn’t notice her mistake until the bag of insulin has emptied. Because it took so long to spot, Peter needs emergency treatment. It’s touch-and-go for a while, but luckily he recovers.

Julia reports the incident through the hospital’s incident reporting system, so at least it can be prevented from happening again. She is wracked with guilt for making the mistake, but also hopes fervently that she won’t be blamed and so punished for what happened

Don’t miss the near misses

Why did it happen? There are a whole bunch of problems that are nothing to do with Julia or James. Why wasn’t it standard practice to always have a second pump set up for critically ill patients in case such emergency treatment is needed? Why can’t the pump detect which bag the fluid is being pumped from? Why isn’t it really obvious whether the clamp is open or closed? Why can’t the pump detect it. If the first incident – a ‘near miss’ – had been reported perhaps some of these problems might have been spotted and fixed. How many other times has it happened but not reported?

What can we learn from this? One thing is that there are lots of ways of setting up and using systems, and some may well make them safer. Another is that reporting “near misses” is really important. They are a valuable source of learning that can alert other people to mistakes they might make and lead to a search for ways of making the system safer, perhaps by redesigning the equipment or changing the way it is used, for example – but only if people tell others about the incidents. Reporting near-misses can help prevent the same thing happening again.

The above was just a story, but it’s based on an account of a real incident… one that has been reported so it might just save lives in the future.

Report it!

The mechanisms used to do it, as well as culture around reporting incidents can make a big difference to whether incidents are reported. However, even when incidents are reported, the reporting systems and culture can help or hinder the learning that results.

Chrystie Myketiak at Queen Mary analysed actual incident reports for the kind of language used by those writing them. She found that the people doing the reporting used different strategies in they way they wrote the reports depending on the kind of incident it was. In situations where there was no obvious implication that a person made a mistake (such as where sterilization equipment had not successfully worked) they used one kind of language. Where those involved were likely to be seen to be responsible, so blamed, (eg when a wrong number had been entered in a medical device, for example) they used a different kind of language.

In the former, where “user errors” might have been involved, those doing the reporting were more likely to write in a way that hid the identity of any person involved, eg saying “The pump was programmed” or writing about he or she rather than a named person. They were also more likely to write in a way that added ambiguity. For example, in the user error reports it was less clear whether the person making the report was the one involved or whether someone else was writing it such as a witness or someone not involved at all.

Writing in the kinds of ways found, and the fact that it differed to those with no one likely to be blamed, suggests that those completing the reports were aware that their words might be misinterpreted by those who read them. The fact that people might be blamed hung over the reporting.

The result of adding what Christie called “precise ambiguity” might mean important information was inadvertently concealed making it harder to understand why the incident happened so work out how best to avoid it. As a result, patient safety might then not be improved even though the incident was reported. This shows one of the reasons why a strong culture of no-fault reporting is needed if a system is to be made as safe as possible. In the airline industry, which is incredibly safe, there is a clear system of no fault reporting, with pilots, for example, being praised for reporting near-misses of plane crashes rather than being punished for any mistake that led to the near miss.

This work was part of the EPSRC funded CHI+MED research project led by Ann Blandford at UCL looking at design for patient safety. In separate work on the project, Alexis Lewis, at Swansea University, explored how best to design the actual incident reporting forms as part of her PhD. A variety of forms are used in hospitals across the UK and she examined more than 20 different ones. Many had features that would make it harder than necessary for nurses and doctors to report incidents accurately even if they wanted to openly so that hospital staff would learn as much as possible from the incidents that did happen. Some forms failed to ask about important facts and many didn’t encourage feedback. It wasn’t clear how much detail or even what should be reported. She used the results to design a new reporting form that avoided the problems and that could be built into a system that encourages the reporting of incidents . Ultimately her work led to changes to the reporting form and process used within at least one health board she was working with.

People make mistakes, but safety does not come from blaming those that make them. That just discourages a learning culture. To really improve safety you need to praise those that report near misses, as well as ensuring the forms and mechanisms they must use to do so helps them provide the information needed.

Updated from the archive, written by the CHI+MED team.

More on …

Magazines …


Subscribe to be notified whenever we publish a new post to the CS4FN blog.



EPSRC supports this blog through research grant EP/W033615/1. 

Conjuring with logic: the remote control red-black mind meld

Magic tricks are just algorithms – they involve a magician following the steps of the trick precisely. But how can a magician be sure a trick will definitely work when they do it in front of an audience? Just like computer scientists who can prove their algorithms always work, a magician can use logic and deduction to be sure their tricks always work too.

A mixture of spread red and black playing cards
Image from Pixabay

Try the following trick on your own first, before reading about how it works or trying it with a volunteer. Take the role of both the magician and volunteer. I will do my best to remote-control the magic via my own mind-meld with you as you read my words, to try and make sure it works for you!

The magical effect

Take a full pack of playing cards and give them a good shuffle. Fan the cards face down. Now ask a volunteer to think of the colour RED and point to a card. Cut the pack at that point and count the top eight cards into a pile face down. Now ask them to think BLACK and touch another card. Cut the pack there and count out 7 cards onto the pile. Repeat this with 6 cards and then 5 cards having them think RED and then BLACK. Have the volunteer shuffle the selected cards then turn the pile face up.

4 piles of cards with matching "RED" and "BLACK" piles
Image by Paul Curzon

You take the cards that are left and shuffle them, keeping them face down. Have the volunteer now run through their cards taking out groups of cards that are together and of the same colour. They should put them either in a “RED” pile in front of them if they are a group of red cards, or in a “BLACK” pile if they are black, telling you how many cards they have placed in that pile. As they take each group of cards, you, focussing hard on your cards, but without looking at what they are, pick out the same number of cards from points through the pack as the volunteer put down, and put them in your own corresponding “RED” or “BLACK” pile in front of you, Place your cards face down. In this way, they end up with a pile of red cards and a pile of black cards, both face up in front of them. You end up with two corresponding face down piles in front of you. They have seen their cards but yours contain cards that you have not seen. Once they have run out of cards and you have placed your matching cards, stop and think for a moment, then go through your two piles and swap two cards without looking at them, saying you believe you made a couple of mistakes and those two ended up in the wrong piles.

Now, looking happy, tell the volunteer that through a mind-meld between you, them and the red and black cards you have, you believe, succeeded in your aim. Remind them that the piles were shuffled, they were responsible for the way the cards were split which was at random, and you haven’t seen any of your cards. One card out at any point and the trick would not have worked. Despite this, announce that you have managed to place the same number of red cards in your red pile as you have placed black cards in your black pile. Pass them the two piles in turn and ask them to check by first counting the red cards in your face down “RED” pile onto the table, and then do the same with the black cards that are in your “BLACK” pile.

Amazingly you have succeeded, the number of red cards in the red pile is the same as the number of black cards in the black pile.

Proving it always works

Did I mind meld with you to make it work? Or is something else going on? We can actually use logic and deduction (with some algebra) to show it works.

First we need to make a mathematical model of the situation – essentially describe the situation, or at least the parts of it that matter, in maths. That sounds a bit scary but it isn’t really. Its just giving names to some piles of cards! Let’s go through it…

In the trick, we end up with four piles of cards. A RED pile and a BLACK pile, both face up, in front of the volunteer and a RED pile and a BLACK pile, both face down, in front of the magician (see the picture above). We do not know how many cards are in each pile and it will be different each time we do the trick anyway because of all the shuffling. Luckily the actual numbers don’t matter. In the trick we care about the numbers of red cards and the numbers of black cards, Let us therefore use mathematical variables to represent these different numbers (that just means give them names!). Mathematicians often use names like x and y for variables, but to help us remember what they stand for we will use variations on R and B to mean numbers of red and black cards respectively.

So, we will use R to stand for the number of red cards in the volunteer’s face up “RED” pile (which are all red) and B to mean the number of black cards in the volunteers face up “BLACK” pile (which are all black).

Now for the magician’s face down piles. They have both red and black cards in each pile so we will write R1 to mean the number of red cards in the magician’s face down “RED” pile and B1 to mean the number of black cards in the magician’s face down “RED” pile. Similarly, we will write R2 to mean the number of red cards in the magician’s face down “BLACK” pile and B2 to mean the number of black cards in the magician’s face down “BLACK” pile. We have the situation as shown below in the picture..

4 piles of cards showing them labelled with variables R, B, B1, R1, R2 and B2

Image by Paul Curzon

In doing this we are doing a form of abstraction – hiding of detail – we have hidden the actual numbers of red and black cards in each pile within our description, describing them with variables as the precise numbers do not matter (and are different every time we do the trick anyway).

So far so good. Now, we want to try and prove that the trick always works. But how to start? First, just think of any facts you know about the situation (and especially anything you know about red and black cards). It may not be obvious how it can help, but write it down anyway!

Well the first thing we know is that a full pack of cards was used, and there are 52 cards in a pack, half (26) red and half (26) black. All these cards ended up on the table in one pile or another. So that means if we add up all the red cards in the four piles it will equal 26. How can we write this in terms of our variables? It is just:

R + R1 + R2 = 26

We add the three variables that stand for numbers of red cards and it equals 26. There are only three things to add for the four piles as one pile is all black. We can say a similar thing about the black cards:

B + B1 + B2 = 26

Now we have two different sums that equal the same thing (26) so we can put them together as equalling each other to get a combined equation which we will call EQUATION 1.

R + R1 + R2 = B + B1 + B2                                         (EQUATION 1)

That doesn’t seem to tell us much useful, but don’t worry, we are just gathering facts for now. What else do we know about how the trick worked? Well, every time the volunteer put some number of cards in their “RED” pile, the magician puts the same number of cards in their “RED” pile (though those cards may be red or black). That means that, throughout the two “RED” piles hold the same number of cards. The number of cards in one “RED” pile is R and the number of cards in the other “RED” pile is R1 + B1 (the reds plus the blacks in that pile). We can write this out as an equation:

R = R1 + B1

Now, this tells us that R is exactly the same as R1 + B1 so anywhere we see R we can replace it with R1 + B1. In particular, we can make this switch in EQUATION 1 to give:

(R1 + B1) + R1 + R2 = B + B1 + B2                                (EQUATION 2)

With the same logical reasoning, we can deduce an equation for the “BLACK” piles too. The number of cards in one “BLACK” pile is B and the number of cards in the other “BLACK” pile is R2 + B2 (the reds plus the blacks in that pile). We can write this out as an equation:

B = R2 + B2

Substituting R2 + B2 for B into EQUATION 2 we get EQUATION 3

(R1 + B1) + R1 + R2 = (R2 + B2) + B1 + B2                     (EQUATION 3)

Now, this seems to have just made things more complicated and not got us anywhere much, but we can now simplify it. Notice that there are two R1s on one side and two B2s on the other, each added, so we can group them together to get:

2R1 + B1 + R2 = R2 + 2B2 + B1

Also, on each side there is a B1 and that pair can cancel out (just subtract B1 from both sides and the equality holds but it is simpler), and on each side there is an R2 which can cancel in the same way. This leaves us with:

2R1 = 2B2

Of course the multiplication by 2 on both sides cancels too (just divide both sides by 2 and they will still be equal). We get:

R1 = B2

That is a very simple equation. It basically tells us that if you follow the steps of this trick that, whatever numbers of reds and blacks end up in each pile, R1 is guaranteed at the end to be the same number as B2. So what does that mean back in the real world? R1 just stands for the number of red cards in the magician’s “RED” pile. B2 just stands for the number of black cards in the magician’s “BLACK” pile. The equation we are left with just tells us that as long as we follow the steps (actually as long as we make the number of cards in each pair of piles match) then at the end the number of red cards in the magician’s “RED” pile will be the same as the number of black cards in the magician’s “BLACK” pile…and that is the “magical” result we predicted!

The trick will always work if you follow the steps!

Proving software and hardware always works

A magic trick involves the magician following steps precisely – following an algorithm. That is all computer hardware and software do – they follow algorithms to achieve some desired result (a magical effect). Just as we proved the trick always works, we can prove that other algorithms (whether implemented as a program or hardware) work using logical deduction too. That is one of the reasons why logic and deduction are so important to computer scientists. You do not want a trick to go wrong in front of an audience, so it is worth proving it always works. How much more important is it that all that software we now rely on for everyday life is error free. And what about a medical device keeping someone alive, or the software flying a plane. We want to be sure they always work. If they contain mistakes, people die. Logic and proof can therefore save lives, not just magic shows.

by Paul Curzon, Queen Mary University of London

More on …


Subscribe to be notified whenever we publish a new post to the CS4FN blog.



EPSRC supports this blog through research grant EP/W033615/1. 

Adrian Stokes: Internet pioneer

An abstract schematic of the UK part of the ARPANET. RAL and others connect to UCL which connects to the US via Norway.
Image by Paul Curzon

We take the Internet for granted now, but it is not that long ago that it did not exist at all. Disabled from birth with spina bifida, Adrian Stokes, OBE was one of the people who helped build it: a celebrated “Internet pioneer”. He was, for example, responsible for setting up the first email service in the UK and so the first transatlantic email system, as well as providing the service linking other universities in the UK to the network making it work as a network of networks in different countries.

He worked on ARPANET, the precursor to the Internet. It was a research project funded by the US department of defence exploring the future of communication networks. Up to that point there were global networks but they were based on what is called circuit switching. Think of an old fashioned telephone exchange, Each person had a direct line – an electrical circuit – connecting them to the operator. When you talked to the operator and asked to talk to someone over the phone, the operator would plug a wire that connected your line to theirs, making a new direct circuit from you to them. When you talked, your voice was converted to an analogue signal (a changing electrical signal) which passed down that wire – along the circuit. Transatlantic telephone cables even allowed circuits, so phone calls, to be set up between countries. Early computers connected to each other, sending data over phone lines in this way by converting them into sounds.

ARPANET worked differently to a circuit-based system. It was a packet switched network. It worked by treating data sent over a network as binary, just as the computer itself does internally. This contrasted with the analogue system then used to send sound over early phones. Importantly, the binary data being sent was divided up into fixed size groups of bits called packets. Each packet was then sent separately over the network. In this system there is no fixed circuit from source to destination that the data travels down, just lots of different computers connected to each other, On receiving packets of data each computer or node of the network passes it on to another until eventually it arrives at the target computer. A key advantage to this is that each of those packets can go by a different route, travelling between different computers. They can even arrive out of order, The data no longer travels along a single circuit. The packets are put back together (in the right order) on reaching the destination, reconstructing the original so that the fact it was ever split up is invisible to the person receiving the data. Extra information is added to the packets beyond the actual data to make the system work: such as a destination address to indicate where it is going to and the number of the packet so the order can be reconstructed if they do arrive out of order. Managing the packets and their journey to the destination is done by software implementing a protocol (a set of communication rules agreed between the computers on the network, that allows them to interpret the streams of bits arriving from other computers).

So ARPANET consisted of a series of computers that acted as nodes of the network. Each had to be programmed with software to run the protocol, passing packets on in their journey to the destination and pulling the original data out and reconstructing it if that computer was their destination. UCL were working with the ARPANET team, exploring how to make it work across continents, so had to program one of their computers to make it an ARPANET node. Once done it could connect to the ARPANET via a satellite link in Norway.

At first, the ARPANET was set up as a way just to access data on other computers as though it was on your own local computer. However, other services could be provided on top of the basic protocols. It just amounts to writing code for your node’s computer to turn data into packets and interpret the data in packets arriving in the way needed for the new application. For example, a way to access files on other computers as though they were on yours were added. Much, much later of course code to allow communication through a web page service was written and the world wide web was born to sit on top of the Internet.

This was one of the jobs Adrian Stokes did. He wrote code for the UCL computers that could treat packets of data as email messages rather than just files. Users could write messages and send them to people on other computers on ARPANET without them needing to know where they actually were. It was the first UK email service.

Once UCL had a link to the ARPANET, they could also extend ARPANET. One of Adrian’s other jobs was in managing onward links around the UK, creating a UK ARPANET network. Researchers in other UK universities could set up their own computers as ARPANET nodes (write and run the software on their computer) and then connect their computers to the UCL one. Networks their computers were linked to could then also connect to the ARPANET. In doing so they created a UK ARPANET network but one that was also connected to the full ARPANET via the UCL computer. It meant, for example, that anyone on the ARPANET in the US could (with permission as UCL added password protection to their node – the first on the ARPANET!) access the powerful IBM System 360/195 computer at the Rutherford and Appleton Labs in Oxfordshire. ARPANET became a transatlantic network of connected networks. Any of those UK universities could also then connect to any computer anywhere on the ARPANET. Their packets just went to the UCL one and then to the US via the satellite link, before being forwarded onwards to other US computers. If these UK university computers had the programs for the file transfer or email services, for example, then they could seamlessly use them to access files anywhere else or send messages to anyone else connected to the ARPANET anywhere.

ARPANET ultimately turned into what we now call the Internet. No single person invented the Internet, it was a massive team effort with lots of people involved each responsible for getting some part of it to work. Those like Adrian who played a critical part in making it work, however, have been recognised as “Internet pioneers”: those who can justifiably claim they were part of the team that invented the Internet, and transformed all our lives as a result.

– Paul Curzon, Queen Mary University of London

More on …

Magazines …


Subscribe to be notified whenever we publish a new post to the CS4FN blog.


This blog is funded by EPSRC on research agreement EP/W033615/1.

QMUL CS4FN EPSRC logos

Herman Hollerith: from punch cards to a special company

Herman Hollerith
Herman Hollerith (Image from wikimedia, Public Domain)

Herman Hollerith, the son of immigrants, struggled early on at school and then later in bookkeeping at college but it didn’t stop him inventing machines that used punch cards to store data. He founded a company to make and sell his machines. It turned into the company now called IBM, which of course helped propel us into the computer age.

Hollerith had worked as a census clerk for a while, and the experience led to his innovation. The United States has been running a national census every 10 years since the American Revolution, aiming to record the details of every person, for tax and national planning purposes. It is not just a count but has recorded information about each person such as male/female, married or not, ethnicity, whether they can read, disabilities, and so on.

As the population expanded it of course became harder to do. It was also made harder as more data about each person was being collected over time. For the 1890 census a competition was held to try and find better ways to compile the data collected. Herman Holerith won it with his punch card based machine. It could process data up to twice as fast as his competitors and with his system data could be prepared 10 times faster.

To use the machine, the census information for each person was recorded by punching holes in special cards at specific positions. It was a binary system with a hole essentially meaning the specific feature was present (eg they were married) and no hole meaning it wasn’t (eg they were single). Holes against numbers could also mean one of several options.

Hollerith punched card from wikimedia
Hollerith punched card (Image from wikimedia, Public Domain)

The machine could read the holes because they allowed a wire to make an electrical connection to a pool of mercury below so the holes just acted as switches. Data could therefore be counted automatically, with each hole adding one to a different counter. It was the first time that a system of machine-readable data had been used and of course binary went on to be the way all computers store information. In processing the census his machines counted the data on around 100 million cards (an early example of Big Data processing!). This contributed to reducing the time it took to compile the data from the whole country by two years. It also saved about $5 million

Holerith patented the machine and was also awarded a PhD for his work on it. He set up a company to sell it called the Tabulating Machine Company. Over time it merged with other companies until eventually in 1924 the resulting company changed its name to International Business Machines or is it is now known, IBM. it is of course one of the most important companies driving the computer age, building early mainframe computers the size of rooms that revolutionised business computing, but later also responsible for the personal computer, leading to the idea that everyone could own a computer.

Not a bad entrepreneurship legacy for someone who early on at school apparently struggled with, and certainly hated, spelling – he jumped out of a window at school to avoid doing it. He also did badly at bookkeeping in college. He was undeterred by what he was poor at though and focussed on what he was good at, He was hard working and developed his idea for a mechanical tabulating machine for 8 years before his first machine went to work. Patience and determination was certainly a strength that paid off for him!

More on …

Magazines …


Subscribe to be notified whenever we publish a new post to the CS4FN blog.



EPSRC supports this blog through research grant EP/W033615/1. 

Tanaka Atsuko: an electric dress

Wearable computing is now increasingly common whether wearing smart watches or clothes that light up. The pioneer of the latter was Japanese artist, Tanaka Atsuko, with her 1950s art work, Electric Dress. It was anything but light though, weighing 50-60kg, clothing her head to foot in a mixture of fluorescent and normal light bulbs.

Light reflecting from strip bulbs in a light bulb
Image by wal_172619 from Pixabay

She was a member of the influential Gutai (meaning concrete as opposed to abstract) Art Association and Zero Society of Japanese artists who pioneered highly experimental performance and conceptual art, that often included the artist’s actual body. The Electric Dress was an example of this, and she experimented with combining art and electronics in other work too.

Atsuko had studied dress-making as well as art, and did dress making as a hobby, so fashion was perhaps a likely way for her to express her artistic ideas, but Electric Dress was much more than just fashion as a medium for art. She had the idea of the dress when surrounded by the fluorescent lights in Osaka city centre. She set about designing and making the dress and ultimately walked around the gallery wearing it when it was exhibited at the 2nd Gutai Art Exhibition in Tokyo. Once on it flashed the lights randomly, bathing her in multicoloured light. Wearing it was potentially dangerous. It was incredibly hot and the light was dazzling. There was also a risk of electrocution if anything went wrong! She is quoted as saying after wearing it: “I had the fleeting thought: Is this how a death-row inmate would feel?”

It wasn’t the first time, electric lights had been worn, since as early as 1884 you could hire women, wearing lights on their heads powered by batteries hidden in their clothes, to light up a cocktail party, for example. However, Tanaka Atsuko’s was certainly the most extreme and influential version of a light dress, and shows how art and artists can inspire new ideas in technology. Up to then, what constituted wearable computing was more about watch like gadgets than adding electronics or computing to clothes.

Now, of course, with LEDs, and conductive thread that can be sewn into clothes and special micro-controllers, an electric dress is both much easier to make, and with programming skill you can program the lights in all sorts of creative ways. One example is a dress created for a BBC educational special of Strictly Come Dancing promoting the BBC micro:bit and showing what it was capable of with creativity. Worn by professional dancer, Karen Hauer, in a special dance to show it off, the micro:bit’s accelerometer was used to control the way the LEDs covering the dress in place of sequins, lit up in patterns. The faster she spun while dancing the more furious the patterns of the lights flashing.

Now you can easily buy kits to create your own computer-controlled clothes with online guides to get you started, so if interested in fashion and computer science why not start experimenting. Unlike Tanaka Atsuko you won’t have to put your life at risk for your art and wearable computing, overlapping with soft robotics is now a major research area, so it could be the start of a great research career.

by Paul Curzon, Queen Mary University of London

More on …

Related Magazines …


Subscribe to be notified whenever we publish a new post to the CS4FN blog.


This blog is funded by UKRI, through grant EP/W033615/1.

My first signs

Alexander Graham Bell was inspired by the deafness of his mother to develop new technologies to help. Lila Harrar, then a computer science student at Queen Mary, University of London was also inspired by a deaf person to do something to make a difference. Her chance came when she had to think of something to do for her undergraduate project.

Sign language relief sculpture on a stone wall: "Life is beautiful, be happy and love each other", by Czech sculptor Zuzana Čížková on Holečkova Street in Prague-Smíchov, by a school for the deaf
Sign language relief sculpture on a stone wall: “Life is beautiful, be happy and love each other”, by Czech sculptor Zuzana Čížková on Holečkova Street in PragueSmíchov, by a school for the deaf
Image (cropped) ŠJů, Wikimedia Commons, CC BY-SA 3.0 https://creativecommons.org/licenses/by-sa/3.0, via Wikimedia Commons

Her inspiration came from working with a deaf colleague in a part-time job on the shop floor at Harrods. The colleague often struggled to communicate to customers so Lila decided to do something to encourage hearing as well as deaf people to learn Sign Language. She developed an interactive tutor program that teaches both deaf and non-deaf users Sign Language. Her software included games and quizzes along with the learning sections- and she caught the attention of the company Microbooks. They were so impressed that they decided to commercialise it. As Lila discovered you need both creativity and logical thinking skills to do well at Computer Science – with both, together with a bit of business savvy, perhaps you could become the country’s next great innovator.

– Peter W. McOwan and Paul Curzon, Queen Mary University of London

More on …

Magazines …


Subscribe to be notified whenever we publish a new post to the CS4FN blog.



EPSRC supports this blog through research grant EP/W033615/1. 

QMUL CS4FN EPSRC logos