No, this isn’t the sequel to the movie “The Castle of Fu Manchu”. It’s a very interesting bit of computer science that deals with the construction of interpreters, compilers, and specializers. I’m dashing out the door with the family this morning, but check it out, courtesy of the “A Neighborhood of Infinity” blog. Unlike most descriptions, this one is fairly easy to understand, although it gives very few hints on how to actually construct the various bits needed. But hey, that’s what a computer science degree is for.

A Neighborhood of Infinity: The Three Projections of Doctor Futamura

Addendum: I was dashing out the door when I read this, but I should expand. Neighborhood of Infinity is the blog of Dan Piponi, a very, very, very clever guy. I don’t consider myself a slouch, but I doubt I’ll live long enough to understand all the stuff he’s written about on his webpage and blog. Great, great stuff. He’s one of the primary reasons that I keep trying to move Haskell to the top of my list of things to learn about, as his writing has given me glimpses into a type of programming beyond which I normally can achieve. Inspiring stuff.

Last year, I noticed that Google had changed their search page to a Sherlock Holmes inspired theme in honor of Sir Arthur Conan Doyle’s birthday. This year, I see that they have chosen to honor Mary Cassatt instead. Well, fine, happy birthday to all, even to Naomi Campbell. But I’ll be listening to some of my favorite Sherlock Holmes stories on my iPod (if you don’t have ’em, try clicking on the first link above, and it will tell you how to get ’em).

Earlier, I blogged about the historic book available from Google Books called Gould’s The Game of Draughts. While surveying a few problems, I noticed that my play was significantly different, and included a number of different outcomes for a couple of tested positions. So, I decided to use the newly added 8 piece Cake endgame database (thanks Martin, for releasing the code and the databases) and see if there were any mistakes I could find. Mind you: these are mistakes which the database points out Immediately, it doesn’t actually point out mistakes in play that require search. I found 47 errors, which for fun, I’ll list below.

I think I am going to (for fun) systematically work through these, and document the improved lines.

Addendum: I seem to have a bug in my code. The list wasn’t correct. I’ll replace it when I verify the results.

Addendum²: Here’s my list of 28 mistakes. I think it’s right, but it might not be, I’m still confused by some of the database issues.

916 : Gould’s Problems #30 is actually a loss for white
986 : Gould’s Problems #97 is actually a draw
1019 : Gould’s Problems #130 is actually a loss for red
1023 : Gould’s Problems #134 is actually a loss for red
1025 : Gould’s Problems #136 is actually a draw
1033 : Gould’s Problems #144 is actually a draw
1086 : Gould’s Problems #197 is actually a loss for red
1094 : Gould’s Problems #205 is actually a draw
1107 : Gould’s Problems #218 is actually a draw
1108 : Gould’s Problems #219 is actually a draw
1171 : Gould’s Problems #281 is actually a draw
1404 : Gould’s Problems #516 is actually a loss for white
1658 : Gould’s Problems #767 is actually a loss for red
1660 : Gould’s Problems #769 is actually a draw
1668 : Gould’s Problems #777 is actually a win for red
1677 : Gould’s Problems #786 is actually a loss for white
1679 : Gould’s Problems #788 is actually a draw
1694 : Gould’s Problems #803 is actually a loss for red
1770 : Gould’s Problems #879 is actually a draw
1774 : Gould’s Problems #883 is actually a draw
1775 : Gould’s Problems #884 is actually a loss for white
1817 : Gould’s Problems #924 is actually a loss for red
1821 : Gould’s Problems #928 is actually a win for red
1902 : Gould’s Problems #1009 is actually a loss for white
1923 : Gould’s Problems #1030 is actually a win for red
1930 : Gould’s Problems #1037 is actually a draw
1958 : Gould’s Problems #1065 is actually a loss for white
1972 : Gould’s Problems #1079 is actually a loss for white

Addendum³: Check out this position from the list above with nine pieces:

The database code sees this as a draw, in spite of the fact that it only has up to eight pieces, because the capture resolution code removes one capture from the game before it does any database lookups.

I’ve been C programming for… (quick arithmetic) roughly 25 years now, and yet, there are still things to learn. For instance, I decided to move my code for Milhouse back from my AMD64 Linux box to my Macbook for a little “mobile hacking” over the next week. I quickly found that unlike gcc on the Linux box, gcc on this Mac still thought that “long” variables were 32 bit. Various counters in Milhouse are 64 bit values, as are the hash values that are used in the transposition table, and I quickly found out that all the places where I previously used “%ld” as a format string had to be changed to “%lld”. Grumble!

You see, here’s the annoying thing about C: you know that shorts can hold char values, and ints can hold shorts, and longs can hold ints, but you actually don’t know how many bits any of these have without peeking using sizeof. Luckily, the C standard requires an include file sys/types.h which has typedefs which include types of various sizes, so if you really want a 32 bit unsigned int, you can use the type uint32_t and be reasonably sure that it will work. Such was the state of my knowledge a couple of days ago.

But here’s the thing: I didn’t know any way to generate the right format string for a particular size of data value. On my AMD box, %ld is used for 64 bit values. On my mac, I need to use %lld. Grumble!

But apparently this was all thought of by the C99 standards committee. They created an include file called inttypes.h which includes defines which tell you what format is needed. For example: PRIu64 is the code for a 64 bit unsigned integer value. On my mac, it expands to "ll" "u", which the C preprocessor is nice enough to cat together. Therefore, to print such a value, you need a line like:

printf("%" PRIu64 "\n", sixtyfourbitvalue) ;

Sure, it’s ugly. You think they would at least include the % in the macro. But, it does work. I’m tidying up all my code to play by these nice rules.

[Event "More Sparring"]
[Date "2009-05-12"]
[Black "Simple Checkers"]
[White "Milhouse"]
[Result "0-1"]
1. 11-15 22-17 2. 9-13 17-14 3. 10x17 21x14 4. 7-10 14x7 5. 3x10 26-22 6. 6-9 23-18 7. 
10-14 18x11 8. 8x15 27-23 9. 4-8 23-18 10. 14x23 22-17 11. 13x22 25x4 12. 2-7 31-26 13. 1-6 
26x19 14. 7-11 4-8 15. 11-16 19-15 16. 9-13 8-11 17. 16-19 15-10 18. 6x15 11x18 19. 13-17 
24x15 20. 5-9 29-25 21. 17-21 28-24 22. 9-13 18-22 23. 12-16 15-10 24. 16-20 32-27 25. 
13-17 22x13 *

To all the moms out there in the world, thanks for all the wonderful things you do for all your children. And while I’m at it, happy birthday to me!

Alan, VK2ZAY, has a really nice blog with all sorts of interesting experiments. Today’s fun installment was a radiation detector that’s just about as simple as can be imagined, ao aimple and inexpensive that I am pondering the possibility of using a similar circuit as part of a sensor for a balloon launch. Very cool:

Alan Yates’ Laboratory – Ionisation Chamber Radiation Detector

It also made me realize that I didn’t understand how a common smoke detector (which I know includes Americium, but little else) actually worked. Wikipedia of course comes to the rescue, and tells me the basic idea.

I’ve been interested in 3D printing for quite some time. It’s a technology that seems poised for a break through. One of the things that it really needs is an inexpensive medium to create objects from. I’ve seen printers which use sugar which is carmelized by hot air, corn starch which is glued together, and various plastics. This link on the Make blog links to an article which includes a recipe (awesome) for a ceramic medium for 3D printing, which is very inexpensive. I have no immediate use for this information, but who knows what the future may be.

Make: Online : 3D printing goes back to the Stone Age.

I’m testing WSPR reception using some new hardware. It’ll return to active duty soon.

There, did I get your attention?

So yesterday was a really warm day, the first of the new year really. According to weather.com, temperatures in Emeryville reached a high of 89 degrees. Pretty darned nice. In fact, actually hot.

After work, I hopped into my car (around 6:30PM, well past the heat of the day) and decided to grab my hands free headset and give a call to my buddy Jeff. As I was pulling out of the parking lot, I heard a rather loud POP and found myself covered in lemon lime soda. Witness:

This guy had been sitting in my back seat for a couple of months, but apparently the temperature combined with the mechanics of jostling around was too much for it. I amusedly told Jeff about the explosion (it wasn’t a lot of soda, since it was one of those ridiculous half cans) and we proceeded to chat.

Of course, he was busy grilling himself some burgers and eventually had to sit down and have his dinner. I jokingly told him that if he hung up on me, he’d never know what was next to explode in my car.

And of course, a few minutes after hanging up:

I’ve now gone through my car to make sure all soda cans have been removed.

One of the Knights mentioned that Bill was now visible on WSPR. Presumably, this means his DSB beacon is actually alive. Here’s a link to his spots as reported on the WSPR net. Not bad!

Bill’s WSPR Spots

And I thought I was nerdy for having the Dr. Who theme be my ringtone…

httpv://www.youtube.com/watch?v=0KRja415Iwk

This is just an interesting little aside. Over the past couple of days, construction of the new building here at Pixar Animation Studios has begun in earnest, which means that we have pile drivers operating a couple hundred feet from my office. Strangely, my office appears to be very close to a resonant node for the building, and my monitors were shaking back and forth. Bleh.

One of my fellow Pixarians decided to put here iPhone to a good use, by recording the ground shaking. Check it out.