Posts
ODEPACK re-released
Minutes ago I uploaded a tarball containing my re-release of ODEPACK, a standard numerical tool for the solution of systems of ordinary differential equations. The algorithms and numerical code are identical to the distribution found on Netlib, but everything has been placed into an organized “package” with Makefiles, examples, documentation, etc. The code is set up to be compiled as a shared library that you can link to your code. Download and enjoy! And tell me if you’re using it!
Direct access to C++ containers from Python
In previous examples, I’ve shown how to pass Python lists into C++ using Boost.python. Because Python lists can contain a mixture of objects of different types, C++ has to use extract<type> to determine what kind of data to get from a list item. This approach works well, but it has its faults. In the C++ code, you might need to have duplicate data structures (a boost.python list to interchange data with Python and a C++ container such as a vector to process the data) and the code to convert between them. If you want to use your C++ library with languages other than Python, you want a non-Python-specific interface. Wouldn’t it be great to define your core data structures using a standard C++ container (like vector) and then access and modify them in Python? You can, but it’s non-obvious and it’s not well explained in the Boost.python docs. Read the docs for the indexing suite and take a look at my demonstration code for exposing C++ vectors to Python, and you should be able to figure it out. Once you get it working, it’s a very clean way of doing things. Just remember, because you’re working with C++ containers that accept only the specified type of object Python will throw a TypeError if you try to append the wrong kind of object.
Mixing objects of different types in a Boost.python list
Demonstration Code–mixing objects of different types in a Boost.python list In Python, a list is allowed to contain objects of various types. Using Python’s introspection capabilities, it’s easy to process a mixed list because you can just test each list member to see what kind it is, using isinstance(objectA, TypeB). This creates a problem when the list is passed into C++, where arrays and containers are designed to hold objects of one type. I encountered this problem when writing a small module to parse mathematical expressions. The expression is entered as a string in Python, which is parsed and “compiled” into a stack of objects. The compiled stack is passed to C++ using boost.python, where it is processed when needed. The stack consists of two or more fundamentally different objects: numerical constants and operators. The evaluation routine pops an object. If it’s a numerical constant, the value is placed on the operand stack. If it’s an operator, the appropriate operation is performed on the values at the top of the operand stack. With help from Alex Mohr and Christopher Woods on the C++-sig mailing list, I developed a method that is illustrated in the example. In C++, define a polymorphic base class (has at least one virtual method) and several classes that are derived from the base class. These classes are exposed to Python using Boost.python so that objects can be created in Python. A list of mixed objects is then passed back to C++ for processing. When trying to access a member of the list, C++ doesn’t know what kind of object to expect, so we have to use the Boost.python function extract<>() (see previous post for an introduction to extract). Now we extract a pointer to the base class using: object = extract <BaseClass*> (list[index]); This works because every object in the list is derived from the base class. As shown in the example, I first tried to do this with references (to avoid the whole pointer mess) but it did not work, so it seems that pointers are unavoidable here. It seems that this use of introspection is relatively rare in OOP, and is sometimes actively discouraged. However, for this type of problem it seems like the most logical design. Is there a different design pattern that would work better?
USPTO tries peer review for software patents
The US Patent and Trademark Office (USPTO) has launched a trial program to subject software patents to peer review online. Naturally, the big software companies aren’t exactly publicizing this. We all know that a lot of stupid patents get issued. Well, stop complaining and start reviewing! Let’s make this trial successful!
Truss warmers
Truss warmers are lights used to illuminate truss. Truss is fun to light because it’s semi-reflective and has a neutral color, so it easily reflects whatever color is used to light it. We used a little par light on one end of a section of truss to turn it blue, with a “cap” taped on the other end to keep the light from spilling out onto other stage objects. We also had some Trackspot lights sitting on the floor. Because the hazer wasn’t working they were pretty much useless, so I positioned two of them to point into the ends of truss that didn’t have blue lights. The Trackspots have a dozen or so colors built in, so it was possible to change the color of the center truss.
Rumor has it we have some small LED color-changing fixtures on order…those should be great fun as truss warmers!
April 22, 2007: The importance of haze
If you are not “into” lighting, then you may not have paid any attention to the beams of light that seem to descend from the lighting fixtures towards the stage. There’s nothing special about the lights –the beams are produced when the light is reflected from millions of tiny drops of haze. Haze is produced by a machine that’s located above the stage behind the teaser (upper curtain). Haze is distinct from “fog.” A fog machine produces clouds of visible, dense, rolling fog, while haze is supposed to hang unobtrusively in the air until it’s hit with a light beam. Ideally, you would never see the haze being produced, but because of the location of our hazer, it sometimes looks more like fog when it gets blown around by the air handlers. The reason I’m writing about haze this week is because on April 22 our haze machine was out of commission. Look at the photos from this week and compare them to previous weeks. The haze adds color and depth to the stage.
I’m excited that we’re finally adding color to the front of the stage. For Easter, we added three pars near the front on each side of the stage, with blue gels. They were a critical part of achieving this look:

Why the people are blurry
This is a simple post to explain why the people are usually blurry inmy lighting photographs. As an illustration, I took three photos of a speaker on stage, using different exposure times. An exposure time of 1/40 second produces a sharp speaker, but an overally ugly picture because of the noise in the image. Look at the graininess that is visible in the full-size image.
Exposure time 1/15 second:
Exposure time 1/5 second:
At 1/5 second the noise is gone, but now the exposure is so long that the speaker moves during the exposure, producing the “halo” effect. Since my goal in taking these picture is to showcase the lighting, I use a longer exposure to capture the darker parts of the image, and I live with the fuzzy people. Another option is to get a more expensive camera with a more sensitive sensor and a broader range of apertures (my camera only supports two).
April 1, 2007 Lighting for solo vocalists
This weekend, two songs started with a solo vocalist. I used the front lights to highlight the solos and provide a transition when the rest of the singers and the band joined in.
In the following song, the female vocalist at stage left leads the song, so I highlighted her for the first look by dimming the front lights on the rest of the band and singers.
I then brought up front lights on the other singers and band members.
I did the same thing for this song, but with a different lead vocalist.
And three more songs…
We did one cool thing that I didn’t photograph. We have six pars on the ceiling throughout the auditorium that light the walls. With blue gels, we used them as “house lights” while communion was being served.
Example: using an extractor class in Boost.Python
The documentation for the Boost.Python extractor class is not terribly enlightening for a new user. The examples given in the tutorial are code fragments, and it’s never clear exactly what the context is or what they are supposed to accomplish. That’s a shame, because the extractor classes are really cool and easy to use, so people should use them! Here is a Boost Python extractor example that should make things clear.