MGF: Cooling Schedule Headache

This week I have been attempting to finish the Technical Report for the work on MGF before a meeting with supervisors next week. I've collected a lot of results, for a "good" selection of graphs following Hu's example, however, one common problem I've been having is the cooling schedule.

Over the past few weeks I've asked (and my supervisors have asked) myself two questions - how will the cooling schedule work for dynamic graphs (which I covered as a post previously), and how does the number of iterations required to find a good layout using MGF, compare to the OT. The latter is especially important as, in theory, the MGF will take fewer iterations, and proving that would be good for both Technical Report and Thesis.

So, I  set up and run both algorithms, using the "default" parameters for a selection of graphs. For both algorithms, given the same parameters, the number of iterations for a graph are the same. 

		MGF		OT
	levels	iter g0	iter all	iter g0	iter all
55grid	12	61	526	61	526
data	15	61	619	61	619
4elt	17	69	769	69	769
add32	175	64	7962
finan512	36	77	1775	77	1775
sierpinski10	20	77	1030	77	1030

The table above gives 6 graphs (dime20 would be included but testing that is far from nice), the number of levels generated by the multilevel algorithm, and the number of iterations for generating layout for the original graph (g0), and the number of iterations overall.

The number of iterations comes down to the cooling schedule and/or calculation of forces. In my implementation, and as described by others such as Veldhuizen, and Fruchterman and Reingold, vertices find a good position but remain moving backwards and forwards (in a zigzagging pattern) as the forces continue to push and pull the vertices into better positions (even though it may be in the best position). The cooling schedule fixes this by limiting the movement at later stages, and forces the algorithm to eventually stop. My understanding of this was that the layout should converge naturally, before the cooling schedule forces a stop.

In practice, the cooling schedule only stops when movement is limited to such extent that the layout is deemed converged - thus, forcing both MGF and OT algorithms to be iterated the same number of times. So  if the cooling schedule is just a means of calculating an ideal number of iterations, why is it reported that the number of iterations can change for the same graph? The real answer is I am unsure. At a guess, I would say the calculation of K is the difference, and the number of controlled parameters in my application. 

My first thought about this is: what have I implemented incorrectly. Hu's work would support this; implementing the adaptive cooling schedule, the behavior did not match that described by Hu, instead, followed the behavior I described above. So, my plan? I intend to replace my calculation of K with that used by Walshaw and check the iterations again. If the same, it looks like there's a problem in need of fixing.

Ah well, practice makes perfect. Let's hope my next rant isn't regarding another piece of work from 2 years ago. Until next time, bye.

Multimatching and "Trailing" Results

After my last post, I have run some tests using the four matching techniques and collected the results (though the real test was to see if the trailing worked as expected). Before this though, I had a meeting with my supervisors (post-viva) and discussed the results of the viva; to summarize  all appears well (unless there is some secret panic i'm unaware of).

Some other topics of discussion:

• complete the Technical Report for the work on Multilevel Global Force Approximation and Multimatching
• Check how much the levels of the multilevel scheme change when layout is pushed back to coarser graphs when using MGF (used to keep the approximation structure up to date with new positions of vertices)
• Output the graphs (all or some of the coarser graphs) into one display area
• Output layout to xyz files so they can be visualised through other applications
• How does the "trailing" actually help?

Most I have yet to complete.

Moving on to what I have completed this week (and back to my results of the multimatching). For the Dynamic Matching work - I have had to alter the code so it no longer uses Arrays, and instead, use ArrayLists. This now ensures I can alter the graph when necessary (required for dynamic graphs) - other data structures are available, such as HashMaps or other ADTs, however, most of the algorithm used here require looping over the data - for which ArrayLists are considered better (Google it for a more in depth discussion). 

I have begun working on an "Operations Manager" which will house the methods for altering the graph (removing, adding or editing vertices, edges and hopefully subgraphs). More work is required on other aspects of the application before it can be considered a dynamic graph drawing system.

Moving back to the multimatching; for my most recent results, there is only a very weak correlation between the degree of vertices and the matching method used - not nearly enough to be able to identify the best matching number before coarsening (further analysis may improve upon this but for now it is not a consideration).

Now for some good news, the Trailing matching mechanism. So far, results show a noticeable decrease in the runtime required to generate layouts for the graph - so far, an average of about 25% reduction but have seen up to and over 50% in add20 (from 13s using standard edge contraction, to 6seconds using trailing with edge contraction - with comparable layouts). Further results will be given when I have finished analyzing the data and fixed a few irregularities. Unfortunately, these results are still not as  good as the Octree (runtime and edge crossings count).

I have 101 things to do, so for now that is all. I will update again next week. Sayonara.

Multimatching and Clustering Techniques

In a bid to complete some older work before moving onto Dynamic graph drawing problems, I have focused  on the multimatching once again. As a form of clustering, there is much research already out there which identifies the most efficient methods, the most useful for graph preservation, most useful in given scenarios for each graph type. Unfortunately, there is far too much information to read through for such a small task in my research.

In regard to this, I had implemented a multimatching form of clustering which when given a matching number, m, the matching/coarsening will group m vertices to form a new vertex in a coarser representation of the graph (as opposed to edge contraction or identifying a MIVS). To recap, I was identifying a way in which to reduce the time required to draw sparse star-type graphs, and to achieve an approximation tree similar to that of the Octree (primarily the star graph thing though).

Having revisited the multimatching results; there is some relation between the matching number and the average degree of vertices within the graph, albeit, making only a small difference to run-time (a few seconds under the 30-40 second run-time for add32). Nowhere near the reduction I wanted.

Following these "bad" results, I investigated other approaches for clustering, with the aim of reducing the run-time further (and hopefully improve drawing quality as well). With multimatching being the first, the second was using brute clustering - where all adjacent vertices, if not matched, are coarsened to form super nodes  regardless of the degree. This is theoretically bad, as it will generate several heavy nodes, and many smaller nodes (composed of the left over vertices). The approach focuses mostly on star type graphs as opposed to sparse graphs.

The third is oddly named trail finders. Analyzing the degree of vertices within graphs which cause the MGF approximation scheme issue, shows that the average degree is 1 or 2 vertices (with very few having 3 or more). Therefore, it is assumed (and backed by analysis of drawings and chaco files) that trails of vertices exist, where one vertex is connected to only one or two others to form strings of vertices. Therefore, multimatching and brute clustering will make little difference to standard edge contraction ( when edge contraction contracts the graph to a star graph, it also becomes obselete). Finding these trails and coarsening them before other matching techniques, means [in theory], the algorithm finds a better matching.

Currently, I am awaiting results which test each of these in order to identify the best approach for the graphs add20 and add32 (with the aim of identifying similar graphs through analysis of the their degree when being read from the chaco file). It should be noted, the adaptive matching described in Hu's work (which changes from edge contraction to MIVS when edge contraction fails) has not be implemented or tested due to difficulty integrating it into the MGF approximation scheme. 

Initial drawings show an improvement in quality when using trail findings, but runtime has not been compared yet. As this is a relatively small topic in terms of thesis, further research is unlikely, and therefore the best of those matching techniques given above will be used (unless otherwise specified by my supervisors).

Finally a PhD Student!

Good news, I've passed the MPhil/PhD transfer viva.

Time to get a move on I think!

Slight Update

Unfortunately there is little to update upon over the past few weeks. Since approval of my MPhil to PhD transfer (only a year late...), I have been generating a short presentation to identify my current position, and any previous and future works for discussion during the viva. I have also been adding to my draft thesis with the hope it shows my examiners that I will be able to complete the PhD within the 3 year limit (only 11months to go!) and that I have a clear plan of what I intend to do in the future.

Much of the presentation is now complete and the thesis is starting to take shape, but there is still a lot of work to be done before it can be considered a complete first draft - but I'm slowly getting there...

As for programming and implementation, little has been made to progress through the dynamic graph drawing stuff, and little will be done until after this viva. When I do return however, it is planned for me to move straight to the dynamic matching work so we can tackle the pesky operations and their effect on the multilevel stuff. Who knows, maybe another paper out of it? Just another idea to add to my growing list of abstracts.

I probably wont update again until the viva is completed, so until next time, enjoy yourself!

What is brute force... What is normal...

Welcome back to another episode of me complaining.

I have failed at implementing a brute force multilevel dynamic graph drawing algorithm. Outputting the changes in coordinates as changes occur is easy enough, but cascading a layout through the coarser levels is not, all due to the number of movements per level. For example, a coarse graph of 2 vertices has 2 movements, but its finer graph of 16 vertices would have 16 movements, which when used to update the coarser graph, causes erratic behavior (shrinking and expanding the graph erratically with no layout).

In this instance, I had expected the weights of vertices, and the difference of k between levels (sqrt(4/7) as given by Walshaw), would have prevented this, apparently I am wrong (or there is a bug I haven't found yet). This type of behavior has been covered and tackled by Veldhuizen through use of damping and time dilation mechanisms, suggesting Veldhuizens approach is actually brute force, adapted to use the Barnes Hut octree approximation and "dynamics" between levels. This is a bad assumption to make though and I certainly don't want to reduce the value of his contribution. 

In any case, this behavior helps me identify a bare bones algorithm for multilevel dynamic graph drawing which identifies the mechanisms (and theory) which are required by default for any implementation. In order to continue, I have instead opted to implement Veldhuizens algorithm first, then develop my own bare bones algorithm (and after, improve upon it). For this though, I have requested aid from my supervisors so I can fully understand the algorithm (there's a lot of mathsy stuff which confuses me a little). 

In the mean time, I am checking over and editing my literature review to put it into some readable format (as opposed to notes pushed together as it is currently). With less than a year, I better get a move on - as the song goes -  "our time is ruuuuuuuunning ooooouuuuut".

Cooling Schedule

Almost all of the literature my work in static graph drawing is based off, uses a cooling schedule to reduce the movement of vertices as a layout is generated. However, there has been little discussion of a cooling schedule in Dynamic Graph Drawing.

A quick recap: the cooling schedule steadily reduces the movement of vertices when given a layout from force directed placement algorithms, in effect, cooling the graph into a good layout. Without such algorithm, vertices would not be cooled, and would remain as a "liquid" - with the ability to move large distances around the placements.

Such techniques are widely used in force directed placement graph drawing approaches for static graphs, but not in dynamic graph drawing. My addition to my literature review has shown that many algorithms in use do not require such techniques as they use hierarchical and/or orthogonal layout techniques, or deal with such small graphs that a cooling schedule is not required (for example, using Eades heuristic would not require a cooling schedule due to the method used to move vertices).

There are some dynamic algorithms which do use cooling schedules however; Lin, Lee and Yen extend the Simulated Annealing FDP approach described by Davidson and Harel (birthplace of cooling schedules), to dynamic graphs, and maintain the same cooling schedule. More importantly, Veldhuizen's work also describes a method of cooling the layout through "damping", shown to be effective at controlling the erratic changes in vertex positions during visualisation.

It is obvious that any FDP orientated approach should use a cooling method, but there has been little investigation as to the loss in efficiency that comes from using one designed for static graphs. As dynamic graphs are ever changing, it would make sense to use this time to improve upon layouts instead of generating a layout once and calling it a day.

Experiments have shown that by resetting the cooling schedule, a graph will build upon the previous layout and improve it. Please see the videos below (YouTube links), which show that resetting the cooling schedule can further improve layout. The last video shows a graph drawing with no cooling schedule, resulting in jerky vertex movements.

Drawing a 20x20 vertex graph, resetting the cooling schedule: http://www.youtube.com/watch?v=FiD1uFQR49U

Drawing a 7x7x7 3D grid, resetting the cooling schedule: http://www.youtube.com/watch?v=VkADKI_FJsk

Drawing the same 7x7x7 3D Grid without a cooling schedule: http://www.youtube.com/watch?v=P5LYL7eG2uk

The effect this will have on larger graphs using the multilevel scheme is unknown, but it is expect to have more of an effect on local structure. Although not a significant point in terms of graph drawing, it is an interesting topic which may have implications at a later date.

Time keeps on ticking

I fear the universe may have a leak as I am becoming more aware of the age old saying that theres not enough time in the day. It's finally starting to hit me that 2 years are over and I have just over 11 months left; so its time to get rocking I guess.

I am still on the literature side of things this week (and for the past few weeks - hence the lack of updates), making my way in to Dynamic Graph Data Structures, a lengthy subject on its own. Having found what to aim for in drawings (aesthetics wise), decided on what drawing algorithm to use (FDP - Spring Embedder) and what viewing technique will be best (Animation), I am now looking at how previous authors control the flow of data and the complexity of operations associated with dynamic graphs.

Although I have a lot more to read, there is no definitive system for dealing with multilevel graphs - specifically updating the locations of vertices in coarser representations. In our static graph drawing work, we used a brute force post-order search of the approximation tree to update vertex positions, using the mean of its children - computationally expensive but also used in other work such as the Octree. This requires FDP be applied to all levels of the graph before the updates can be made - something which would be extremely inefficient if applied to dynamic graphs).

Further reading will hopefully identify a more useful method, or at least give me some ideas how to overcome this (NB: Veldhuizens work isn't clear on this subject but I've yet to read it in this context). That's all for this week folks, I will update again shortly - hopefully getting back into the swing of updating this. See you next time.

Dynamic Literature: Mental Map

Over the past week I've been working on writing up much of the literature for my Thesis draft as part of my RDA2 form (MPhil to PhD transfer). Now that the deadline has passed I can give my blog an update.

NB: Blogspot needs a feature which allows users to put all blogs into a single editable and printable file. Just a thought for any dev's which may be reading.

Aesthetics of a dynamic graph are very hard to define, and even measure due to constant changes in the structure. Therefore, the concept of a Mental Map has been created, relating to the readers familiarity with the layout (and the graph). Much of the literature is infatuated with the Mental Map, and it is widely believed that any changes to it will affect the readers understanding of the graph, and it is of the upmost importance to avoid any big changes which could confuse the user and remove their mental map. In essence, it has become a measured aesthetic of dynamic graphs across many publications.

Unfortunately, measuring the Mental Map is still difficult, and many authors suggest different ways of doing so - measuring movement over time, edge crossings over time and others, most being computationally expensive and not ideal for my work.

Although my work will inevitable cater to the Mental Map concept, the works of Purchase (whom has previously worked with measuring and identifying the most important aesthetics of static graphs) has suggested (with strong proof) that attempting to attain good Mental Map stability is not as useful as first thought. There are comparisons against different algorithms, different visualisation styles with different parameters being measured, and all results point to a weak improvement to readabilitywhen achieveing this mental map (usually by restricting movement).

Unfortunately, there is almost no literature for Mental Maps of huge graphs, only smaller graphs with less than a 1000 vertices (most support fewer than 100). Admittedly there may be research I have not yet found, but it is unlikely I will find any as Purchase's publications foil the concept, and dynamic graph drawing for huge graphs is an almost untouched area (par a few individuals - Veldhuizen and Frishman, possibly Hu but I have yet to check).

So what to do? Identifying the Mental Map is perhaps the most difficult part. With larger graphs, I treat drawings as rigid objects which can be rotated and translated, suggesting my Mental Map looks at the global structure. Some would suggest the Mental Map only applies to smaller localised structures where users would like to view connectivity between vertices. For uhge graphs, I offer two approaches - for global structure, identify the mental map of a coarser interpretation of a graph, and for local structure, use only sections/partitions of the graph which can be identified through the MGF/edge contraction tree.

I have yet to finish reading more of the literature - much of my reading has focused on smaller graph techniques and so I need to investigate techniques for larger graphs (if any can be found). Hopefully I can find an alternate approach to compare against (or even better, find my suggestions aready implemented). I will update if I find anything, have a good weekend!

Wishful Thinking

It seems once again I got ahead of myself. The improved testing suite, Osmium, has been hit by a significant flaw. The results yielded for the Octree implementation greatly differs from what is expected, so much so that a fair comparison to the MGF approximation cannot be achieved.

To summarise the observations: layouts using the Octree approximation are achieved approximately 8x quicker than our own MGF approximation, however (following the rules of the universe), the quality of those drawings is very poor (some would suggest that there is no layout, instead materialising as a messy ball of vertices and edges). The cause is yet to be confirmed, but the behaviour was not in previous versions. Unfortunately, rolling back to such versions provides an unfair comparison of algorithms, as many of the underlying algorithms have been replaced to better suit the clustering.

Although this is an issue I would prefer to resolve, time is not permitting and so I will continue with an analysis of the MGF results for our Technical Report (comparison against other work was carried out before the introduction of clustering, so its not too big of an issue to omit such comparison at this stage - although it would be preferable).

As for other work, I have continued to make small contributions to my very very draft thesis outline (although at the moment its more accurate to say "contributions to my desktop") and have been plotting out ideas for the dynamic/online graph drawing. I have also finished my secondary collection of literature (specific to our next piece of work), so am preparing to make my way through them to find what I can/cant/shouldn't use and look for any ideas for improvements.

Not much else to say for now but the deadline for the RDA2 form is looming and the amount of work I have left is starting to look more and morel like a mountain - guess that's what I get for being lazy, heh.

Refreshment

Well, its been an eventful few days and unfortunately, this leads to a lengthy blog post. But not to worry, a TL:DR has been included at the bottom! So feel free to skip the bulky part if limited for time, or are just lazy, like me, as I expect to be when re-reading this in my future. By the way, hello Carl...

I have made good progress on most writing related items, and am currently re-reading and editing (if and where required) my attempts at an RDA2 report, technical report and to some extent, thesis material. It should be noted that the RDA2 report is short (currently only a page) and non-technical, involving no knowledge of my work - its more of a research-only peice which mentions what ive done, i.e. literature survey processes etc.

The technical report, I was still unsure about. All (most) items regarding the Multilevel Global Forces work, without clustering, has been written and undergoing the same checks. The results for the clustering though, they were a nuisance. Not only did they not match my expected results, for example, a clustering of 2 vertices should have given me drawings of similar quality and similar runtime to those in standard edge contraction - but they did not (yet the octree results did return expected results).

After some lengthy work on the testing suite, I finally found the answer to my doubts. The bad results had been due to conflicting movements. For context, when a level has been given a layout in the MGF algorithm, a post-order search of the tree is carried out to update the coarser graphs with updated coordinates of the finer graphs, and so, keeping the approximation tree up to date. This is similar to a process required to keep the octree up to date, but is not required in the multilevel paradigm alone. In my haste to progress with the clustering, I had rewritten some code without thinking twice about it.

Well instead of updating the coordinates in the tree, I was actually adding them to the already existing coordinates previously computed. This generated awful layouts, and when coupled with a different but similar issues, increased runtime too. Having fixed this, layouts now look much better and re-testing of the clustering has begun (another lengthy process but worth the more accurate results).

In addition to this fix and the reports, I begun thinking towards the MPhil to PhD viva and what might be expected of me. It is then I made a horrible realisation: people might want to see this Testing Suite ive been bragging about. Therefore, I have spent the majority of my time over the past few days, cleaning the test suite and ensuring everything is in working order. In this clean up, I have resolved so many undiscussed bugs it is not true, and have even cleared up some of the theory behind the work (values of K, repulsive forces and viewing sizes etc). This new suite lead me to the discovery of my clustering issue, and will now be a prototype system to a finished product, should my work go that far.

Now if anyone is thinking like me, they'll be screaming "you have bigger things to worry about - dynamics for instance". My argument to this is that if I hadn't done it now, I might not have found time towards the end, or even worse, I would have forgotten everything about the code (admittedly an issue I had now) and may never have fixed my bug with clustering.

TLDR:

• More progress reading and editing the various documents for RDA2 (MPhil to PhD transfer)
• Fixed bug causing the horrors that were my results for clustering
• Running fresh tests for clustering, ETA 2 days, then finally an end to the MGF business
• Cleaned and re-programmed much of the Testing Suite, now codenamed Osmium [Alpha] - formerly WeaponX (more of a personal nickname for it... if you can think of anything better, let me know!)
• All algorithms are in a "default" mode, allowing for any graphs to be input in Chaco format, and requiring no (or little) changes to the settings/code

For now, that's all, I will keep you posted on my progress with the clustering results and anything else that might warrant some attention. Good Night!

Deep into the Work Load

Probably time for another update.

I am making my way through the work load I discussed in my last post, albeit slowed by my discovery of yet another MMO (this time it's S4League). I have made some good progress with the Technical Report and am currently awaiting some further results to confirm some analysis (and remove doubt). It should be noted, making things in excel uniform and pretty for a report is the most time consuming and tedious task I have known this week.

Further to the technical report, I have been filling out my RDA2 form (though there's not much to fill out), I have been checking over my literature review/survey in preparation of finalising it for inclusion in my Thesis skeleton, and as a final push, begun implementation of the Veldhuizen dynamic graph drawing technique.

There is still much to do, but I am slowly coming closer to reaching my aim for work to be completed by the next Research Committee Meeting (which I have now been told requires all forms be submitted by September 9th).

I will hopefully update again later this week or early next. Aim for then? completion of the Technical Report if I'm lucky... for now, good night!

Olympic Work Load!

So goes another week of "work", which is unfortunately slower than anticipated. As mentioned previously, I am writing my technical report, which other than explanation of results, is going well. I have cut down much of my unnecessary literature (though most of it can be used in the Literature Survey/Review in my thesis) but am struggling to discuss the results of my experimentation.

I am aware its "good" to question my own work, but I'm starting to think there is such a thing as "too much questioning". I find myself questioning my own methodologies and as consequence, I am becoming unsure of my results. Unfortunately my doubts have to be suspended due to the lack of time I can spend on this (arguably I've wasted too much time already).

Awareness of your own work is damn annoying.

I will still aim for the end of the week, but once again my work load is increasing (oddly by my own expectations) - with the next Research Commitee Meeting two months away, I am expecting them to request any RDA forms before the 9th September. By this time, I would ideally like my Technical Report complete (an end to my work with the MGF algorithm for static graphs) and an implementation of Veldhuizens dynamic work. Additionally, I suspect they would also like to see evidence of me having started my thesis.

We shall see, still a few weeks away but time is starting to slip by ever more quickly. As always though, I do like a challenge!

P.S. GO TEAM GB!

Update 17.54.1221

It's amazing how accurate "out of sight, out of mind" can be, so I better update while I remember.


Over the past week I have been working on my technical report and analysing/collecting more results to affirms some of my reasoning. Unfortunately an electrical fire caused the entire Queen Mary building to be evacuated with all the electrics being turned off (goodbye computer/results). This week I will continue with the my write up of the multi-matching, with the hope of finally moving to the dynamic work ASAP.

As for a plan for the next few weeks, the next Research Degree Meeting is in September and I am in dire need of making my MPhil/PhD transfer (making it 24 months instead of the original 18, or the later 21 months), so in regard to this, I would like all the static graph work complete. Additionally I would like to have implemented the Dynamic graph drawing technique given by Veldhuizen in preparation of my own contribution, with about 30-50% of my thesis written (only in draft).

Now you may be thinking this is quite a steep expectation from myself, me too, but I can try - and if it succeeds, I'll be laughing. If, for whatever reason the plan fails, plan B (Panic) will become my immediate priority.

For now thats all, I shall update again if and when I make any progress. Enjoy the Olympics!

Survival

It worries me that I wrote an update for this but instead of being published, it was saved, and I didn't notice - even after checking back here several times.

Nonetheless, a brief update of the past two weeks.

Week A represents the week I participated in the iV2012 conference, and overall, I feel it went well. I met with some other members of the Graph Drawing community and discussed some of the problems weve been having and are dealing with at the moment (primarily, designing a structure for dynamic graphs where positions of finer vertices can be used to update coarser vertices in the multilevel structure).

The session itself flopped at the start with no chair turning up. By popular demand (of 2 people) I chaired the session myself (titled Application of Graph Theory) which again went well - I was even thanked afterwards, which although customary, was a confidence boost.

The presentation also went well, with a good response from the audience. Though questions related more to the measuring of aesthetics than the algorithm. No fires, no murders and no horrible hangovers, overall, a good week.

Week B representing this week so far, has so far entailed my return to the technical report which, like everything else I do, has taken forever. Thankfully the conference has given my a little boost to finally finish this piece of work and move on to the bigger problem. Previously, results collected regarding the multi-matching showed a massive increase in runtime with MGF taking almost 4 times as long as the QT - contrary to the single edge contraction implementation.

This has since been fixed and now results are as expected (or not so if the data is correct - which I will explain another time). Unfortunately the edge crossings have now increased to a similar ration (4x) though some results show a decrease to normal levels for matchings of more than 3 vertices. The cause is being investigated.

Week C representing future work: GETTING THIS DONE ASAP! Thats all for now though, see you next time readers.

Whoops... Better Update

Every time I come to this I begin writing, then get immediately distracted by something shiny and forget about it.

So a quick catch up, last week I was away from work on holiday - so the gap in my posts can be explained by that (this is more for future me when I come to write up my logbook... btw Carl, get back to work).  You'll all be happy to know the cat is fine. Before the holiday, I was setting up and began running the tests for my latest multi-matching implementation - with some analysis of the results thrown in there.

This week has seen a continuation of that analysis in time for a meeting with my supervisors. The results showed that the MGF (CA) tree is much more susceptible to the multi-matching (for the graphs 3elt and data in only 2D layout), showing a large decrease in runtime for matchings of 3 and 4, with a smaller decrease for 5 and leveling out thereafter. The Octree also showed this decrease in runtime, but was not as significant.

An issue with the results is that the runtimes recorded for the MGF tree are much higher than the Octree (contrary to previous implementations). This is almost definitely due to the way it has been implemented (the MGF algorithm was almost completely re-written whereas the OT algorithm remained the same). Other issues show that the results for 3D layouts increase in runtime for the matchings, for BOTH MGF and Octree, suggesting more implementation woes.

Results for 55grid shows some interested spikes in the number of edge crossings for matchings of 3 and 5 vertices (prevalent in both 2D and 3D resultsets), which my supervisors and I believe to be due to the structure of the graph and itself having "preferences" (and sentient thought...).

Since the analysis I have been preparing for the IV2012 conference which is next week. I have been working on my presentation since Yesterday though little progress has been made to change the content since my previous presentations.

Tomorrow will be spent panicking and practising the (hopefully) finished presentation. For now, thats all folks, I shall update next week during or after the conference (if I survive). Au revoir!

Leaping Forward

This week I have spent huge amounts of time attempting to escape the gravity well of the multimatching work, and finally, it has paid off. The multimatching algorithm is now working for all algorithms (multilevel, octree and MGF) and my experiments have been started. I should have results by Monday, and am currently writing up the technical report to accompany the work.

So finally, I have made some progress - and what a feeling it is.

Currently there is nothing else worth mentioning and as it's a Saturday, I want to get back to my precious games, so for now, that's all. Stay tuned for The Results Return, where our protagonist identifies the unlikeliest of  issues, and fights for his sanity so he can return to the glorious path of Progression.

Have a good weekend!

EGH2012 Workshop

So remember how I dislike talking in front of crowds of people? Turns out mathematicians aren't people, theyre cruel questioning machines who seem to know everything about the universe. Why do I say this/bring this up? Well I had the great fortune of being included in the EGH2012 Workshop right here at the University of Greenwich, and was allowed to give a short 10minute exposition of my research.

Although I wasn't ridiculed, I feel I could have done better regarding my explanation of some aspects (such as the forces involved and their importance, and more about my intent regarding dynamic graphs). I was only faced with one question regarding multipole techniques, which was relatively easy to answer - but I am bias by not being able to "see" what I said (what I think I said and how it came out may differ...).

However pessimistic I can be, it was still good practice for talking in front of an audience - even more so for an audience unfamiliar with such a topic. Moving on from the horrors, I am continuing with the issues of the multimatching layouts, with a hope of finishing this by next week (by may mean by Friday next week, but we will see how progress goes over the weekend).

A rather short update for now, mostly due to my attendance of the EGH2012 workshop but also due to the lack of progression of my research. On the bright side, I have been preparing some notes regarding my implementation of the MGF tree in a dynamic enviroment to reduce the time required to respond to changes. For now, thats all folks, have a good weekend.

Foolish Mistakes

As expected, there is only one explanation for every error that occurs in my applications - me. It seems once again, the massive increase in runtime was my fault and down to the smallest mistake known to mankind - using the wrong information.

As identified time and time again, the issue was coming from the calculation of repulsive forces, where it spent more time than it should have (4000ms instead of 900ms for 3elt, for example). At first, this looked to be the tree, which after some difficulty and work, was ruled out. The structure of the approximation/coarsening tree was as expected.

It was then hypothesised that more time was spent converging to a nice layout, but once again, a comparison of the number of times each algorithm run showed no difference. When coupled with the tree structure being correct, this didnt make much sense.

To aid in finding the issue, I had friends/fellow programmers (the whole of 2 people!) check over my code and try to identify the changes from previous implementations. This came up with many causes which were ruled out, but came to the conclusion that it was something I had assumed in the algorithm which was incorrect.

Finally, outputting every possible computation at every stage identified the problem. Instead of using the matching tree to approximate forces, the application was using the list of adjacent vertices. This caused the number of calculations to increase to a function of the average degree within the graph (as opposed to a lower number given by the matching number - in this case 2 or 3).

Fixing this has identified some other issues which are currently being investigated, but thankfully, I can now finished the implementation, move onto the testing/experimentation and finish this. I shall update again next week with a small progress update.

Have an enjoyable 4-day weekend!

Is this even my code?

This week I have been continuing with the coding of the multi-matching which, as mentioned before, is becoming a more prominent pain than it should be. As this is similar to my previous implementation, and much of the code pasted across, it is difficult to identify which part of the previous algorithm should be saved and which should not.

Unfortunately there is not much else to update upon at this time, unless you like reading my complaints about my own work... Regardless, any timeline/plan I set for this seemingly simple task gets completely ignored, so for now, I will set one for the end of June (because a stupidly large amount of time should be enough, right?). I will look to have everything finished, with the possible exception of the testing, by then so I can begin the long awaited dynamic work.

Paper Submission and Matching Hells

This week started well with my start on re-arranging the Information Visualisation 2012 conference paper to match the required style of the IEEE publishing template (in what can now be called the most irritating activity of all time). This continued until yesterday evening, with both conference paper and proceedings having been submitted successfully, and with registration and arrangement of travel and accommodation underway (not that I have much to do with that).

From today onwards, I have been working to resolve the big difference in runtimes between the previous edge contraction implementation, and the multimatching. Unfortunately, this is harder to fix than previously expected, but as I continue to work on it, other ideas/issues come to mind which could affect the results (but due to the vastness of the subject, may be identified and not researched to save time) - i.e. using theoretic distance between two parts of a graph to limit matchings and calculating the ideal number of matchings given the connectivity of a graph.


For now, I continue to progress with the matching - which will hopefully be finished before the end of the week (another week... *sigh*). I shall update if and when any significant progress made, or next week otherwise.

Multi-matching: A mixed blessing

So... Multi-matching... slowly becoming my biggest pain (first being my seperation from my cat and second being my seperation from online gaming with Diablo III being released next week).

The matching is turning into a very tempermental system. Last time I posted, I had managed to get the "dumb matching" working with some small issues implementing it with the FDP algorithms. This has since been fixed (though it's still not implemented with the Barnes Hut due to the god awful complexity of the data structures involved). I am now given good output with similar graph drawings generated for matchings of 2 and "rougher" drawings for further matchings (to be expected, an analysis of which will be included at a later date).

Unfortunately, there is a significant runtime difference between this and the previous hard coded implementation (single matching): a difference in the region of 9x the runtime. Outputting runtimes for individual components (calculations of individual forces), the significant difference in runtime comes from the use of the tree in the global force calculations, which has more levels than the previous work (most likely due to changes when adapting it to use the multi-matching scheme).

Diagnosis and fixes are in the works as I type and further information will be posted later, but for now, know that the latest implementation of the coarsening tree is drastically slower than the previous. I will hopefully update later this week (or early next) when the issue is resolved.

Keeping reviewers, and myself, happy

This week I have been continuing with my implementation of the matching; attempting to fix the many problems it seems to have with my already existing "testing suite". Although many have been resolved or patched, there remains a larger issue when attempting to extend coordinates calculated in coarser graphs to the finer graphs (the dreaded NaN has returned).

Experience suggests this is a bug somewhere within my code where I am dividing by zero - normally due to calculating repulsive forces between a vertex and itself (resulting with a distance of zero). However, this only appears once so a more thorough examination of verbose output is required. I will update again if and when this is resolved.

Additionally, I have been working to alter my iV2012 contribution, requiring some investigation into why my MGF(CA) algorithm is faster that the OT for smaller graphs, but slows for larger graphs. Originally I hypothesised that this was due to the dimensions of the tree but failed to give any real description or evidence. Having looking into this a bit deeper, I have found my hypothesis is correct (quite significantly - in fact, its surprising my algorithm keeps up with the OT, see the below table for a comparison). Further discussion of this will be included in my technical report, and due to the amount of information, it can only be summarised in my iV2012 contribution.
 

			Levels
Graph	|V|	|E|	QT	MGF
3elt	4720	13722	14	14
uk	4824	6837	15	22
4elt	15606	45878	13	17
fe_sphere	16386	49152	14	15
finan512	74752	261120	14	36
wave	156317	1059331	15	89
dime20	224843	336024	15	52

Other changes, as requested, are being made to the submission but the limited page count is beginning to limit my additions (im convinced they set it just to play with me...).

For now, its back to "work". I shall update again when I have made an acceptable amount of progress, or when I get distracted from what I should be doing. Whichever comes first.

Vertices, No Edges (not disconnected graphs)

Just a quick update today.

I have been progressing on with the multi-matchings and have finally got a version working, expanding on the edge contraction used previously and allowing multiple connected edges to be collapsed at once. This has been shown to work for any number above one and generates a much shorter multilevel/contraction tree.

In order to successfully achieve this, the method of storing the graph has changed. We now omit the Edges list and store all related vertices in a list attached to each vertex - almost exactly as it is stored in the chaco file, and exactly as implemented by Walshaw.

With every silver lining is that underlying cloud though, and here, that cloud is what I call "dumb matching". Currently, the algorithm reads through all vertices and if applicable, finds a match with any related vertices, however, this is only limited to vertices it is connected to, as opposed to a trail of connected vertices, leading to an independent vertex subset which is not maximal.

The "smart matching" implementation is paused, but will be underway when the "dumb matching" is successfully integrated into the current testing suite (due to the change in storage structures - existing code needs to be altered to accept both new and old data structures).

Progress on the report is unchanged at a level between slow and none.

The iV2012 conference has accepted my paper with some useful comments, unfortunately highlighting one of my fears with this work - that it is not particularly original, having reused other peoples work to generate something new. Regardless, this is good news so I am relatively happy.

That's all for now. I will hopefully include some descriptive images of the matching technique I've used in future posts when I have finished playing with my code and I will keep you updated with any other progress, and if course, if my research is ever accepted by the Research Degrees Committee.

Multimatching - back to you is it?

If the title was an unsuccessful hint, this week I have been working on the multimatching algorithm for replacing the currently used edge contraction method. This has been started countless times before and progress has been made - however, due to the amount of time between my work on it, I've had to spend the majority of a day catching up on my own work.

Additionally, I realised that some of my work is not longer applicable - the paper I have written for the IV2012 conference uses the edge contraction for comparisons, but the newer multimatching uses hashmaps for its storage (and other tasks), resulting in an unfair comparison. I now get to choose whether to continue with the previous approach and provide compareable results or continue using hashmaps for this report and provide new results. <EDIT> In a sudden moment of clarity (and remembering the obvious) - the multimatching method should work for edge contraction in the same way, albeit a little slower. Therefore I will be using the multimatching method for all result. </EDIT>

Much of the report itself has been put together (as mentioned in my previous blog entry) but no significant work has gone into refining it. Some may call this laziness, I call it preparation and excitement for my return to coding. In the mean time, I am going to return to the code and hopefully finish that before the end of the week. I will update again when any progress is made. Sayonara!

Better extinguish my laziness (again)

I recently remember I had a blog to continue, so before I let it become one of those "I'll do it later" tasks, I better pull it back from near-extinction.

Last week saw my return after my Easter Holiday (Wednesday was my official day of return to be specific - should it come up later), which also saw my return to marking. Fortunately my marking was complete and I was only required to transfer my marking from paper to its required digital format. Additionally, I spent my time working on little bits and peices (my way of saying I may have procastinated a little).

This week has seen my return to paper writing! Although no part of me enjoys writing papers, it was comforting that I have already provided myself with a template for my intended technical report, and having written a conference paper for IV2012 (of which I should hear whether it was accepted or not on the 22md April) it has made it a lot easier for me to continue onwards.

I am hoping to complete a reasonable draft (for myself) this Friday, so I can begin my process of improving the report - similar to the approach I took with the conference paper, which didn't turn out so bad.

Having read through my previous attempt at this report - I am realising I will be returning back to my code soon enough in order to gather some more results (words cant describe how happy this return makes me feel). These additionally results will hopefully identify the causes of some of the behaviours present in my work.

I will update again soon, for now, I leave you with Professor Meowthykins to brighten up your Wednesday:

Back to Reality

Jury Service is finally over! 2 weeks was a bit longer than I had hoped, but I'm thankful I was not called back for a third.

So some news over the past weeks:

• IV2012 Conference Paper submitted - I am very happy with the finished paper but concerned the conference may not appreciate it due to the topic (graph drawing algorithms are quite a small part of data visualisation, especially where other more graphical works take proprity) but we'll see
• RDA4 submitted - catching up on my previous RDA4 (annual update form) gave me an idea of where I'm supposed to be - which fortunately looks to be only a little behind (due to my work on Multilevel Global Forces)
• RDA1 was rejected - an unhappy bit of news to hear when I am away from work, which pushes my PhD transfer back (cant transfer without having my research approved). Fortunately a revised copy was completed and sent off, so we can only hope for good news.
• I return to work on the same day as coursework is due - someone somewhere is playing cruel games with me

 Thats about all the news I can remember from the past few weeks. As for my current plans, getting my Technical Report for MGF is priority (also marking), which will be this week. After which, I can concentrate on the dynamic work.

Additionally, when the decision on my RDA1 form has come through, I will be completing the relevant online exams, writing the necessary progress report and arranging for my MPhil/PhD transfer.

That's all for now folks, Sayonara!

Bricks will be - laid nicely

A bit of a hectic week this week as I had my PhD Seminar today. Most of my time has been spent re-writing my previous seminar's slides to reflect my current work and my progress, I have also been playing with some of my implementations - mostly for funsies but to check where I left the multi-matching work.

Unfortunately, next week I am stuck in non-work related activities [JS], so unless I am particularly lucky, I will be unable to continue with much of the work.

So... what's left for me to do...

• I have still got to finish my paper for the IV2012 conference
• Yet to refine and finish my Technical Report on the MGF/CA algorithm
• I need to write a report regarding my research explaining why I should be transfered to PhD
• Finish the Multi-matching Implementation, Experimentation and Reports
• Begin writing drafts for my Thesis chapters (maybe not full chapters but writing up my research this far)

Seems longer than I remember but oh well, one thing at a time.

Not much else to say for this post - the PhD Seminar went... something, probably repressed already. Paper is going OK-ish with the deadline extended to 21 March. Better news though, the seminar has returned my enthusiasm for the dynamic work again, so I am looking forward to playing with that.

I will update again soon, or when I can next remember.

Almost... Just Almost....

So this week I've/We've been putting the finishing touches to the paper titled "A Multilevel Force-Directed Graph Drawing Algorithm using Multilevel Global Force Approximation", and by golly its been fun. I have found I very much prefer writing smaller papers instead of the monolith of a technical report that's hiding away behind me, but alas, I think I have mentioned this before.

So... thankfully the deadline for the paper has been extended to the 21st March (not that I want to wait but better to be safe than sorry) which gives us a little more time to add or remove and make any edits that are required. Unfortunately, my PhD seminar is next week (7th March) so I have yet another thing to worry about.

All in all though, its been a relatively stable week. Major changes to the paper have been completed and I have more to make by tomorrow, and also a new presentation for next week. Should make for an interesting Friday.

Now that I'm bored with the seriousness, here is some images...

10x10x10 grid drawn in 3D, top two are the MGF (my application, formerly CA)

bottom are the OT drawings, shown from two angles

fe_sphere with MGF on the left, OT on the right showing some flattening from the octree structure

An interesting image of add32 drawn using the OT

 Mesh100 drawn using the MGF algorithm, very similar to that drawing by Walshaw

Bunnies

The Emporer, formerly Chancellor Palpatine and sometimes known as "why would you show me a picture of an old man dieing"

General Update 3.1.607-33

It's been a bit of a busy week, but I'm almost there; our draft conference paper for IV2012 was finished Monday, or Tuesday (it's all blurred into one long day...) with some of my own corrections made yesterday and my supervisors comments today - so all in all, its going well.

Today is our second meeting in a month (mother of god...) and no doubt will focus on how to improve on the conference paper, and if the School budget will allow me to even present at the conference. I would like to take this chance to say "small papers are the best!", due to the ease of writing and not having to explain everything in the explaining of everything, everwhere.

There is no much else to discuss this week, but in the mean time, here are some graph drawings from the past month. For each of the images, the drawings from the coarseing tree/contraction approximation are on the left, and those from the quadtree/octree are on the right. Click on the image to view in higher quality.

 

10x10x10 cubic grid 

1000 vertices 2700 edges

 

3025, a 55x55 square grid

3025 vertices 5940 edges

 

3025 edit, the 55x55grid from above with opposite corners connected by edges

3025 vertices 5942 edges

 data

2851 vertices 15093 edges

 

 whitaker3 (supposed to be a rectangular drawing but some part of my algorithm forces this warping)

9800 vertices 28989 edges

 3elt

4720 vertices 13722 edges

 4elt

15606 vertices 45878 edges

 finan512

74752 vertices 261120 edges

 sierpinski10

88575 vertices 177147 edges

dime20

224843 vertices 336024 edges

Super Special Awesome News Batman!

Looks like I finally have a deadline for my paper-related nonesense; this time the aim is for a small 6-page conference paper for Information Visualisation 2012. The deadline is 1st March, which gives me 2 weeks to write a 6 page version of something thats taken me several months, and as many would agree, far longer than it should have.

The great news is for the paper, I will not have to explain anything and everything that might be linked to the subject, and will provide me some experience of reducing an idea into a very compact document - a useful skill for journals (so i'm told).

On top of this, I have finishing the results half of my document having fixed a bug in my implementation of the quad tree approximation (apparently I cant change small peices of code without the algorithm freezing for 3hours on a 75k vertex graph...). That will be sent off to the supervisors today in order for them to look over in order to prepare for the conference paper.

For now, I will stop procrastinating and get back to writing. Sayonara.

A developing topic

For the past few days I have been collecting, preparing and discussing various output drawings from my graph drawing algorithm, comparing to that used by Yifan Hu. It was always an interest how the different approximation techniques affect the output (a bit obvious, considering its the only difference), but it is becoming more and more prevalent in smaller graphs.

The contraction technique causes a final approximation tree with a root and two children; each child with a weight summated from all the vertices it models, which is used when calculating how much force that supernode exerts on a singular vertex. As there are only two children, in comparison to the quadtree's 4, or octree's 8, it causes the graph to warp around the vector seperating them (due to one side of the graph pushing the other away and vice versa instead of an all outward force).

In comparison, the quadtree pushes out in 4 directions, which causes a much more uniform drawing. As mentioned before this technique is more prevalent in smaller graphs, which much large graphs looking much more like they should. As a brief experiment, I took out the weight from the repulsive force function, which as expected, reduced the stretching (unfortunately, it also caused the collapse of global structure, a result of weak repulsive forces between supernodes and vertices).

The future work on matching will provide some more critical evidence to further investigate this effect and how the contraction approximation can be altered to tackle it (without having to match large numbers of vertices - 8+).

Damn You NetBeans!

When testing the Multilevel force directed placement algorithm, with no approximation, for multiple parameters (running 100+ times), be wary not to agitate NetBeans. Having attempted to delete a different project, I have now caused a verification pop-up which will never close.

I have come across this once before; the pop up wont close until all java applications have finished running - I had previously thought I found a way past the bug, however, my actions are limited by the running application which I want to avoid stopping prematurely, so I can't play around by closing related Services. As a result of this pop up, I am unable to use ANY features in NetBeans whatsoever - so am unable to run or edit any other of my programs until the others have finished

To further improve on this situation, the application has been running all weekend and still not finished.

Bitterness aside; during the end of last week I made some more progress on the papers - collecting some output images to include and compare, collecting results for a wider selection of graphs (for comparison against Hu), begun testing on the quadtree for the wider selection of graphs after some minor changes, and made some further progress writing for the second paper - though realising I have more research to do in order to investigate the effects of different matching techniques.

This week I will also be aiming to begin implementing the dynamic algorithm given by Veldhuizen - as an attempt to escape static graphs.

Behold, the Things To Do Notepad!

This week I have made an incredible discovery: there are notepads dedicated to daily To Do lists available at the CMS School Office. I guess its not that big of a deal but now I can keep record of what I have done and what I need to do in clearer detail.

So, since my last post (and acquisition of the To Do book), I have:

• Finished generating the charts required for a comparison of the Contracton Approximation and Hu/Barnes Hut Quadtree approximation. [prepared]
• Discussed the comparison in runtime and quality [written]
• Explained the relationship between the size of the output area and the behaviour of the FDP algorithm [written]
• Explained the relationship the strength of repulsive forces and the size of the graph [written]
• Organised some of the output images (subjective results) [prepared]
• Discussed the choice of default values for graphs [written]

 In addition, I am also currently:

• Discussing subjective results (output images) [in writing]
• Generating new results for a wider range of graphs (specifically those mentioned in Hu's work) using the "default values" gained from the experimentation [running]
• Generating normal Multilevel results (no approximation) for comparison to test data [running]

And for future work, I have planned to:

• Organise references for the papers
• When complete, analyse and discuss the results of other graphs (using default values)
• Critically analyse the subjective results
• All the multi-matching stuff/things/work

Just a small insight into the week in a quick and easy to read format (though without context its all pretty meaningless, but thats not so much of an issue).

Almost There

Last week I reworked my first paper regarding the Contraction Approximation and managed to get the majority of the previous work and theory in order. Unfortunately, I could not complete the results section and beyond due to some unexpected issues with my collection of charts, graphs and images - some missing headers, some were under the wrong header and others I don't remember drawing.

This week I will be sorting through those images and gradually adding them into the paper, followed by a continuation on the multi-matching and how that affects the contraction approximation. My aim is to speed this out as quickly as possible so I can begin to look at dynamic graphs a bit more.

For the dynamic work, I have looked at a small example I will use to identify the behaviour of such a system and outline some development ideas for future use. The example is a model of an expanding auction site, with pages and entire sections being added and removed constantly. As this is just an example and a website is only one of many data collections which could be used, I am looking to implement some unexpected behaviour which I have yet to choose and investigate.

For my own enjoyment, part of this be a god mode which will add hundreds of vertices with edges between all pairs, to the graph.

The benefit of this example is that I will be able to use a data collection gathered by one of the University students when the algorithm is ready - without needing to test the algorithms progress. Why don't I just use the students work? The data I am expecting of them, is larger than I would like for a simple testing example, therefore I would prefer to use an example which is easy to manage to begin with.

These are all just plans though; the real work might turn out very different. For now, I want to finish my papers.

General Update

An unimaginative title for an unimaginative post.

This week I have made good progress on paper 1 with a start on paper 2 (mostly copying and pasting remnants from previous attempts at writing), but sadly, have been once again called back to the academic world with the requirement of organising plagiarism offences and finalising marks. But not all bad, it should only take the rest of the day... and I also have cookies.

So... What next? well, I will be finishing my paper (hopefully) by the end of the week with copies sent to the supervisors (this sounds very similar to previous plans...), with a continuation of the muddy half-eaten homework which is paper no.2 once I have rid myself of no.1. From there I can continue my attmepts at implementing multi-matching/clumping and can progress into the shallow and ambigious world of dynamic graph drawing.

For now, I must continue with the academic work then roll on to the research work tomorrow - horray! Time for a cup of tea.

Writing Away!

Surprise! I'm doing real work this week and its a weird feeling. I should clarify, "real work" is "phd work" and not that overly-stressed business-filled work those outside (and some inside) of the academic bubble have to deal with.

Over the past two days, I have been applying changes to my first paper based on the comments of my supervisors, and will be continuing today. I am surprised it is taking so long for me to make these changes (you may be less surprised at this point) but reading through it again is helping me become more aware that my writing is awful, and therefore I am rewriting vast quantities of it

Now, for less useful news: It's skills week at the CMS school this week so students are preoccupied and CMS Seminars begin today (mine being during mid-March). Also, Wikipedia is down as part of the SOPA-blackout.

Not much else to say today but I will update again when I have finished making changes to this paper and begin the experimentation for the second paper. Have a fun Wednesday...

Oh no, its still here...

...the marking that is. It seems it was designed to be the worst peice of marking in recorded history, with every bit made painstakingly long and tedious to get through. Thankfully on the reports to go, which is the short bit.

Progress has not been made this week, even after being given notes on my sad attempt of a paper. Fortunately, next week is Skills Week for our beloved students, which gives me an entire week of PhD focus, so I'm planning to greatly improve on my first paper and start my second during those few days of happiness.

Other than that, I have been avoiding invigilations and hiding from addition tutorials in an attempt to focus after the christmas break... its not helping as much as I thought it would. Weirdly enough, the enthusiasm and will to do work is here, but everything else is against me doing work.

This madness will have to stop soon anyway, im beginning to see the half way mark on the horizon (which should be time for my MPhil to PhD transfer) so I will need my papers finished by then with some part of my thesis drafted. Time is running out! Which makes this game a lot more challenging, interesting and most of all, fun :D


See you on the other side (of the weekend)!

Well, that was a nice break

And after a nice break, comes the storm that is everyone going back to work.

As can be expected, work will no doubt be slow this week to cope with getting back to normal, therefore, this week shall now be known as Marking Week! That's right, a week dedicated to marking those courseworks submitted over the Xmas period; aren't I lucky.

If the marking is completed before the end of the week, the remaining time will be dedicated to making changes to my paper regarding the Coarsening/Contraction Tree Approximation which you may have noticed, I spent the past few months researching (exciting). What if I complete that too, you say? Amongst the world ending and winning the lottery, I will move straight onto the paper regarding how multi-matching affects the CA, which will bring me to the end of the week, or the end of my sanity, whichever comes first.

As you can probably tell from the manner I am typing this in, I am still partially on holiday mode, so for now, I will leave you knowing that I did survive the winter, and you will get to read more of my nonesense later this week; aren't you lucky.

Hope you had a good Xmas and New Year!