Thursday, June 17, 2010

New Address

Hi folks,
I'm moving towards WordPress: My articles will be published on aaron.karper.ch and d3orn.ch. See you there!

Saturday, May 22, 2010

Decorative Unit Testing in Python

So after some experiments in C++, this week I got back to where I once started: Python! The idea was, that I'd produce a quick prototype for something, so that I could translate it into another language. However, I got distracted as I often do.


First of all, I wanted to be able to test things in my prototype, so I wanted some kind of unit testing, so instead of actually starting to write code, I headed for the intertubes and googled for unit testing in Python.


In fact, there is the standard module unittest, just here. That's really cool, I thought, I'd be looking for hours to find something (as I did with C++), but this way, I could just begin. What I found rather annoying was that you normally have to put test in front of your test method names. My free spirit rebelled against such puny laws - you gotta start small with rebelling, right? Anyway, there was of course the alternative to write a test suite and just manually add all my test methods. Well... no.


But on the other hand, whenever you get an API to do something, you might as well automate the something as good as you can, so I started with the familiar JUnit syntax @Test to annotate test methods.


For those, who know the more obscure features of python, it should be clear, that this is a decoration in Python - a function modifying functions. In this case, I just left a note for me in the func_dict:

def Test(f):
        f.func_dict["Test"] = True
        return f

On the other hand, there was the problem, that no one would care for this fancy note, so I wrote an InSuite decorator for TestCase classes.


class InSuite(object):
        def __init__(self,testsuite):
                if testsuite not in __TESTSUITES__:
                        __TESTSUITES__.append(testsuite)
                self.test = testsuite
        def __call__(self,f):
                for i in f.__dict__:
                        if self.isTest(f.__dict__[i]):
                                self.test.addTest(f(i))
                return f
 def isTest(self,x):
                try:
                        return x.Test
                except AttributeError:
                        return False

This would add each annotated method to the given TestSuite, and all TestSuites that are somewhere mentioned, to a global list. These two decorators are a great team, just take a look at my tests:


FunctorTestSuite = unittest.TestSuite()

@InSuite(FunctorTestSuite)
class FunctorTestCase(unittest.TestCase):
        def setUp(self):
                ...
        @Test
        def shouldSquareResult(self):
                ...
        
        @Test
        def shouldNotTakeTooMuchArguments(self):
                ...


Tada! No more worries about naming conventions and InSuite could easily be extended to check for other annotations as well. Splendid, that was a rather useful waste of time!

Thursday, May 20, 2010

Thoughts on Neuronal Networks

This has been on my ToDo Heap for some time now: I started to implement some libraries for neuronal networks in nearly all languages I know. I'm no expert on this topic and I haven't actually been able to implement all the fascinating stuff so far, but there is still enough time left until the entropy death of the universe.


First of all, I should explain, what a (artificial) neuronal network is. Well, obviously it's about wiring neurons together. I like to imagine them as persistent functions: They provide a value, which can be computed with some inputs. As with functions, the input might itself be the value of a neuron, else one couldn't write for example abs(sin(x)) to compute the absolute value of the sine of a value x. On the other hand, often the input stays the same, so why not just keep the old value without recalculating, if the input didn't change?


And of course when the value of one neuron changes, there is a wave of updates: A changes, B has A as input and thus changes, C has B as input, etc. Quite like a normal program actually, you do some calculation, until your line of dependencies ends.


That's a boring program! It's just a straight line, we don't have any loops yet. But we could do that anyway, and there breaks the function metaphor: We could just wire them back to themselves.


Take for example the neuron A with the simple rule add your inputs. Now we connect

1 => A
A => A

and maybe add some things that do something useful. Now A might start off as 0 and update. It becomes 1 and update. 2 and update... That's just an infinite loop counting up, but one can easily imagine, that it is much better with neurons like 1 if the first input is greater than the second or 0 else.


For now that's where I am. There is of course more to it, as it is a possibility for creating artificial intelligence and dealing with computer learning, but you should probably read more about this, if you are interested. I might write more about this, once I have more time.

Hello World

(println "Hello World")

Hello out there. I decided to start a blog as a way to document my thoughts and sharing them with the world, which probably doesn't care about them. Anyway, I will mostly write about my experiences with programming, math and stuff. Have fun!