Friday: back at last …

Due to a number of issues, interuptions to the normal service, but we’re back with a pre-Christmas flurry:. Did some writing on emergence report: bit popular-science at the moment, but thinking this could be sufficient.

Other reading/thoughts:

• P2P and flocking:
• http://scholar.google.com/scholar?hl=en&lr=&q=ants+p2p&btnG=Search
• see anthill also
• DRM and flocking
• trust and emergence
• disruptions to a flock

Monday: writing up emergence …

Still writing up the emergence report:  today covered ACO.

And because been thinking about it, a definition of trust:

1. Firm belief in the honesty, veracity, justice, strength, etc., of a person or thing

Belief:

1. Trust or confidence
2. Acceptance as true or existing of fact or statement

Confidence

1. Firm trust

Friday coding: exceptions in practice …

Working through a chapter on dealing with exceptions in Python. Getting there … I think ;-).

Monday: back and blogging! …

After an unexpected hiatus, I’m back! Decided to write up what I have read on emergence to see where I’ve got to — I have a feeling I’ve captured the basics/essentials, which I think will be sufficient to start me off.

Also reading Emergence by Steven Johnson, a pop-sci book (my early thoughts, anyway) on emergence (Emergence: The Connected Lives of Ants, Brains, Cities and Software), as bedtime reading, after coming quite a good interview with him on the O’Reilly network, and a chapter he wrote in Extreme Democracy (6. Two ways to emerge, and how to tell the difference between them by Steven Johnson). Seems a reasonable book, and could throw up something new which I haven’t seen before.

Currently battling a LyX (http://www.lyx.org/) install, as potentially a better way to create documents — I’ll wait and see how it goes!!

Wednesday — Ants …

From Inspiration for optimization from csoial insect behaviour, E. Bonabeau, M. Dorigo, G. Theraulaz. Nature, 406, Jul-2000, pp39 — 42

• how social insects collectively solve problems => artificial problem-solving techniques =>swarm/ artificial intelligence
• underlyigng model of intelligence is collective intelligence of social insect colony
• models based on self-org. can help explain complex colony-level behaviour emerges out of interactions btw individual insects
• ants mdoels of co-operative food retrieval => inspired optimisation and control algorithms
• ant colony optimisation (ACO)
• ant colony routing (ACR)
• how do ants work together:
• ant colonies can perform taks together and make decisions that seem to require a high degree of co-ord. amongst ants
• e.g. build a next
• typical example is finding food, and finding the shortest path to the food
• ants can lay down pheromone trails, chemical substance that attracts other ants
• as more ants walk over the trail, more pheromone put down => stronger trail => more ants work over it => positive feedback
• in artificial situations, pheromone decay is modelled into the situation
• if pheromone decays sufficiently quickly, more difficult to maintain a stable trail on a longer path => shorter paths get invesigated
• this prevents convergence –> mediocre results
• often used in Travelling Salesman Problem (TSP)
• ant travels between n cities, visting ea. one once and ending at the start point
• after each trip between cities, lays down a pheromone trail
• as more ants wander around the situation, links that belong to good solutions end up with more pheromone on them than other links:
• to select a city to move to, an ant selects one that is connected to the current city by a link that has > pheromonoe that the others –> selection process
• this selection amplifies previously reinforced links and leads to the emergence of a good solution
• evaporation prevents mediocre links from being amplified
• algortihms used to solve ’static’ problms, but can also maintain a pool of alternative solutions, which can be useful in changing situations
• a weak link can quickly be reinforced by more ants moving over it
• not very good at problmes uniformly randomly generated:
• ACO tends to reinforce sections of solutions that belong to many good solutions: the more solutions a section belongs to , the stronger it is reinforced
• however if you have a large number of solution sections that are equally likely to be parts of good solutions, ACO can’t differentiate between them => poor performance
• ACO used in ACR in networks: long delays in particular networks mean less pheromone deposited; quicker routes get more pheronmone, so more traffic diverted down those route
• Other applications inspired by social insects:
• division of labour
• e.g. not being so specialised you can only do one task
• certain amount of flexibility
• brood sorting
• data sorting
• co-operative transport
• e.g. small robots (Alice micro-robots, http://lis.epfl.ch/research/projects/EvoAnts/)

NB from Wikipedia on ants (http://en.wikipedia.org/wiki/Ants):

• same family as wasps and bees
• can swap tasks: e.g. if too many ants doing one task, will swap and do something else (coping)

Coding: Exceptions according to Jython …

From Python Programming with the Java Class Libraries, chap. 7:

• the exception has information about what’s gone wrong
• instead of using an if-else loop after each method, you set up one exception handler that works with many methods
• errors & exceptions:
• errors: usually involves syntax, e.g. missing comma
• exception: usually involes operation gone wrong, e.g. dividing by zero
• (can be correct syntax, but wrong operations)
• unhandled exception can stop program dead in it’s track
• try and except
• think try and catch
• can have > 1 except clauses — the exception handlers
• example (note blog foul-up of formatting!):
• try:
• suite
• except express-target:
• suite
• except:
• suite
• the ‘except’ without an express-target is a catchall bucket: if an exception doesn’t have a specific exception handger and an except caluse without an expression target is present, the exception will go to that clause
• call stack:
• the order of called functions
• imagine a module calls function A(), and function A() calls function B(), which calls function C(), the call stack is A->B->C.
• if an exception happens in function C() and isn’t handled, it propagates to function B(). If B() doesn’t handle it, it propagates to A(), and if A() doesn’t handle it, the program stops.
• Please note:
• unlike Java, not common based class in Python like Throwable, RuntimeException or Exception
• howeve,r Python has adopted the Java approach to exception handling
• in Python, exception matches a handler if the handler recognises the object that identifies the exception or a base class of the exception, or if the object thrown exactly matches the handler’s object identity
• in Python, the handler matches the exception if it has a tuple containing an item that matches the exception
• therefore you can handle >1 exception in one except clause
• NB exception code is expensive to run
• the try-except-else clause
• else is executed only is no exceptions occur
• you can raise an error
• think of exiting IDLE
• of format:
• raise exception-expression, description-expression
• or to use classes and instances …
• raise class, class-instance
• raise class_instance
• e.g. raise badListForm, “The list had a malformed tuple”
• bad practice to use strings to raise exceptions (fallen out of favour — use class instance instead)
• ‘raise’ with no expression reraises the active exception
• the ‘fiannly’ clause
• format:
• try:
• sutie
• finally:
• suite
• NB can’t use a finally clause and except clause in the same try statement
• the ‘finally’ caluse guaranatess the clause will be executed whether or not an excpetion occurs
• normally put cleanup code, like closing a connectoin, in finally clauses

Put this into action: go through the exception examples in IDLE, and see what happens

Friday Coding: Exceptions …

NB all of the following from Head First Java, 2nd Ed.

• problem handinling code for code which you can’t guarantee will work at runtime
• basically preparing yourself to handle a situation if something doesn’t work as anticipated — e.g. a server is down
• based on your knowledge that what you’re doing — e.g. which method you’re calling — is risky, and might generate an exception, so that you can write code to deal with that possibility
• if a method throws an exception, they’ll be a throws clause in the risky method’s decalration
• however need to tell compiler that you (the coder) realise you’re calling a reisky method
• wrap the exception in a try/catch block
• you tell the comilier you know something exceptional could happen, but you’re preapred to handle it
• (compiler doesn’t care if you are handling it — juts needs to be told that you are)
• in Java, an Exception is an object
• when your code calls a risky method, that declares an exception, it’s the risky method that throuws the exception back to you, the caller
• when you write code that could throw an exception, need to decalre the exception
• NB there are certain types of exceptions that the compiler will not check — RuntimeExceptions
• these Runtime Exceptions generally come from code logic issues
• there’s also a ‘finally’ clause, which runs at the end no matter what
• basic flow:
• try: attempt to do something
• catch: if the ‘try’ above fails, do this to recover
• finally: if the ‘try’ was a success, do this; if ‘try’ failed and ‘catch’ was actioned, do this when the ‘catch’ completes
• note similarities between this and an ‘if’, ‘if else’, ‘else’ logic flow
• methods can throw more than one exception
• the method declaration must decalre all the checked exceptions
• exceptions are polymorphic: you can decalre exceptions using a supertype of the exceptions you throw
• e.g. imaging you have a TrouserException, SkirtException and LingerieException: these could all be a subtype of ClothingException
• p330, Head First Java
• however, you should write a different catch block for each exception that you need to handle uniquely
• these need to be ordered from smallest (i.e. furthest down the hierachical parent chain — more granular) to largest (coarest)
• think about this logically: the more ‘granular’ exceptions are decendent from the ‘coarser’ exceptions — therefore, if you put a coarse exception at the top, the compiler will realise that the granular exceptions are of this type, and parse them okay — completely ignoring any special ‘granualr’ exceptions
• you can ‘duck’ out of the way of handling an exception, but just decaliring it
• the exception gets passed onto the method calling the method you’re calling
• p336, Head First Java

Next up …. Python !!