depth first search

A day of reading the SWIG manual and grokking the examples resulted in the following interface file. What does it do? It adds this to Python.

%module blobs
 
%exception
    {
    try { $action } 
    catch (...) 
        {
        return NULL;
        } 
    }
 
 
%include "exception.i"
 
%typemap(in) IplImage * (IplImage header){
	void * vptr;
	int res = SWIG_ConvertPtr($input, (&vptr), $descriptor( CvMat * ), 0);
	if ( res == -1 ){
		SWIG_exception( SWIG_TypeError, "%%typemap(in) IplImage * : could not convert to CvMat");
		SWIG_fail;
	}
	$1 = cvGetImage((CvMat *)vptr, &header);
}
 
%typemap(in) IplImage *mask{
	if ($input == Py_None){
	   $1 = NULL;
	}
	else {
		SWIG_exception( SWIG_TypeError, "%%typemap(in) IplImage *mask : masks not supported yet.");
		SWIG_fail;
	}
}
 
%typecheck(SWIG_TYPECHECK_POINTER) IplImage * {
  void *ptr;
  if (SWIG_ConvertPtr($input, (void **) &ptr, $descriptor( CvMat * ), 0) == -1) {
    $1 = 0;
    PyErr_Clear();
  } else {
    $1 = 1;
  }
}
 
%{
#include "BlobResult.h"
#include "Blob.h"
%}
%include "BlobResult.h"
%include "Blob.h"

I’ve added a new algorithm to my continuing series of Python implementations. A rather simple Metropolis-Hastings algorithm is ready for you perusal. All implementations in the series are now linked in the sidebar. Happy hacking!

I’ve also updated the site license. You are now free to copy and share anything written by me on this site (including the example code) provided you abide by the Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.

Now for some figures. A histogram of the resulting sample sequence (starting from x = 10 and running for 2400 steps):

A time series plot of the resulting samples:

As McKay points out, the random walk behavior is undesirable and requires that a large number of samples be taken for such a small state space.

UPDATE: My plots and code have an error. I don’t actually reject the rejected samples. I suspect this is why the left and right most buckets have more samples than they should.

I no longer choose to use Python. One day I decided to spend a couple of hours parallelizing some code for a new dual core machine. Than I discovered the GIL. From the Python list circa 2004:

I've said it before.  One day enough people will think that the GIL is
a problem big enough to warrant a solution, e.g., when the majority of
systems where CPython runs have more than one CPU.  Until then we have
to go back to early 90s programming and use IPC (interprocess
communication) to scale applications that want to run PURE python code
on more than one CPU.

That day has come to pass.

UPDATE: Though the lack of true threads is still a concern, I’ve found working with the latest iteration of numpy to be much easier than alternatives like Matlab or R. The truth: syntax matters.

I just watched an online presentation of SAGE, a nifty toolkit for doing mathematics. One of the really neat things about SAGE is that it glues together a ton of existing open source packages. We’re beginning to transition into the stage of software engineering where software development starts (in the minds of many futurists) to resemble archeology — digging up ancient secrets and putting them to work in new ways.

Python threads cannot run simultaneously. And forking two processes on a P4 with HT does not necessarily mean better performance. I don’t even want to attempt to unpack the existential reasons why I’m worrying about this kind of programming arcana in the middle of spring break.

But today is beautiful, so I’m going for a walk.