For many years I had an idea for an approach to solving rubik's cube. Just recently I found a trivial expository example of my approach. Jaap of course took my idea and ran with it and now has a gallery of quite remarkable correspondences between simple permutation puzzles and archimedean solids. (My contribution was the cuboctahedron.)

Gambling pools with odds

Racetrack betting has a very curious feature: When placing your bet, you don't know what the actual odds are. The current odds are readily available, but those in principle could completely change before the close of betting. An interesting variant would be to allow people to place bets on a horse which were contingent on the odds on that horse being at least a certain value. I haven't worked out whether it would always be possible to set canonical odds for a given set of bets, but I suspect it is. This would be an interesting (and, of interest to casinos, potentially quite popular) variant on normal betting pools.

Memory Allocation

graydon has some commentary on memory allocation. Specifically, he's in favor of explicit 'might be null' status for variable, and strictly tree-structured memory allocation. These are good ideas, but there are many thorny edge cases. For example, with non-nullable variables there's the case of an object's constructor passing 'this' to something which reads a variable which hasn't been set yet, even though it's guaranteed to be set once the constructor finishes. For memory allocation, usually that approach works fine, but there are occasional data structures which require making an exception to work properly, such as a circularly linked list. No single allocation scheme can capture the full generality of practical behavior, so the options are to either make a system which handles the vast majority of cases well (which strict tree-based doesn't quite) or have a system for violating the general rule in special cases.

I've spent quite a bit of time thinking about how to make a type-safe language with the declarative power of C++ (and more) but with the transparency of C. A friend of mine told me that one of my ideas amounts to 'jump tables but no vtables' - If you subclass an object, rather than making the class data structure point to a superclass object, it simply inlines a copy of references to all the methods it inherits from the parent, with overriden methods substituted. This vastly reduces the complexity of method lookups at runtime, both in terms of cycles taken and difficulty of proving correctness. The tradeoff is that in theory there could be an exponential blowup in the size of class objects in memory, but in practice that won't happen. (Well, maybe it will happen for those truly obsessed with OO wankery, but they get what they deserve.)

Advogato Feedback

I get very little feedback from this weblog. I know people read it because every once in a while I post an entry which generates lots of response (for example, the first one on solar thermal energy). Maybe this is because my entries are so obtuse that people aren't sure what to make of them. Or perhaps it's because I've made my email address so difficult to find. I had to do that, unfortunately, due to a deluge of not only spam but non-spam BitTorrent tech support requests. I simply couldn't keep up with them, and now make the assumption that anyone who I really want to hear from will make the effort to find my email address. I hope I don't lose too much important mail this way.

Spam Filtering

Speaking of spam filtering, I've now basically gotten my problem under control with the following filters - anything with 'dsl' or 'cable' in a Received: line but not in the From: goes to /dev/null. Anything with 'unknown' in the Received: line gets chucked. Anything with a locally tacked-on Message-Id: which isn't From: a locally hosted domain goes to /dev/null. And finally, anything which matches any of a very long list of bounce formats or bounce subject lines gets chucked.

I've taken this aggressive approach to spam filtering because even small amounts of spam were making me delete real mail thinking they were spam. Unfortunately people with even slightly dubious mail setups are likely to have their mail to me /dev/nulled now. And of course I never get bounces any more. I hope I don't lose too much important mail this way, but I undoubtedly lose some.