Categories
University - Masters

EVCO – Evolutionary Computation Coursework and Module Result – 80%

The Evolutionary Computation module I took in my first term of this year was assessed through one piece of coursework worth 100% of the module.

In this coursework we had to design an evolutionary algorithm to produce tanks for a tank battle game called Robocode. The algorithms we designed were judged on their ability to produce tanks which were robust against a diverse range of other tanks — in other words their ability to solve a multi-objective problem evolutionarily.

Many forms of evolutionary algorithm could have been used to develop these tanks, however because all tanks in Robocode are compiled Java classes I decided to use a Grammatical Evolution algorithm. As well as the standard GE algorithm I also produced a coevolutionary algorithm which employed grammatical evolution.

I found the real skill in evolutionary computation was working out which parameters to use in such an algorithm (e.g. What population size, how often should mutation of a gene take place on average, which breeding method should be used, how many codons of genes should there be), and developing a BNF grammar that wouldn’t result in too much recursion and therefore invalid tanks once you ran out of genes to generate code which got you out of the recursion, but was still useful.

The coursework was marked based on the report we produced explaining our decision making processes, analysing our algorithms and using statistical methods to evaluate our algorithms and tanks. By the time I was finished I had written 15 pages and had a further 25 pages of appendices.

Overall I found the coursework quite enjoyable, and the best tank I produced was quite amusing to watch as it flailed around the screen constantly rotating its turret and shooting at any enemy it could find.

I’m happy to say that I found out last week that I achieved a grade of 80% for the coursework, and therefore for the module overall. This keeps me on track for the Distinction I so badly want in the degree overall.

Danny

Categories
University - Masters

MODE Assessment 2 Coursework Result and Module Result

Today I received my grade for the second assessment of the Model-Driven Engineering module. In this open assessment we built on the work we had done in assessment 1 by developing a graphical editor for users of our Media Library model, developing two model-to-model (m2m) transformations, and a model-to-text HTML report transformation.

I’m happy to say that I received a mark of 83% for part two of this module, giving me an overall grade of 80% for MODE.

This grade alongside my 99% for CRTP means I’m currently in a very good position to get a distinction in my masters degree, which has always been the aim.

Due to some mitigating circumstances I am still working on my EVCO and COPR module assessments, and expect to have these finished by the end of this week. I will keep the blog updated with information about them (and hopefully some non-academic blog posts once I get some more free time)

Danny

Categories
University

Mobile Devices and Applications Coursework Result – 100%

On Monday 12th May our Mobile Devices and Applications coursework was due in at 9am and I had to demonstrate mine at 1:30pm, which was a very quick turn-around! At the demonstration I received my grade of 100%, which I was of course very happy with.

The coursework this year was to develop an Android Application called AMULET –  “An m-health (mobile health) tool for the valid self-assessment of alcohol-induced impairment” for a real-world research project in the University of Hull’s Social Sciences Department. In this post I will briefly outline the functions of the application.

User Management

 

All users of the service had to sign up to use the AMULET service, which keeps track of all their data. They could do this inside the application itself, and information could be synced with however many devices they decide to use. The interaction with the AMULET web service is via a RESTful JSON API. The user could also manage their account from within the application including deleting it and changing its password.

The Tasks

 

The main point of the application was for users to be able to self-test various attributes and skills whilst sober, as a calibration, and then compare this score with their current score at the time of intoxication. Users were asked to input details of their current drinking session before taking a test, and shown results afterward.

The Inspection Task measures the users speed of information intake. It does this by showing the user 8 sheep and changing one of them to be a wolf for a small period of time — 100ms — the wolf then changes back to being a sheep and the user has to select the correct sheep. If the user selects the correct sheep then they complete the same task again, this time with less time — it goes down in 10ms increments. When they eventually fail this is their recorded score. A sober person should manage a time around 60ms.

The Sequence Task measures the users ability to locate information. It does this by asking them to tap every number, in order, from highest to lowest. The users score is the number of seconds it takes for the user to complete the task.

Finally, the Pilot Task measures the users ability to split their attention between multiple objects. In this task the user has to drag around the white square and keep it away from the red enemy squares. The recorded score is the amount of time in seconds the user avoids the enemies.

In my implementation each task had 3 different difficulty settings; easy, medium and hard.

In the inspection task on easy mode the sheep would change to a wolf (which was both a different shape and colour), on medium mode the sheep would change to a purple sheep, (which was the same shape but a different colour) and on hard mode the sheep colour would change only slightly.

In the sequence task easy mode makes the user count to 9, medium mode makes the user count to 16 and hard mode makes the user count to 28.

In the pilot task the enemies move faster at the higher difficulty settings, and believe me it gets rather tough. Different calibration scores and results are stored for each setting, meaning users can’t calibrate on hard and then compare that score to an easy result when drunk — because that would be cheating!

 

Before each task the user was shown the task brief, which allowed them to access instructions for the particular task they were about to start. At the end they were shown the task finished screen, which compared their results to a calibration or prompted them to make one. At any time the user could go to the home screen and tap “task history” to see their results from the past.

Drink Diary & Unit Calculator

 

As well as keeping track of the users abilities at times of sobriety and intoxication the application also kept track of the users drinking habits through a “drink diary”. This diary allowed users to enter information about a particular brand of drink including the brand name, alcoholic % and portion size, and then store how many they had drank along with a timestamp.

A unit calculator was also included for the users convince. The user could input the number of drinks they had consumed, the class of drink (e.g. Red Wine, White Wine, Average Strength Beer), and the portion size and be given a reasonable estimate of the number of units consumed. This functionality was also called when the user input drinks for the drink diary, to make data entry easier.

RESTful Server Interaction

One of the most interesting parts of the coursework was ensuring we stuck to the standard required by our lecturers server to send and receive data. This server allowed for research to take place on the information submitted by users, backed the data up and allowed users to carry information from one device to another.

All drink diary entries and task results were synced.

User Interface

Though the design of the application was very “windows phone-eseque” it was somewhat unique and supported many of the android features users have become familiar with; such as landscape and portrait support, different screen resolution support (from 3 inch phones to 12″ tablets and above) and notifications for long running processes such as data upload.

Thoughts on Developing for Android

I thought this coursework was a really nice way to pick up the programming language Java which, until now, I hadn’t needed to use. It’s similar to C# in a lot of ways with a few of its own idiosyncrasies, but a lot of the industry (and The University of York) use it extensively, so its a good thing to have learnt.

It was also interesting to have developed an application which worked across mobile phones, from small 3 inch screen devices, to much larger 12 inch tablets. This made me really think about the best way to develop the user interface, and I think I found a good compromise — it was certainly at least usable on all of these devices.

The main issue a lot of people had, including myself, wasn’t with Android itself, or indeed Java but rather the Eclipse IDE which most android developers use when writing applications. We all know that Visual Studio is in a class of its own, but it was a bit of a culture shock to change to an IDE that didn’t support debugging in quite the same way for example. Having said this I think this ability to switch between development environments is a good skill to have picked up. The other issue was just how slow the default andoird emulator is on a non-intel PC — but this can be solved through the use of Genymotion.

I will be getting my results for the module as a whole, along with my final university grade itself on the 2nd of July. I will of course update the blog then!

Danny

 

Categories
University

Languages and Their Compilers ACW Result – 80%

You may have noticed that my blog hasn’t been updated nearly as much this semester as it has been in those last year and the year before. One of the reasons for this has been the Languages and Compilers assessed coursework, which has taken up quite a bit of time.

The aim of the coursework was to build a compiler, a bit of software which converts from a “high level” human readable language to a “low level” language a computer can execute, for a completely made up language called SPL – which stands for Simple Programming Language.

Formalizing the Grammar of the Language

SPL If Then Else Syntax Diagram
SPL If Then Else Syntax Diagram

The first thing we had to do was formally specify the grammar of the language — the grammar of a language specifies what is, and isn’t, valid in said language — we did this by reading some syntax diagrams provided to us by our lecturer, such as the one above, and then writing out Backus-Naur form notation to describe it. The image above in Backus-Naur form is notated as:

<if_statement> ::= IF <conditional> THEN <statement_list> ENDIF |
                   IF <conditional> THEN <statement_list> ELSE <statement_list> ENDIF

Items in <brackets> are other rules, so there would be another rule which describes the syntax of “conditional” and “statement list”. Using multiple rules together allows us to build up a complete syntax for the language.

The Tokenizer

Once we had developed a complete BNF grammar for the language we could move on to building the compiler itself, this was especially interesting for me because my final year project uses a lot of the same concepts.

The first stage of building the compiler was building a tokenizer. A tokenizer, as I’ve spoken about before, is a system which recognizes certain keywords, or patterns, and gives them a label which can then be used later on in the compilation. For example the C# code:

public static void main()
{
     int a = 10 / 2;
}

Consists of the following tokens:

  • Public Keyword
  • Static Keyword
  • Void Keywork
  • Identifier Pattern main
  • Open Bracket (sometimes referred to as BRA)
  • Close Bracket (sometimes referred to as KET)
  • Open Curly Bracket
  • int keyword
  • Identifier Pattern a
  • Symbol =
  • Integer Pattern
  • Symbol /
  • Integer Pattern
  • Semi Colon
  • Close Curly Backet

We used an open source version of the Unix program lex, called flex, to build our tokenizer (in my FYP I’m building a tokenizer from scratch). In our flex file we recognized tokens using regular expressions. Matching something like a keyword is rather simple, you just look for that literal string, however looking for an integer is a tad more interesting. Below you can see a few examples:

/* Primitives */
digit                  [0-9]
number                 {digit}+
/* End: Primitives*/

//Public keyword
public                 TOKEN(public);

//Integers (e.g. whole numbers)
{number}               TOKEN(integer);

//Reals (e.g. Numbers with decimal point)
{number}.{number}      TOKEN(float);

On the left hand side of the token recognition is the pattern that has to be matched. For the word public it is the literal string public, for integers it is a {number} and for a real it is a {number} a full stop and then another {number}. {number} has been declared previously to be 1 or more digits, and a digit has been declared before that to be any number between 0 and 9.

The tokenizer takes a .spl file, which contains spl code written by a programmer, and spits out an array of tokens which we can then use in the next stage.

The Syntax Parser

Once we’ve finished building our tokenizer we could then go on to building a syntax parser. The job of the syntax parser is to ensure that the array of tokens provided by the tokenizer are in an order which makes sense. To produce the syntax parser we used a free program called Bison, which is based on the Unix program YACC.

This is where we go back to the Backus-Naur Form we made previously. Using that, with some alteration, we produced a .y file which, once passed through Bison, could identify correct grammars in the list of tokens passed to it — and tell the programmer there was an issue with their code if anything was detected as incorrect.

Correct grammars were added to a parse tree, in hierarchical order. As we saw earlier, an IF statement contains a conditional, so that became one of the branch nodes of the tree which represented an IF statement.

At this point we could print out the parse tree, my software could print both to the console and to an interactive animated viewer. Below you can see both:

a.spl Parse Tree as shown in the Command Prompt
a.spl Parse Tree as shown in the Command Prompt
a.spl Parse Tree as Interactive Animated Viewer (Click to enlarge)
a.spl Parse Tree as Interactive Animated Viewer (Click to enlarge)

Code Generation

Once we have determined that the input file from the programer is syntactically correct we need to generate executable code. For this coursework instead of generating an executable directly we generated ANSI C code, and passed that to the GNU C Compiler. We did this for a few reasons:

  • Generating machine code directly wouldn’t be as portable
  • Generating machine code would take a lot longer!
  • Learning ANSI C was really useful, as its the number 1 most used programming language in the world

Generating code was a simple case of walking the parse tree and generating code for each node… for example, if you reach an IF THEN ELSE node you could simply output the following:

if(/*Generate code for the CONDITIONAL here*/)
{
    /*Generate code for the IF statement list here*/
}
else
{
    /*Generate code for the ELSE statement list here*/
}

Ensuring you generate code for the conditional and statement lists in the correct sequence. Certain types of grammar throw up a few problems, such as FOR LOOPS (which way should the iteration go?) but the concept of code generation from a tree in itself is simple.

Optimization

The final part of the coursework was to add some optimization to the compiler. Some optimizations you could implement included:

  • Don’t compile the code if it doesn’t contain and input or output (if a program has no input or output, it looks the same as having no program at all!)
  • If a programmer increments a variable by 1 generate the ++ operator rather than +1
  • Constant Folding: If a variable is assigned to the outcome of a constant set of values. e.g.  a = 4/2, then generate a = 2 because this will always be the case

I chose to do both the incrementation optimization and the no input or output optimizations. I was going to add constant folding too, but didn’t think I had enough time.

Conclusion

Today I got my grade for the coursework and achieved 80%, which is a strong first class. I’m really happy with this. 🙂

I would recommend that any second year thinking about what modules he or she should take next year seriously consider Languages and Compilers, it is by far the best module I have taken. It combines knowledge from all your previous modules and really cements that information in your head.

I’d like to thank both Dr. Martin Walker and Eur Ing Brian Tompsett for setting such an interesting coursework, and providing me with the help that they did along the way.

If I’m allowed I might upload my compiler and some documentation for SPL for people to have a play with it.

Danny

Categories
University

Electronics and Interfacing Exam, Coursework and Module Grade

Robots. Infrared. Kill Switch.

3 of the more exciting terms in Computer Science, it has to be said — and also three of the integral parts of the Electronics and Interfacing module, which I haven’t spoken about much this year. This is due in part to the fact that I spent a lot more time on the other modules I took this year, and partly due to the fact that the coursework and exam for the module were both at the very end of the year.

Infact my final exam for the module was only yesterday, my last for the whole year, meaning I’m now at the end of my second year of university 🙂 Expect a second year round-up blog post soon.

Coursework

The coursework we were given for the module was to build, and write the software for, two devices in a team of two. One device, a Robot, would be controlled by another device, a Controller via an Infrared link using a command and control protocol we came up with as a pair. I worked on producing the Controller whilst my partner worked on producing the Robot itself.

Below you can see the LCD Screen I programmed to show Bitmap images (don’t think anyone else did this) which could be touched to control the devices trajectory or to activate the Killswitch — which stopped the robot dead in its tracks. Next to that you can see the potentiometer which could be used to alter the speed of the robot, and finally alongside this you can see a physical button which also activated the Killswitch, for those times when the responsiveness of a touch screen wasn’t enough and you wanted to smack something! 😛

All of these items when used together were used to control Eric, our robot, whom you can see below.

Eric The .NET Micro Framework Robot
Eric The .NET Micro Framework Robot

I received a grade of 71.25% for the coursework.

Exam

The exam, which I took yesterday, focused more on the electronics portion of the module, and now the terms Ohm, Amp, Volt, Potential Difference, AC, DC, Current and Resistor and burnt into my memory forever. In addition to the questions about electronics there were a few questions on the .NET Micro Framework, Threading and other embedded programming specific tools.

As it was an electronic exam I have already received my grade and am quite happy to say I achieved 84%, though I was hoping to do a little better.

Module

This means overall I achieved a grade of 77.6% for the module, which is my lowest grade of the year and therefore a little disappointing, but still a reasonably high first so I’m content.

Danny.

Categories
University

Advanced Programming Coursework Result – 100%

Today I got back the result for my Advanced Programming Coursework.

The coursework was called “Data Structure Analysis”, and the aim was to design and develop data structures in C++, a Linked List and a C style array, and then compare them using a hardware timer to see how they compared in read from file, write to file, search and sort operations.

Once we had created both structures, making sure we kept within a coding style tested using the Parasoft Code Reviewer software and ensuring we didn’t have any memory leaks by properly implementing the gang of three, we then wrote up a 2000 word report detailing how our various algorithms worked.

I’m really happy and proud to announce I achieved a grade of 100% for my work! :D. This means that, subject to the normal exam board review, I have achieved a grade of 88.24% for the module overall! Good times.

Danny

Categories
University

Networking and Web Technology Coursework Results – 80% and 100%

Over the past few weeks I’ve been working hard on several courseworks and revising for several exams. One of the modules I’ve enjoyed the most has been Networking and Web Technologies.

The coursework was split into two stages. The first of which was simply entitled Networking — in this section we produces a command line client which could interact with both our lecturers server as well as one we later made ourselves. The client could send information to the server about the whereabouts of a staff member using their username and a string of text explaining their location. Simple stuff, but very satisfying to implement from something as simple as a socket connection. The server we made, which ran on multiple threads to allow over 10,000 people to connect at once, then collected this data, stored it in an XML file and could send the data to any client that asked for it. All good stuff, as Rob Miles would say.

Networking Coursework - Client, Server, Sever Log and Storage XML File
Networking Coursework – Client, Server, Sever Log and Storage XML File

I received a grade of 80% for my implementation of the console based applications, which I was happy with.

Today I demonstrated part two of the coursework, entitled Web Technologies to my lecturer. In this second part we had to make an application, either in PHP or ASP.NET which handled all of the same things the command line server did in part one, but better. I chose to do it in PHP as I have years of experience with the language.

The final result was a website with the following features

  • A Microsoft SQL Backend Database
  • The ability to add, delete and edit entries from a form
  • Validation of all inputs on server side
  • Parameterized queries to stop SQL Injection attacks
  • A responsive design so the site looks different, and better suited, on tablets and mobile phones
  • An API which any client which can send HTTP formatted POST or GET requests can use to add edit or query a user’s location

In the end I was awarded a grade of 100% for part 2! I couldn’t be more over the moon.

I have an exam on Tuesday for networking, which will be the final of the 3 parts. Once I know my grade for that and the exam overall I will of course update the blog 🙂

Danny.

Categories
Programming University

2D Graphics Solar System Simulation Coursework Result

I’ve written a few posts now about my Solar System Simulation — also known as a JavaScript Orrey — Coursework for 2D Graphics. It was the coursework I’ve been most enthusiastic about since I’ve got to university so I was anxious to get my result.

I’m very pleased to say I got a grade of 86%. This is a high first class.

Because I’m pretty confident I did quite well in the other half of the module, User Interface Design, I think I should have a high first class for the Module as a whole, which I’m very happy about! Of course I will update this blog when I get my module grades back on the 18th of February.

The lecturer who set this coursework, Dr. David Parker, provided me with some really useful feedback, saying:

This was a well featured piece of work, I also love what you did turning it into an app (though that isn’t reflected above).

Some of the code is a little over complicated and you could put some thought towards how to make it simpler. This also has maintainability consequences.

Taking that into account I intend to spend much more of my programming time working on refactoring my code to make it easier to understand and maintain.

I was also very pleased that Dr Parker described my use of SVN, a subversion system used to keep track of changes to software source code over time, as the best he had seen. 🙂

Danny

Categories
University

System Analysis, Design and Process Coursework Grade

A few weeks ago I wrote about our group project for the Systems Analysis, Design and Process Module. I was a bit worried at the time about how it would work out, because I’m always a bit nervous about group projects, however I’m pleased to report it all worked out well in the end. 🙂

My team achieved a baseline grade of 35 out of 40, which is 87.5%. This doesn’t necessarily mean that I have that grade, but my personal grade won’t be far off this mark!

I’m really pleased, if I get a personal mark of 87.5% that will mean I have a grade of 80% overall for the module, a high first class. 🙂

Danny