« October 2006 | Main | December 2006 »

November 15, 2006

Fix your Mac

If there is one downside to owning Apple hardware it's the cost of repairs. I've just come across iFixit, which has excellent do-it-yourself guides to replacing all the major components in your Mac. Yay!

Posted by Noel at 09:00 AM | Comments (1)

November 13, 2006

New Software, For You!

We released two bits of code a little while ago, both at PLaneT:

• A new minor version of SchemeUnit that adds a check-= form for comparing numbers within a specified tolerance, and fixes a few bugs.
• A new add-on to SchemeUnit, called Benchmark that, as the name suggests, adds forms for benchmarking code.

A simple example of using the Benchmark library:

Suppose you were benchmarking some functions that worked on vectors of numbers, and you wanted to see if the SRFI-43 vector-map was faster than writing a loop by hand. You can test this assumption using the check-faster form:

(module test mzscheme

  (require
   (lib "vector-lib.ss" "srfi" "43")
   (planet "test.ss" ("schematics" "schemeunit.plt" 2))
   (planet "text-ui.ss" ("schematics" "schemeunit.plt" 2))
   (planet "benchmark.ss" ("schematics" "benchmark.plt" 1)))

  (define big-vector
    (vector-unfold
     (lambda (i x) (values i x))
     1000
     0))

  (define check-map
    (test-case
     "Check vector-map is faster than hand-written loop"
     (check-faster
      (lambda ()
        (vector-map - big-vector))
      (lambda ()
        (let loop ([vec (make-vector 1000)]
                   [idx 1000])
          (if (zero? idx)
              vec
              (begin
                (let ([idx (sub1 idx)])
                  (vector-set! vec idx (- (vector-ref big-vector idx)))
                  (loop vec idx)))))))))

  (test/text-ui check-map)
  )

On my computer the hand-written loop is a fraction faster than vector-map, so if performance is essential than the loop is to be preferred.

By formalising assumptions as tests you automatically get notified when implementation changes render them invalid. So if changes in the JIT compiler made vector-map faster this test would fail and I would know to rewrite my performance critical code.

Often it isn't convenient to keep two versions of a function around, perhaps because the implementation depends on many modules. In this case it is useful to benchmark the implementation against its past performance. You can do this by creating a benchmark-case where you would otherwise create a test-case. An example is in order: Say you have a complicated function foo and you want to ensure your optimisations are making it faster. Then you simply write:

(benchmark-case
 "foo benchmark 1"
 (foo some-big-input))

The Benchmark library automatically saves performance data and fails this test if foo becomes slower. The name of the test case is important, as this is what the Benchmark library uses to find historical data.

That's it. As you can see the Benchmark library is quite simple, but I have found it very useful when optimising code. I hope you do as well!

Posted by Noel at 02:05 PM | Comments (0)

November 06, 2006

A Farewell to Alms

Tyler Cowen writes

The book is not yet out, but it is the best of its kind since Guns, Germs, and Steel.

The book in question is A Farewell to Alms, and 4 pages into the draft I'm hooked.

cp>Till a few days ago a full PDF draft was available online. This has been replaced with a few PDFs of individual chapters. The author tells me this was done at the request of the publisher, and he intends to put the first eight chapters online.

Posted by Noel at 05:56 PM | Comments (0)

Voting Systems: Theory Meets Practice

Suresh posts on tamper-proof voting systems. Why do you care? Apart from the application to democratic government, it's a problem that all Internet companies that aggregate user behaviour (for example, social networking sites) face. Be sure to read the comments.

I love applying theory to real-world problems, if only because it justifies my over-education :)

Posted by Noel at 10:12 AM | Comments (0)

Does engineering/math/science education in suck?

Kathy Sierra asks why does engineering/math/science education in the US suck? Nice of her to limit that to the US. I guess we're ok here in the UK. “Education sucks” is a meme that has a lot of mileage. We've posted along these lines before. I'm willing to accept that the average educational experience is only average, but so is the average student. I think the passionate will always be disappointed with those who don't share their passion. I know I have been in my time at University, but on the flip side I've been a pretty poor student in some classes that I found boring. However, as an engineering/science graduate I must ask “where's the evidence” in response to this claim. There is definitely something to be said about the issues of teaching and teaching standards, but I find this post too simplistic.

Posted by Noel at 08:03 AM | Comments (0)

November 05, 2006

Firefox 2.0 Find Again

Incremental search is one great feature in the Firefox 1.x series. Press /, or simply start typing, and Firefox searches as you type. Firefox 2.0 has the same feature, except it is missing the “Find Next” and “Find Previous” buttons. Here are three ways you can get this functionality back:

1. Press F3 to find next, and Shift-F3 to find previous
2. Start your search by pressing Control-F (Command-F on OS X).
3. Muck around with your Firefox configuration to turn on the buttons

Mozilla call this feature Find As You Type. Follow that link and you'll find a few more usage tips.

Posted by Noel at 05:31 PM | Comments (0)

November 04, 2006

Network West Midlands: Go In, Stay In, Tune In

Network West Midlands

draws design inspiration from HM Government.

Posted by Noel at 08:22 PM | Comments (0)

November 02, 2006

Air Taxis, Constraint Solving, and Computing Power

This week's In Business covered the fascinating industry of air taxis. An air taxi is exactly what the name suggests: an airplane that takes you where you want to go, when you want to go. Now clearly the infrastructure required for air taxis is a bit more expensive than that for a normal taxi, so answering the question “how do you make money?” is quite involved. The best answer was provided by DayJet. Essentially they run a massive constraint solving system, juggling aircraft, airports, and travellers, and they charge you by how difficult you make the constraints. If you demand to travel in a small window of time it is going to be difficult for them to find other passengers for the plane, so you pay more. If you don't particularly care when you travel, or how long the journey takes, then they might be able to fill the plane, or make a detour to pick up other customers.  Hence you pay less.  This is an elegant solution to a difficult problem, and I'm struck that this is the type of solution, indeed the type of industry, that can only exist because of information technology. Even five years ago I doubt computer power was cheap enough to make this feasible.

Now just don't get me started about the environmental problems air taxis would cause. That's a problem there is no easy or elegant solution for.

Posted by Noel at 09:21 PM | Comments (0)