Resolver Spreadsheet = Awesome (ish)

Here are some reasons why Resolver Spreadsheet is awesome:

1. It produces Python code. There is no particular reason why I couldn't virtually cut-and-paste something from the spreadsheet as an algorithm in my application. Vice versa, there is no reason I couldn't "prove" an algorithm to a co-worker or supervisor by setting up some sample runs and graphing them.

2. It produces Python code. You can edit it to change the semantics. If you like coding, you can do it!

Things that are not as awesome:

1. It only runs on Windows

2. There's a 31 day evaluation. I understand why, but I still find evaluation periods annoying and too short. If I could have a 6-month evaluation period, then I'd be happy.

py3k fail

Okay, it's not py3k that's broken. It's just that I can't load jpgs (I think) because I can't use Pil to create a TkSomething graphics canvas (at least that's how it goes in the tutorial). Which means I can't try out what I wanted to try out using py3k. Hum.

So I've reconfigured the project to Py26. It's a bit disappointing not to be able to use the latest version of my favourite language, but at least I can use the most exciting language features in Py26.

-T

Really Powerful AI: how close is YOUR system?

I read a lot about AI. Many people think AI is, one day, possibly soon, going to achieve a level of competency such that it will revolutionise the planet and destabilise humanity as the only intelligent force. Some people point to a number of identifiable trends in computing, usually trends in computing power, and claim this indicates a progression towards that stage.

Some such people are crackpots, while others are insightful individuals with the knowledge and experience that they should know what they are talking about -- certainly well enough to give a valid and sensible opinion.

However, I suspect that many people aren't directly working on a system which demonstrates such capability or promise.

So here's my question to anyone working in AI (or any related area). How close is the system that you personally work on, right now, to demonstrating the kind of ability which would contribute significantly towards an independent, thinking machine?

Cheers,
-T

A few days of WingIDE; a few years of Eclipse

I thought I would just quickly blog about my experience giving Wing IDE a fair trial, using it exclusively to fix one particular bug in my system. The short version: it's okay. It needs a visual diff.

Okay, so now for the long version. My application is a hybrid Python/C application, with my particular turf being almost exclusively in the Python code. The team has basically adopted Eclipse + PyDev as a kind of default environment, but it's not proscriptive. Eclipse works, there's no doubt about it. It supports pretty much the workflow I want, does a reasonable job of editing, and a reasonable job of communicating with our SVN repository. It's flexible, so I can do C work in it, hook into our ant targets, change the repository and manage multiple repositories. It's popular, so there is a wealth of information on teh internets. On the downside, I find that it's slow, the code folding is flaky (try folding a file, then editing just one method), prone to crashes.

I've long known that Wing IDE exists, and for extra kudos it's written in Python. It seems to be a genuine competitor, and I thought I'd take it for a spin.

The first thing I had to get used to was how it treats projects. It's probably better actually, but different. It creates project files, in which it stores (apparently) a list of files and directories which are included in the project, plus (presumably) various project settings and configuration files. However, it doesn't actually make your directories for you. You have to do that yourself, either during 'save as', or externally and add them to the project. Well, okay, I'll do that. But what's weird is that there's no capacity (that I could find) to create a project from a code repository. Checking the code out is legwork you have to do yourself, before you create the Wing IDE project. Well, okay...

So I did that. Once the project is created, and the directory added, you can then enable version control for the project and then you finally get some GUI help with your repository. However, this is basically where Wing IDE starts to fall down, and unfortunately it's one of the things I ran into first. So, I'll hold off on criticizing this functionality while I talk about the good points.

It's quick and responsive -- much nicer than Eclipse for doing the job of typing out code. Wing IDE is definitely a nicer editing experience.

Its folding is mostly better. It doesn't randomly unfold while you're typing, which is a big win. Unfortunately (for my tastes) it folds all the methods directly next to eachother so there's no whitespace in between. I don't know if I like that, and I'm definitely not used to it. I prefer a gap so I can start typing in between two methods if I want to. But it's a big win over Eclipse.

Its two-pane view is a little better, and again way faster. Eclipse throws a shoe sometimes when you have the same file open in two panes. It would be neat if I could flow one file into a kind of two-column layout with integrated scrolling, but Eclipse doesn't do that either.

Its search is better and easier to use.

In short, if it weren't for the code repository issues, to which I will now return, I'd much prefer Eclipse. So now for the show-stoppers.

In Eclipse, as soon as I change a file, the project browser clearly marks that I have diverged from the latest repository version. Wing doesn't.

In Eclipse, there is a *great* visual diff tool. Wing IDE will just show you the text diff file.

Eclipse has a built-in repository browser. Wing doesn't.

Anyway, I've run out of time to write down any more thoughts, but that was my experience trying out Wing. It needs to be more capable with code repositories before its functionally at the same level as Eclipse. When it gets there, its speed will put it in first place (for me).

-T

I know I should know how to do this, but...

I'm convinced I have read about why not to do what I'm in the middle of doing. It even feels like a bad idea, but I'm having a brain failure. I'm refactoring. I have a bunch of methods which basically take a list of say 20 similar objects, and merge the similar objects together into new objects. Imagine having a list of 20 numbers. Any numbers within 1 of eachother are 'similar', and should be removed from the list, then their average should be added back to the list. After the process, you might end up with say 4 'representative' numbers.

Okay, now I'm not dealing with numbers, but with complex objects, but the principle is the same. Rather than having like 6 different methods doing basically the same thing, I thought I would implement just *one* mergeList method which would take a pairwise mergeMethod which would then get applied to each pair. Okay, great. So I did that, but now I've realised that I'm going to end up with like 6 different pairwise mergeMethods, when really most of *those* are still pretty similar. In fact, some of them are already in my codebase and are written such that they take a modal switch as an argument.

So now I'm in this situation where I have a generic merge process, but I need to pass modal arguments down to the pairwise merge method. Now for the evil bit.

So, there's this thing called **kwargs. I can write my generic merge process such that it will accept arbitrary keyword arguments, which it can then pass directly to the pairwise merge methods. I could then call my generic method with a pairwise mergeMethod and additional arguments to be passed to that mergeMethod.

Is that evil? Should I be using inheritance instead of modal arguments?

Also, in self-defence, a lot of the constraints here come from dealing with a mature codebase. I'm just trying to work out where I should decide to draw the line and get things Done.

Cheers,
-T

HELP: How do you do Test Driven Design and Prototyping?

Here's where I fall over with TDD. Let's imagine a standard day in my life...

I have some programming problem. I need to build a Thingy to do Stuff. I don't already have anything that does something similar, so I sit down and think about the problem. Along the way, I figure out some approaches to the problem. I don't really believe in BDUF, so mostly I'll just start coding. This kind of exploration is what helps me think, and so I'll build 2 or 3 partial programs before I start to converge on something approaching a solution. Let's dot-point the process so far:

* Problem. Solution?
* Analyse
* Maybe scrawl out a flowchart
* Write a program that for some simple input, generates something like the right output
* Gather up more input data sets, and pump them through the program, extending and fixing as I go
* Reach workable solution

Okay, now a few background points. This isn't how I'd approach a big, team project. But it's how I approach anything I have to solve by myself. I can't just navel-gaze and come up with a great program design, and if we're being honest, I'll bet you can't either. To reach a decent design, I basically need to build 2 or 3 mediocre attempts first.

Now, as far as I understand it, TDD goes hand in hand with unit testing, which is all about small, well-tested, re-usable components. Well, that's great if your fundemental starting point as a designer / developer is the component. But really, it's not. Your starting point is the problem, and the process is one of decomposition and analysis.

Some problems lend themselves to an easy decomposition. A problem which lends itself to a decomposition will immediately make you think "hey, I know how to solve this. If only I had a sorter, a comparison algorithm, some kind of message generator and an input parser this would be a cakewalk!". That kind of problem isn't so hard, and is made out of nice, well-defined objects whose role is well-understood.

Other problems make you think "uh-oh. This one's going to take some coffee, a whiteboard and a fair bit of muttering." Some part of me thinks that the better and more experienced you get, the more new problems should tend to fall into the first category, but in fact I just tend to get given harder and harder problems (or so I think!)

So this is a question to TDD experts. What is the design process that should be followed when confronted with a new problem?

Cheers,
-Tennessee

Call for interest: should I run a python AI competition?

This is just a shoutout to see whether there would be any interest in my running a Python AI competition? There are a few Pythoneers who are into AI that I know of, and it occurred to me that one thing which could be done to serve the community would be to offer a competition.

At this stage, I'm thinking either of challenges which relate to basic AI algorithms, or perhaps building a chatbot/twitterbot. The first challenge should probably have a low barrier to entry, so perhaps I will put together a multi-stage or multi-challenge competition so that people can choose their own level of competition.

Leave a comment with (+0) if you think it would be neat, (+1) if you would take part, (-0) if you're not really in favour, or (-1) if you would sabotage the competition :)

Cheers,
-T