lunglet.net

I had high hopes for the OpenMP support introduced in GCC 4.2, and then came this:

• libgomp and python: dlopen fails
• GCC Bugzilla Bug 28482 - Cannot use libgomp in shared library

Reported by Nathan Bell on the NumPy mailing list.

I received what I am choosing to call the first pyactivemq bug report. World domination is now but a mere formality.

I recently ported one of the JMS examples from the Java EE 5 tutorial to Python and pyactivemq. Check it out on the Examples page. Everything works, except the final call to cancel the subscription. This should work once AMQCPP-132 gets fixed.

I’m currently working on some algorithms for which I’ve found it very useful to be able to generate the same random numbers in Python (using NumPy’s numpy.random module), C++ (using the Boost Random Number Library) and MATLAB (using the rand function).

I use the random numbers in tests, where being able to generate the same random numbers everywhere has been very useful. It allows me to compare the output of my algorithms exactly. For example, I might implement an algorithm in Python with NumPy first, write some tests, and then rewrite it in C++ (for the cases where I need the extra speed).

Getting MATLAB and NumPy to generate the same random numbers is straight forward. It seems NumPy uses the Mersenne Twister algorithm. MATLAB can be configured to do the same. Specifically, the following code generates the exact same 10 numbers with NumPy 1.0.3:

numpy.random.seed(0); numpy.random.rand(10,1)

and MATLAB R2006b:

rand('twister',0); rand(10,1)

However, the Mersenne Twister combined with a uniform distribution generator from the Boost Random Number Library don’t generate this same sequence. A quick glance through the NumPy and Boost code seemed to indicate that they use the same magic constants. I used the following C++ code with Boost 1.34.0:

#include <boost/random.hpp>
boost::mt19937 rng;
rng.seed(0U);
boost::uniform_real<> uni_dist(0, 1);
boost::variate_generator<boost::mt19937&, boost::uniform_real<> > uni(rng, uni_dist);

I’m guessing that NumPy and Boost simply do slightly different things with the bits that come out of the MT algorithm to generate the respective uniform distributions.

To work around this problem, I cooked up a Boost.Python wrapper for the Boost Random Library classes so that I could generate exactly the same numbers in Python and C++. You can take a look at the code here (the tests are still a work in progress):

• random.cpp
• test_random.py

The interface exposed by this wrapper behaves more like the stuff in numpy.random, compared to the wrapper in pyboost, which could be considered a very literal translation. It probably also wouldn’t be too hard to wrap these classes with MEX for MATLAB, guaranteeing you the “same” random numbers across all three platforms.

Disclaimer: I am not an expert on anything related to random numbers (except making them up in my head).

I have sent pyactivemq 0.0.2 out into the world. pyactivemq is a wrapper for ActiveMQ message broker. pyactivemq uses Boost.Python to wrap the ActiveMQ C++ library.

Update: Since making this release, I’ve done a few more hours of work on pyactivemq. I’ve almost gotten multiple consumers with message listeners in separate sessions to receive messages, i.e. multiple threads calling back into Python code almost works. I need to stick a lock or grab onto the GIL somewhere, but I’m not exactly sure where yet.

I was recently writing some tests for a Python extension module that uses Boost.Python. To keep things agile (i.e. keep compile times down) I have a few #ifdefs in my code that allows me to disable various parts of the module when I’m only interested in other parts. This greatly reduces the time of edit-compile-test cycle when your module starts getting really large. I wanted to skip certain tests in my test suite depending on whether a part of the module was available. Here’s what I came up with:

import unittest

class _test_foo:
    def setUp(self): pass
    def test_baz(self):
        self.assert_(True)
    def tearDown(self): pass

try:
    from extmodule import foo
    class test_foo(_test_foo, unittest.TestCase):
        pass
except ImportError:
    print 'skipping foo tests'

if __name__ == '__main__':
    unittest.main()

• Ruby on Rails Hello World on GlassFish
• Database-enabled Hello World RoR app
• Database-enabled RoR WAR on GlassFish
• Google Maps Encoded Polylines
• Annotation-Driven Dependency Injection in Spring 2.1

I recently cooked up a little Python script that uses the excellent BeautifulSoup HTML/XML parser to scrape the images in the swell, period and wind charts for South Africa from MagicSeaweed.com. I used the time series feature that was added in Google Earth 4 to display the data in sequence. You can view the results here:

• South Africa Swell Chart
• South Africa Period Chart
• South Africa Wind Chart

If anyone knows where one could find the raw data from which these images were made, I’d be very interested. Plotting the data as polygons would probably look much nicer than image overlays when zooming in.

If anyone is interested in the code that does the scraping, let me know. You’ll only have to change a few coordinates (obtained using Google Earth) and URLs to adapt it to fetch the reports for your location.