Beatrice Worsley: pioneering programmer

Female professional computer scientist working at a bank of screens — Image by Artista Digital from Pixabay

Many of the earliest programmers were women, just as before them many of the human computers were women. It was only later that somehow programming changed in people’s heads to be something men did. One of the earliest was Mexican born, Canadian, Beatrice Worsley. She wrote the first program to be run on the EDSAC computer and gained one of the earliest pure Computer Science PhDs on programming.

Beatrice was outstanding at both Maths and Science at school and at university demonstrated it by coming top in the class in many of the subjects she took during her degree, gaining grades corresponding to a First every year. She spent the war as a Wren in the Canadian Navy (including working as a researcher for the Navy) before going back to university to do a Masters at MIT. There she completed her project that involved surveying virtually all the computing devices of the time (whether completed or planned). Her survey not only included the very primitive computers being bulit immediately after the war, but also the earlier mechanical calculators, such as the ones IBM made its name creating, and differential analysers. The latter are analogue computing devices that were both precursors, and work in a completely different way, to today’s digital machines. Rather than converting data into 0s and 1s they manipulate physical equivalents of actual values as represented by wheels and discs. Unlike the digital computers to come which could be applied to any problem, they solved just one kind of mathematical problem so were not flexible in the way modern computers are.

This Masters thesis set her up for her future career as a computer scientist: she had realised by then that computing was the future. Initially, she got a job helping run IBM mechanical calculators in Toronto. As part of this job she actually built her own working differential anlalyser out of the children’s construction set Meccano.

At this point, Maurice Wilkes ar Cambridge University was building a new kind of machine called EDSAC. This differed from the very first digital computers in that it included stored programs – the program it followed was just data within computer memory, not something physically hard-wired into the machine. This followed the ideas first spelled out by Alan Turing in his description of a Turing Machine and developed by John von Neumann as the von Neumann architecture. It had the basic design we now think of as the basis of modern computers.

Beatrice was sent to Cambridge to find out more about it while it was being constructed, and got involved in getting it to work. It successfully ran its first stored program on 6 May 1949. That first program calculated a table of squares of numbers and it was written by Beatrice, making her the first programmer of what is arguably the first fully-fledged computer as we now know it (as opposed to a demonstration prototype). She also as a result wrote one of the earliest research papers about programs, describing this and other early programs and how they worked on EDSAC. She stayed on in Cambridge to do a PhD on the topic ultimately becoming one of the first people to gain a Computer Science PhD, and probably it was the first PhD about digital computers as we now know them. It built on the work of Computing giants, Alan Turing and Claude Shannon in discussing how programs could efficiently run not just on idealised machines such as Turing Machines, but on real ones like EDSAC. She also wrote more scientific programs for EDSAC, including one to correct pendulum measurements at sea, presumably in part due to her time as a WREN researcher Back in Canada. She also helped design an early programming language, Transcode, and co-wrote a sophisticated compiler for it based on their deep understanding of the hardware. This was because the computer at Toronto, the “Ferranti computer at the University of Toronto” was incredibly tricky to program in its machine code. Worsley could do it but many others struggled. Transcode in effect simulated an easy to program computer running on top of it, based on in idea by John Backus. As a result hundreds of people learnt to program it. Linked to this and starting with her PhD thesis she pioneered the use of programming libraries to make programming easier through her career.

Beatrice Worsley was not the very first person to write a program, or to get a Computing-linked PhD, but she was certainly one of the first, as well as one of the first people to work professionally as a computer scientist. She was certainly a computing pioneer whose programs made history and whose programming research made a solid contribution to the nascent discipline of programming. Computer Science certainly wasn’t a man’s world at the start, and there is no reason why it should be now.

Paul Curzon, Queen Mary University of London

Why ‘Correct’ Computers Can Be So Wrong

A dark, brooding vending machine — Image by Alexander Antropov from Pixabay

Have you ever followed a recipe perfectly, only to find the cake tastes… well, a bit weird? You followed every rule, measured every ingredient, and checked every step. The recipe said you did it right. But your taste buds, and your grandma’s disappointed sigh, told you something was definitely wrong. In the world of computer science, we have this problem all the time. We call it the difference between verification and validation.

Verification is like checking the recipe. Did you follow the rules exactly as written? A computer program called a “verifier” can look at the code a programmer wrote and check it against the “recipe” (the formal specification). If the code matches the recipe, it gets a big green checkmark. It’s officially “correct.”

But validation is like the taste test. Does the final cake actually taste good? Does it make people happy? This is about asking: did we make the right thing?

The Case of the Annoying Vending Machine

Imagine a new high-tech vending machine. Its specification (its recipe) says: “If a user inserts money and the selected item is out of stock, return the money.”

A programmer builds the machine. A verifier checks it. You put in a pound, press “B2” for salt and vinegar crisps, and it’s out of stock. The machine correctly spits your pound coin back out onto the floor.

Is the machine correct? According to the recipe, yes! Verification passed. Is it the right machine? No! It’s incredibly annoying!

Your expectation as a human was probably completely different. You expected it to say, “Sorry, B2 is out of stock. Please choose something else.” You expected it to hold onto your money and let you make another choice. Cheese and Onion Crisps are just as good. The machine followed the rules, but it completely misunderstood what you, the user, actually wanted. It was correct, but wrong.

This is the frustrating gap where most “bad” software lives. It follows its own strange rules perfectly but seems to have no common sense about what people actually expect.

Teaching the Genie to Read Minds (Almost!)

So how do we fix this? Our research introduces an idea called Semantic Expectation Logic (SEL). It sounds complicated, but the core idea is simple: what if we could teach the computer to understand not just its own recipe, but also the collection of fuzzy, unwritten expectations that people have in their heads?

Think of it like upgrading from a rule-following genie to a mind-reading one.

A rule-following genie gives you exactly what you wish for. If you wish to “be on a flight”, it might put you on the wing of a 747. Technically correct, but not what you expected!

SEL is our attempt to build a “mind-reading” genie for software. We do it in three steps:

Write Down the Rules of the World: We tell the computer about fundamental truths. For the vending machine, a rule might be “Money can only be returned after a transaction is finished or explicitly cancelled by the user.”
Ask People What They Expect: Instead of guessing, we show people what the machine does in different situations. “The machine just spat your coin on the floor. Is that what you expected?” We collect all these “yes” and “no” answers, along with why. We call this “mining expectations”.
Check for Gaps: Our SEL tool then looks at what the machine actually does and compares it to both the “Rules of the World” and the “Mined Expectations”.

It might find:

A Bug: The machine sets itself on fire. (It violates a Rule of the World: “Vending machines should not set themselves on fire.”)
A Validation Failure (The “Aha!” Moment): The machine follows its own rules perfectly but violates a strong expectation. Our tool would flag this: “Warning! 98% of people expected the machine to ask for another choice, but it just returned the money. This is a Surprise!”

We even created a “Surprise Factor” metric that gives a score from 0% to 100% for how surprising a piece of software is. A low score means the software behaves as people expect. A high score means you’ve built a technically “correct” but incredibly annoying vending machine.

By making expectations a central part of the testing process, we can start building software that isn’t just correct according to its own bizarre logic, but is also correct in a way that actually makes sense to the people using it. We can build the cake that not only follows the recipe but also tastes great.

Vasileios Klimis, Queen Mary University of London

Getting Technical

Read the research paper:
- A Logic for Validating Stakeholder Expectations

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

Johnny Ball’s ‘Two Wrongs Do Make a Right’ Trick

(or how to stack properly)

A girl holding a 4 of Hearts — Image by Adina Voicu from Pixabay

We present a CS4FN exclusive (from our archive): a mathematical card trick contributed by TV celebrity mathematician, Johnny Ball. The BAFTA-winning father of radio DJ Zoë Ball is famous for his TV shows like Think of a Number, Think Again and Johnny Ball Explains All, plus numerous brilliant books on maths and science.

The trick is as follows, in Johnny’s words…

There is a very simple card trick that I often use, as I can get to the explanation very quickly. In fact, for a mathematically minded audience, they are already some way to working out why it works, as soon as it does work. It’s called the Two Wrongs Do Make a Right Trick.

Just memorize the top card of a pack; let’s assume it’s the 4 of Hearts. Hand the pack to someone and ask them to choose any smallish number (eg between 1 and 10), then to deal that number of cards face down. Then announce the next card dealt will be the 4 of Hearts. Oops – it isn’t? Get them to place all the dealt cards on top of the pack again. Now ask them to choose a number bigger than the first one, but not so big that we run out of cards (eg between 10 and 20). They now deal that number face down, and the next card dealt will be the 4 of Hearts. Oops – wrong again. Let’s now see if we can make two wrongs equal a right.

Place the cards back on top. Now ask for a last chance. Take the smaller number from the larger. They now deal that number face down, and the next card dealt is the 4 of Hearts. Success!

Why does it work?

Hidden in this distracting presentation, the tale of your mistakes played up for laughs, is some clever mathematics. It uses a magic technique called a stack, which is a set up sequence of cards in a known order. Sometimes magicians will put a pre-defined stack of cards, for example four aces, on top of the deck and do a false shuffle, and then be able to deal a wining poker hand because they know exactly what cards will be dealt. In this trick your ‘mistakes’ create the stack for you.

X stacks the deck

Starting with your known card on top (that’s your secret card), your spectator chooses a number from 1 to 10. Let’s call that number X. You deal down X cards so that the first card down is the secret card, next down is the second from the original top of the pile and so on. At the end of your count of X there are X cards on the table, with the secret card on the bottom. Oops, mistake number one. Don’t worry, you can regroup. Just place the mistaken card back on top of the pile of undealt cards, then stack those X dealt cards back on top, and your deck now looks like this from the top down: (X-1) indifferent cards, the secret card, and the rest of the pack.

Y marks the spot

Second try – this time you ask for a bigger number, a number between 10 and 20. Let’s call that new number Y. Counting and dealing down Y cards, where number Y is bigger than number X, means that once Y cards are on the table you can reveal mistake two, oops again. But let’s ‘think of the numbers’ of the cards on the table. That pile has Y cards, and because we stacked the deck in the first phase the secret card is now at position X from the bottom of these Y cards, meaning it’s at position Y-X. Exactly the position in the stack to be revealed by the finale where you subtract X from Y and count down (oh wait, that’s another mathematical TV programme).

Think again – with some real numbers!

The algebra of Xs and Ys says it works, but to see this is true let’s test it and think of some specific numbers, say X=5 and Y=15. The first deal stacks the secret card at position 5 from the top. We then do the second deal of 15 cards, reversing as we go. Onto the table goes 1, 2, 3, 4, SECRET, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15. Pick up this pile and put it on top of the pack. The secret card is now in a new stack. From the top down it’s at 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, SECRET, rest of pack. Now count down 10 cards from the top of this new stack (that’s X-Y = 15-5 = 10), dealing 10 cards from the final stack gives us 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, and the next card is the SECRET card! Magic.

Proving algorithms work

A magic trick like this is what computer scientists call an ‘algorithm’: steps that if you follow them guarantee some result – here that your secret card is revealed. What we showed above is a logical, mathematical proof that the trick works. Now, programs are just algorithms (written in a programming language) so in the same way as we proved our trick works we can prove logically that a program we write always works too!

Even if you do do such a proof, it is also a good idea with software to do lots of testing too – putting in some values to check it works for specific cases too (lots more than the one example we checked). Doing that first can also help you come up with the proof.

Finale the stack pays off

Stacks, in this case the series of cards in a given order, that you deal from the top of the pack, are also used in computer science, though the meaning is slightly different. It is a data structure, a place to store information, that works like a stack of chairs. You can add a chair or take one from the top of a stack of chairs but not from the middle, and its the same with adding and removing data in a computer science stack.

Computer scientists like to have ways of thinking of data, normally numbers in the computer memory, in such a way that they know where things are so they can use them when they need them. A stack is an example of what computer scientists call an abstract data type, a data structure with rules of how you add and remove data to and from it. The stack is a ‘container’ of data (or nodes if the things stored are more complex than just plain numbers, and link off to other parts of memory). Computer scientists do two basic things to stacks: they ‘push’ and they ‘pop’. In a push a new element is added to the top of the stack, and all those elements under effectively move down a place. It’s like adding those cards on top of the secret card. In a pop the top element is removed from the stack, and up jumps all the elements underneath, like dealing a card from the top of the deck. Your laptop and your mobile phone will have a stack somewhere in them. The software will be pushing and popping and doing lots of other clever computer science tricks to keep track of the information and how it’s moving around. The programmer will probably use even smarter things like stack pointers. These are a note for the computer to tell it what was last changed and where in the stack it was.

One too many?

One of the nastiest (and easiest to make) errors in computer software can come from something called a stack overflow. A program pops from or pushes to the top of the stack. That position in memory is kept track of using the ‘stack pointer’, which is just like a sign pointing to where the top of the stack is. So we push and pop from where the stack pointer is pointing changing the position of the pointer as we do. A stack normally has a fixed maximum size (like hitting the ceiling with a stack of chairs). A stack overflow is where you shoot off the end of the stack, so where you try to push a value on the stack when it is already full. It is like a magician counting past 52 cards. It can only end in tears. Sometimes this nasty trick is used by computer hackers to gain control of a computer system. Once the stack has been overshot, the computer surrenders. The software has literally lost its place, and the hackers can move in and take over.

Fortunately maths can come to the rescue by creating tests to ensure that the stack doesn’t pop its clogs or push up the daisies. Even better you can prove that the program controlling the stack (just an algorithm) never lets you overflow the stack in the same way that we proved our trick always works.

Let’s pop over and give the last word to Johnny

Ever ready to make things simple to understand and easy to do, Johnny points out:

You can reduce the trick to choosing just 1 and then 2 with just three cards, and show that the manoevring moves the top card down by the difference in numbers chosen.

Now why didn’t we think of that?

Peter W McOwan, Paul Curzon, Queen Mary University of London

but critically of course (and also inspiring us about Maths since we were kids), Johnny Ball

More on …

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

Wright of Derby: science from the shadows

A group gathered round an experiment removing air from a flask containing a bird, lit by candle and moonlight. — Image An Experiment on a Bird in an Air Pump by Joseph Wright of Derby, 1768. Public Domain via Wikimedia.

The National Gallery in London currently has an exhibition on the British Painter: Joseph Wright: ‘From the Shadows’. But why might scientists care about the work of artists?

First of all, artists have been investigating light, colour, perception and illusions and the way our brains process this far longer than science as such has even existed, never mind used to study those phenomena. They built a massive foundation of knowledge upon which our current visual technology relies from the pixel grids of screens to the way we construct 3D computer generated imagery, and virtual reality worlds. Much of our modern technology is based on the knowledge created by artists, not just scientists and engineers. And Joseph Wright was a master of the use of light (and dark).

He is particularly famous for his paintings of candlelit scenes full of highlighted faces emerging from shadows as featured in the National Gallery exhibition. This use of extreme light and dark to conjure a feeling of drama didn’t start with him, though. It was pioneered and perfected by painters like Caravaggio and Rembrandt who were his inspiration. However, they used the technique in paintings depicting scenes from history, the Bible and ancient mythology. He grew up in the middle of the Industrial Revolution with Derbyshire being the source of the industrial Revolution with the first cotton factories powered by water built in the area around Matlock and the first water-powered silk mill built in Derby itself. Wright painted both the first Cotton Mill at Cromford and the pioneer of the industrial revolution responsible, Sir Richard Arkwright. Immersed in the spirit of the age he was the first professional painter to paint in this dramatic style of light and dark scenes of science and engineering.

His paintings were essentially works of public engagement with science and technology. In this he is one of the first to take public engagement for the masses seriously. He died in 1797, 2 years before the Royal Institution was founded, now famous for its Christmas Lectures which pioneered science demonstrations for all. They were initiated by Faraday in 1825. Wright didn’t just paint these scenes of technology and of people watching science demonstrations. After all a painting would only be seen by a small number of people. and possibly only the family and friends of the person who commissioned it. Wright also took his work to the masses by commissioning mezzotints of his paintings. These were high quality black and white prints that could be relatively cheaply mass-produced so widely disseminated. Mezzotints were even portrayed back lit in shop windows so that anyone could see them from the street.

It is more important as ever that Scientists engage with the public about their work, and artists still provide one way to do so. So what would Joseph Wright be painting now in the current computer and AI revolution? Children wearing virtual reality goggles, arms out touching non-existent things, with astounded expressions perhaps? A group gathered round a robotic arm picking up an egg? All lit of course by the screens of smartphones.

Granite: games for good?

Curlers sweeping in front of a stone amongst other stones. — Image by AS Photography from Pixabay

Are video games good or bad for you? One game certainly did a lot of good for Bruce Mouat. He started playing a video game called Granite when he was only 8. It is a Curling game. As an adult he leads the GB Curling team in the Olympics and is one of the best players in the world, having multiple world gold medals.

Curling is a sport requiring both physical skill, strategy and nerve. It involves sliding polished stones of super hard granite down an ice track. The aim is to try and land your stones nearest the centre of a series of concentric circles 40 or so metres away. Despite the distance, millimetre accuracy is often needed. It is also called curling because the stones do not run in a straight line but curve their way into the target, in part controlled by sweepers who sweep the ice in front of the stones to alter the curl of the path as well as the distance.

It is an incredibly strategic sport with the players having to think several moves ahead, but then having to put that strategy into practice with their skill. In that way it is very much like Snooker. That is where the video game came in. Obsessed with the video game as a child, he became outstanding at the decision making in the sport by playing the video game against his granny. The reason the video game helped was because it is more than just a game, it can just as well be called a simulation, like a flight simulator. The latter are considered so accurate that pilots train on them to gain the hours needed to become skilful controlling a plane. That is what the video game Granite does for Curling.

To work as a simulator it needs what is called a physics engine. The programmers have to code the actual physics of polished granite stones sliding on ice and of ice being swept, covering all the small differences made by ice temperature, the speed of the sweeping and so on. The programmers, who were married curlers themselves, made the physics so accurate, that everything in the game behaves as close to possible as it would in reality. That means you can really learn strategy by playing it, even if you then still have to back that by hours of practice playing real curling to gain the physical skill to land stones exactly where you want them. It also can of course help inspire people to start to play the sport in reality.

In the 2026 Olympic final Bruce and Team came away with their second Silver medal, won in consecutive Olympic games, this time beaten by Canada. Even in losing the final match, Bruce Mouat made some absolutely amazing shots, both in terms of strategy and perfect physical skill under extreme pressure.

So playing a video game can certainly be for good: when the physics is so good it acts as a simulator and so can be a way to put in the hours of practice needed to be world leading, but just for fun. So have a go at playing Granite and maybe you will also gain a love of the game and so sport, then one day become a Winter Olympian yourself. Or if you love some other game or sport and learn to program, perhaps you could code a perfect simulator for it to give future players who enjoy your game an edge in the sport.

The Proof of Love

A pseudocode poem in a red heart:
Violets are violet
if roses are red and violets are blue
then
Life is sweet
else
I love you — Image by CS4FN

For Valentine’s day we created this card with a pseudocode love poem. But what does it mean? Is it a statement of love or not? Now that Valentines Day is gone and logic and rational thinking are starting to reassert themselves, here is a logical argument of what it means: an informal proof of love.

We are using our own brand of poetic pseudocode here, and what matters is the formal semantics of the language (ie mathematical meaning).

What we will do is simplify the code to code that is mathematically equivalent but far simpler, explaining the semantics as we do. We will by reasoning in a similar way to doing algebra, just replacing equals with equals.

First let’s write the poem out in more program looking notation, making clearer what are statements (actions) and expressions (things that evaluate to a value. In the English reading version we are using the verb TO BE in both ways which confuses things a little.

Let’s make clear the difference between variables (that hold values and values). The colours are all values (data that can be stored) – so we will write them in capitals: RED, BLUE, VIOLET. The flowers are variables (places to store values) so we will leave them as lowercase: violets, roses. Then the title becomes an assignment (written more formally as :=). It sets the value of variable violets to value VIOLET. (We are pedantic and believe the colour of violet flowers is violet not blue!)

What comes after the keyword IF is an expression – it evaluates to a boolean (TRUE value or FALSE value) so is referred to as a boolean expression. You can think of boolean expressions as tests – true or false questions. We will use == to indicate a true/false question about whether two things are the same value.

The other two lines are statements – think of them as print statements that print a message as the action they do.

The algorithm of the poem then is:

violets := VIOLET;
IF ((roses == RED) AND (violets == BLUE))
THEN
    PRINT "Life is Sweet"
ELSE
    PRINT "I love you"

Now let us simplify the algorithm to an equivalent version a step at a time. In the assignment of the first line, the variable violets is set to value VIOLET and then not changed, so we can substitute the value (a colour in uppercase) VIOLET for variable violets (in lowercase) where it appears, and remove the assignment. This gives a simpler version of the algorithm that does exactly the same:

IF ((roses == RED) AND (VIOLET == BLUE))
THEN
    PRINT "Life is Sweet"
ELSE
    PRINT "I love you"

Now in the boolean expression, we have the subexpression

(VIOLET==BLUE)

but these are two different values and this is asking whether they are the same or not. It evaluates to true if they are the same and FALSE if they are different. It is therefore equivalent to FALSE so the whole expression becomes:

(roses==RED) AND FALSE

The original algorithm is equivalent to

IF ((roses == RED) AND FALSE)
THEN
    PRINT "Life is Sweet"
ELSE
    PRINT "I love you"

Now whatever X is a boolean expression (X & FALSE) will always evaluate to FALSE because it needs both to be TRUE for the whole to be TRUE. The whole boolean expression therefore simplifies to FALSE and the algorithm to:

IF (FALSE)
THEN
    PRINT "Life is Sweet"
ELSE
    PRINT "I love you"

Notice how this means it does not matter what colour the roses are at all. Whether roses are red, white, blue or something else, the algorithm result will not be affected.

The semantics of an IF statement is that it evaluates exactly one of its two statements. Where its test (boolean expression) evaluates to TRUE, it executes the first THEN branch (here the Life is Sweet branch) and ignores the other ELSE branch (the I love you branch). Where its test evaluates to FALSE it instead ignores the THEN branch completely and executes the ELSE branch.

Here the test is FALSE, so it ignores the THEN branch and is equivalent to the ELSE branch. The algorithm as a whole is exactly equivalent to the far simpler algorithm:

PRINT "I love you"

Going back to the poem, it is therefore logically completely equivalent to a poem
I Love You

We have given a mathematical proof of love! The idea though is that only computer scientists with a formal semantics (ie maths meaning) of the pseudocode language used would see it!

Can a program beatbox (using physics)?

A rapper — Image by Casey Budd from Pixabay

Can a translation program make music? It turns out they potentially can – they can beatbox! In the future perhaps Artificial Intelligences will be able to do creative beatboxing the way human beatboxers do.

Beatboxing is a kind of vocal percussion used in hip hop music. It mainly involves creating drumbeats, rhythm, and musical sounds using your mouth, lips, tongue and voice. So how on earth can Google Translate do that? Well a cunning blogger worked out a way. Once on the Google Translate page they first set it to translate from German into German (which you could do then). Next they typed the following into the translate box: pv zk pv pv zk pv zk kz zk pv pv pv zk pv zk zk pzk pzk pvzkpkzvpvzk kkkkkk bsch; Then when they clicked on the “Listen” button to hear this spoken in German. Google translate beatboxed.

So how do programs like Google Translate that turn text into speech do it? The technology that makes this possible is called ‘speech synthesis’: the artificial production of human speech.

Originally, to synthesise speech from text, words are first mapped to the way they are pronounced using special pronunciation (‘phonetic’) dictionaries – one for each language you want to speak. The ‘Carnegie Mellon University Pronouncing Dictionary’ is a dictionary for North American English, for example. It contains over 125 000 words and their phonetic versions. Speech is about more than the sounds of the words though. Rhythm, stress, and intonation matter too. To get these right, the way the words are grouped into phrases and sentences has to be taken into account as the way a word is spoken depends on those around it.

There are several ways to generate synthesised speech given its pronunciation and information about rhythm and so on. One is simply to glue together pieces of pre-recorded speech that have been recorded when spoken by a person. Machine learning provides a new way to do it – machine learning programs are trained on vast amounts of recorded speech and learn the natural way humans speak from listening to humans actually speak. That gives a way to overcome the problems of just using pronunciation dictionaries.

Another way uses what are called ‘physics-based speech synthesisers‘. They model the way sounds are created in the first place. We create different sounds by varying the shape of our vocal tract, and altering the position of our tongue and lips, for example. We can also change the frequency of vibration produced by the vocal cords that again changes the sound we make. To make a physics-based speech synthesiser, we first create a mathematical model that simulates the way the vocal tract and vocal cords work together. The inputs of the model can then be used to control the different shapes and vibration frequencies that lead to different sounds. We essentially have a virtual world for making sounds. It’s not a very big virtual world admittedly – no bigger than a person’s mouth and throat! That’s big enough to generate the sounds that match the words we want the computer to say, though.

These physics-based speech models also give a new way a computer could beatbox. Rather than start from letters and translate them into sounds that correspond to beatboxing effects, a computer could do what the creative beatboxers actually do and experiment with the positions of its virtual mouth and vocal cords to find new beatboxing sounds.

Beatboxers have long understood that they could take advantage of the complexity of their vocal organs to produce a wide range of sounds mimicking those of musical instruments. Perhaps in the future Artificial Intelligences with a creative bent could be connected to physics-based speech synthesisers and left to invent their own beatboxing sounds.

by the CS4FN team (adapted from the archive)

Cyber Security at the movies: Catwoman

SPOILER ALERT

A cat sat on a branch silhouetted by an orange moon — Image by bess.hamiti@gmail.com from Pixabay

The 2004 film Catwoman, starring Halle Berry as Patience Phillips (and Catwoman), has been voted as one of the worst films of all time, and has won multiple Razzies (Golden Raspberry Awards) – Halle Berry accepted hers while holding her Best Actress Academy Award. Now, however, it has a bit of a cult following. It did at least feature an African American woman as the lead, in a superhero film, possibly for the first time, and came long before Black Panther. Whether it deserves either accolades or condemnation, it certainly features some of the worst cyber-physical security seen in a film by a corporate giant. So what can we learn about cyber-physical security from the film?

The weakest link

The plot is based around the cosmetics firm Hedare Beauty and its development and product launch of a new face cream that reverses the affects of aging. Clearly, a big corporate player, the firm has a massive team at their headquarters that includes artist Patience working on PR, but also a massive research and industrial complex, developing testing and manufacturing its products. Now, cyber-criminals do not just include hackers out to cause anarchy or extort money from people, they also include people working for companies, sometimes supported by their countries, doing industrial espionage: trying to steal research and development secrets. By stealing the designs or product formulae of their competitors, such companies aim to save the massive time and development costs of doing it themselves. They then quickly produce rip-off products to steal the market. Gaining secrets can also gain criminals advantage through insider trading, buying and selling shares, so making money on the back of secret information about what is about to happen. Companies, therefore, have to take industrial espionage seriously, and that means taking cyber-security seriously too.

In Catwoman, the company, Hedare Beauty, have the normal kinds of industrial secret but also a big nasty one too, so their bosses have even more reason to put a lot of effort into security. They certainly have lots of heavies with guns looking to shoot people. However, their physical security is actually totally lax.

This is first seen when Patience’s love interest, Detective Tom Lone, merrily walks into the corporate headquarters and up to her open plan desk where she is working on the product launch to ask her for a date. How did he get in? Why isn’t anyone accompanying him in such a sensitive area especially days before a crucial launch? Where is his visitor’s pass and why isn’t he being challenged. Perhaps this can be put down to being a cop (perhaps he waived his badge about) but still someone senior should have accompanied him surely (and is returning Patience’s purse (his excuse) really a good enough reason to bypass security whoever you are?)

However, even if we let that go, later Patience has to deliver some artwork by midnight to the boss out at the industrial complex. That is where the real secrets, good and bad, are. When she gets there the foyer is locked and dark with no one on duty. In many thrillers, the heroes have to use sophisticated gadgets, amazing technical or physical skill, or subterfuge to overcome the massively sophisticated hi-tech security. Patience, by contrast, just wanders round the back looking for another way in and finds a fire door ajar. This allows her to both enter and ultimately make it to the heart of the building where secrets are being discussed. As a result she overhears (if accidentally) something she should not hear…

Perhaps the most important principle of cyber-security is that it is as weak as its weakest link. You can have all the high tech multi-factor biometric authentication systems, impossible to crack encryption, experienced and well-trained former SAS guards patrolling the foyer, and so on, but if you leave a back door open then the criminals will just ignore all your high tech security and walk in through that one back door. That is exactly what Patience does. There is no point as, for example, I have seen in real life, checking everyones access cards on a main gate, when there is an un-manned side gate. The criminals aren’t going to even try to enter through the front gate. Likewise, if you have a weak point in your cyber-security system, it does not matter how massively strong the rest is.

It is also better to think not of just cyber-security, anyway, but of cyber-physical security. The weakest links can just as easily be to do with physical security as with the computerised part – like the open door Patience found, or letting someone claiming to be a Detective to walk around anywhere in the building. Once the “Detective” is in, they can gather information to launch other attacks from other weak points they now have access to (like passwords written on post-it notes, an access card left on someone’s desk, or computers left unlocked, for example). So poor physical security can be the weak link allowing a backdoor into the computer system.

Another point from the film is that, whether cyber security or physical security, just being “inside” (a computer or a building) should not give access to everything. As you move through a building or through a computer system, there should be more locks to get through, more authentication tests to pass, with different levels of access for different people

Patience should never have got into the building, but even if she had, she shouldn’t have got further than the corridor. Luckily (!) for her, she did with the ultimate result that she gained superhuman powers and became Catwoman, so perhaps sometimes bad security is not all bad (if only in a world where people can gain superpowers from cats).

Magazines …

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

Pseudocode Poems

A purple flower with dew drops — Image by AdelinaZw from Pixabay

Pseudocode poems are poems that work both as a poem and as an algorithm so can be read or executed. They incorporate sequencing, selection or repetition constructs and other kinds of statements to take actions. You can implement them as an actual program. Below are our attempts. Can you write better ones?

Poems often use the ambiguity in language and aim to affect emotions. Pseudocode is intended to be precise. Programs certainly are. They do something specific and have a single precise meaning. Writing pseudocode poems that do both can be a lot of fun: just like writing normal programs is. The idea was inspired by Bryan Bilston’s poem ‘Two Paths Diverged’. Read it here or buy his wonderful book of poems, ‘ You took the last bus home’.

I am not a great poet, but here are some of my attempts at pseudocode poems to at least give you the idea. They are, in turn, based on the core control structures of Sequencing, Selection and Repetition. They also use print statements and assignments to get things done,

Sequencing

This pseudocode poem is based on sequencing: doing things one after the other.

What am I when it’s all over?

I am dire.
I am fire.

I am alone.
I am stone.

I am old.
I am cold.

We use the verb TO BE to be the equivalent of assignment: setting the value of a variable. Here it is implemented as a Python program.

def whatamI():
	"""What am I when it's all over?"""

	I = 'dire'
	I = 'fire'
	
	I = 'alone'
	I = 'stone'
	
	I = 'old'
	I = 'cold'
	
	print(I)

Selection

Here is a pseudocode poem based on selection, which is the second core control structure. It chooses between two option based on a boolean test: a true / false question. The question here is: do I love you? Dry run the algorithm or run program to find out.

Violets are violet
if roses are red and violets are blue
then
    Life is sweet
else
    I love you

Here it is implemented as a Python program (with appropriate initialisation).

def violetsareviolet():
	"""Violets are violet"""
	roses = 'red'
	violets = 'violet'
	
	if roses == 'red' and violets == 'blue':
		print('Life is sweet')
	else:
		print('I love you')

violetsareviolet()

There is also a proof of what it does/means here. Find out more about Selection based pseudocode programs via our computational literary criticism of Rudyard Kipling’s poem “If”.

Iteration or Repetition

The final kind of control structure is iteration (i.e., repetition). It is used to repeat the same lines over and over again.

Is this poem really long?

it is true
while it is true
    this is short
it is endless

Here it is implemented as a Python program.

def isthispoemreallylong():
    """Is this poem really long?"""
    it = True
    while (it == True) :
        this = 'short'
    it = 'endless'

isthispoemreallylong()

Can you work out what it does as an algorithm/program, rather than as just a normal poem? You may need a version with print statements to understand its beauty.

def isthispoemreallylong2():
    """Is this poem really long?"""
    it = True
    while (it == True) :
        this = 'short'
        print("this is " + this)
    it = 'endless'
    print("it is " + it)

isthispoemreallylong2()

The word while indicates the start of a while loop. In the pseudocode, it is a command to repeat the following statement(s). It checks the boolean expression after the body each time. Only if that boolean expression is false does it stop. In this case the body sets the variable named this to string value ‘short’. The test is about a different variable though which is not changed inside the loop, so once in the loop there is nothing that will ever change the variable it so the value of the test will always be the same. Variable it will always be True and the loop will keep setting variable this to value ‘short’, over and over again. This means the loop is a non-terminating loop. It never exits so the lines of code after it are never executed. As a program they are never followed by the computer. The variable it is never set to the value ‘endless’.

Overall the poem is short in number of lines but it is actually endless if executed. It is the equivalent of a poem that once you start reading it you never get to the end:

it is true 
check it is true 
this is short
check it is true 
this is short
check it is true 
this is short
...

Here is a more romantically inclined poem for Valentine’s day (since at the time of writing, it is coming up) again using repetition

My love for you is endless

my love is true
while my love is true
    I love you

Here it is implemented as a Python program.

def myloveforyouisendless():
"""My love for you is endless"""
my_love = True
while my_love == True:
    print('I love you')

myloveforyouisendless()

Pseudovode love poem surrounded by hearts

In the pseudocode of this poem the verb “to be” is used for two different purposes: as an assignment statement (it is true is used as a statement to mean it = True) and as a boolean expression (it is true is used as a boolean expression to mean it == True). As an assignment it is used as a command to do something. As an expression it is something representing a value: it evaluates to either true or false. Confusing these two English uses is a common mistake novices make programming, and shows one of the ways why programming languages are used with different symbols for different meanings, rather than natural languages.

Now it is your turn. Can you write a great poem that can also be executed?

Paul Curzon, Queen Mary University of London

Answers

The selection poem is about a volcano, but the answer to the question in the title is ‘cold’.
Assuming you agree with me that violet flowers are violet (or at least not blue) then clearly we are compatible at least in being pedantic and you will find I love you.

If: a computational literary criticism

If, by Rudyard Kipling is an inspirational poem that was voted the UKs favourite poem in the 1990s. It consists of a series of lines that start with If. What If, by Benjamin Zephaniah is a more subversive poem modelled on the original.

If statements, of course, are a really core part of programs so are these poems, given they are all about IF, algorithms? The use of If here isn’t quite the same as a pure computational one as seen in programs. For a start, it doesn’t follow the structure of a computer science IF statement. Here are a few lines:

If you can keep your head when all about you
  Are losing theirs and blaming it on you,
If you can trust yourself when all men doubt you,
  But make allowance for their doubting too;
...

In programs, an IF statement has a specific structure. It consists of a test of something that is true or false but then gives a specific action to take when the statement is true. The lines

you can keep your head when all about you are losing theirs AND blaming it on you,

is more or less such a true or false statement. Either you can keep your head or you can’t. This though ignores the possibility of you sometimes losing your head and sometimes not. The poem presumably means to say that you must ALWAYS keep your head. What exactly does “when” here mean too? The reason we do not use English when writing programs is the lack of clarity of what is actually meant. Programs are mathematically precise in their meaning. They do only have one possible meaning (and that is the point). this is also a potential issue of writing programs by instructing AIs over what you want in English!

This boolean expression (something that evaluates to true or false) also uses a logical connective AND just like in a program – you must both be keeping your head AND people must be blaming it on you for the whole to be true. If they are both true then the action that follows is taken, but if they aren’t both true the poem says nothing about you!

Another issue in If, is that this test / boolean expression is not immediately followed by an action to do when it is true. The action comes right at the very end of the poem

...
Yours is the Earth and everything that's in it,
And - which is more - you'll be a Man, my son!

This comes after a whole series of these partial IF statements. To make it more clearly like a program you would add a more explicitly IF-THEN structure, which is the equivalent of putting ANDs between all the tests. In a program that would be written more like the following:

IF you can keep your head when all about you
  Are losing theirs and blaming it on you,
   THEN IF you can trust yourself when all men doubt you,
              But make allowance for their doubting too;
...
...
                             THEN Yours is the Earth and everything that's in it,
                                        And - which is more - you'll be a Man, my son!

Only if all the tests are true does the final action get taken. Though it isn’t really an action, it is more an assertion that something else is true – “the Earth is yours”, rather than “we give you the Earth”. (Also that final And is no longer a logical connective!)

Poems like this could be made more explicitly computational though. For example, a slightly more computational version might be:

IF you can keep your head when all about you
   Are losing theirs AND blaming it on you
THEN I will thank you, giving you a pay rise too
...

A love poem in this vein might start

IF you are a snail 
    THEN I will become your shell.
IF you are a ...

This leads on to the idea of pseudocode poems, that use other computational constructs. More of that to come.

To do …

Write your own poem in this style with true/false questions followed by specific actions, modelled on the computational version of IF. It could be a reworking of If itself or a completely different poem.

	Music AI Kriss Kross… on The day the music didn’t …
	Music AI Kriss Kross… on Separate your stems
	Musical Algorithms… on You’ll be Bach! – create…
	The art of animatron… on I’m (not) a little …
	The Decline and Fall… on Victorian volunteers needed…