The Castlerigg Project

Introduction

The Castlerigg Project was undertaken by a team of pupils at Keswick School in the mid 1970s. The project investigated several aspects of stone circles and other ancient sites in Cumberland, with a large part of the focus being on the Castlerigg stone circle at Keswick. I was a member of the project team throughout, with my own speciality area being the analysis - and subsequent de-bunking - of "Ley-Lines".

Much of the computing work for the project was done using an HP 9830A desktop calculator that ran the BASIC programming language. This machine was owned by Cumberland County Council and was shared between various schools in the county, spending only a small part of each year at Keswick School.

The original incentive for the project was entry into a competition held by "Computer Weekly" and Digital Equipment Corporation. The prize for this was a DEC "Classic" computer. The final stage of the competition, including the announcement of the result, was held at the Waldorf Hotel in London. Unfortunately, Keswick School didn't actually win. We were told that we came a very close second. One memorable thing about the final was that the judges included Patrick Moore.

Subsequently, the team entered the BBC Television "Young Scientists Of The Year 1977" competition with the same project. The team won the heat and moved through to the final. Unfortunately, again, we didn't win. But it did mean that I appeared on national television!

Project Reports

The following documents were produced by the project team. The HTML versions contain corrections to the more obvious spelling and typographical errors. There are also links to PDFs of the scans of copies of the originals (warts and all!).

The report from December 1975

The report from April 1976

The report from January 1977

Other Documents

The project leader, Peter Stewart, wrote an article for the Keswick School magazine, "The Keswickian". This was after the original contest, but appears to have been done before we entered into "Young Scientists Of The Year".

Unfortunately, my stash of material did not contain copies of any of the original computer programs or raw data used on the project. I did, however, find a paper that I had subsequently written (using my Dad's old mechanical typewriter!) relating to further work on the Ley-Lines part of the project. This is particularly interesting, as it contains an amended version of the data (as gathered by my sister and me) for the various ancient sites that were analysed in the project. It also included a hand-written copy of some HP 9830A BASIC source code relating to the further Ley-Lines work document. If you look at the PDF of the scan of the original, you will see that it suggests that this was not the final version. With some tweaks, this can be made to run under various currently available versions of BASIC. For more on this, see Ley-Lines Re-Visited below.

Press Clippings

I kept a handful of press clippings about the project. These include one from the "Cumberland News" about the project, a couple of pages from the "Computer Weekly" write-up after the original competition and the "Radio Times" listings for the broadcasts of the "Young Scientists Of The Year 1977" programmes.

Diary Notes

These notes are based on extracts from my personal diary made at the time.

Original "Win A Computer" Project

"Young Scientists Of The Year 1977" Heat

"Young Scientists Of The Year 1977" Final

Certificates

Certificates were awarded for both the original "Win A Computer" competition and "Young Scientists Of The Year":

Broadcasts

The programmes were broadcast on BBC1 in March 1977:

The Heat was shown on Sunday March 6^th 1977.

The Final was shown on Sunday March 27^th 1977.

Later Events

Some time after the original competition, where we didn't win the Digital Equipment Corporation computer, Keswick School was contacted by Computer Weekly. The paper had received an enquiry from a "Bakery Firm", somewhere in the South of England, asking for ideas as to what to do with an old computer that they were replacing. Computer Weekly suggested that they could donate it to Keswick School, as we had done so well in the competition!

The result was that a large lorry delivered an ICT 1902 computer (ICT being a predecessor of ICL), plus peripherals, to Keswick School. This machine was probably less powerful than the prize computer - but was about an order of magnitude larger in physical size. It also required a three-phase mains power supply, which took a long time to have installed. Eventually the machine was powered up, with much clunking of mechanically damped delay-relays and flashing lights. That was as far as it ever went, though. No programs were ever loaded or run and we never actually knew whether it was really in full working condition at all.

Shortly after all of this, the school purchased its first Commodore PET, which proved to be a much more appropriate computer for the pupils (particularly me!) to learn with. The ICT equipment did not completely go to waste, however. For my "A"-level Computer Studies practical project, I built an interface to allow the PET to use one of the old ICT electro-mechanical teletype units as a printer. Finally, at about the time I left Keswick School in the early 1980s, it was decided that the redundant ICT 1902 should be scrapped. I managed to get permission to extract some rather useful and/or interesting components from it, before it was hauled away to the scrapyard. The high-current multi-output power supplies from the (huge) paper-tape punch and reader units were invaluable to me in my on-going electronics construction hobby. The magnetic Core Store from the CPU (which was 16 K-words of 25 bits, including one parity bit) amazed and intrigued various of my work colleagues for many years, before I donated it in 2010 to The National Museum of Computing at Bletchley Park.

Ley-Lines Re-Visited

UPDATE: March 2019

A rather glaring typographical error has come to light, which placed the stone circle at Shap on St Sunday Crag! The grid reference in the original typed document had a "3" at the start of the Eastings, which, with even the most trivial check, should clearly be a "5". The results below have been refreshed based on the corrected value. The only change was a slight reduction in the number of alignments produced by three of the algorithms, plus a single extra alignment being detected by one other algorithm.

A couple of minor errors in site names have also been corrected.

Also, the graphical links to the data and results at the bottom of this page now display them on dynamic maps once again. It was during the work to do this that the above typos were noticed.

UPDATE: August 2024

A minor bug was discovered relating to the conversion of the handwritten BASIC program into a more modern dialect. The "bwbasic" interpreter (version 2.20) was previously used, but this had the unexpected feature of always performing at least one iteration of a 'FOR' loop - even if the start value in the range of the loop was higher than the finish value. The original HP 9830A BASIC interpreter did not exhibit this behaviour. Post-processing of the output generated by 'bwbasic' attempted to catch occurrences of this situation, but it transpired that spurious alignments were still being counted. Changing to use the "yabasic" interpreter (version 2.90.3), which behaves as expected, highlighted the issue which has now been fixed. The results table below has been updated with the one value that needed to be correcting, which was a reduction from 235 to 234. It is also interesting to note that 'yabasic' is many times faster running the transliterated BASIC code than 'bwbasic' had been.

Various alignment detection algorithms have been used in the modern re-analysis. The data set for real sites was that containing the 100 entries from the "further work on the Ley-Lines" document.

You will notice that the allowed error values (i.e. permitted deviation from an exact straight line), used when detecting alignments, are quite small. This is because allowing larger values results in ridiculously vast numbers of alignments for both the real and random data.

Multiple control (random) data sets were generated and the various algorithms run against these. The results in the table below are for 100 sets of 100 (to match the number or real sites) random locations over the same basic area as the real data. The same 100 sets of sites were used for each algorithm.

For the random sites, the minimum, maximum and average number of alignments are given. My understanding of statistics is not up to calculating (or fully appreciating the meaning of!) the chi-squared parameter for these, so that is not included here.

The above results agree with the original work, in that there do not appear to be significantly more alignments in the real data than in random data. There does, however, appear to be an extra factor that was not fully considered in the original analysis. The data for the real sites is actually quite "clumpy", in that there are areas where there are multiple sites in close proximity. This can lead to spurious calculated alignments when there are two sites very near to each other and a third site many miles away. This can increase the occurrence of apparent alignments where, by manual examination, it is clear that there is no real line at all. The different algorithms seem to have different sensitivities to this. It should be possible to compensate for the effect, by either making the alignment detection algorithm more rigorous or by generating random data-sets that are equally as "clumpy" as the real data. A quick play with the latter approach confirmed that "clumpy" random data results in higher numbers of alignments.

So, to satisfy all the believers and conspiracy theorists out there, here is the full set of data for the real sites:

Site Map	Alignments
Map File (KML)	Map File (KML)
Data for Real Sites (tab separated)

You should remember, however, that a set of random data over the same area (which produces a realistic looking map of random sites) will also result in a similar number of alignments between sites in the randomly generated data!

Site Map	Alignments
Map File (KML)	Map File (KML)
Data for Random Sites (tab separated)