Mike Schaeffer's Blog

Paul Graham solicited comments on his Arc programming language a few years ago. These comments are online, and are very interesting reading. Lots of good comments.

Non-Blogs

• A Comparison Between Erlang and C++ for Implementation of Telecom Applications
• Designing an Authentication System a Dialogue in Four Scenes
• Frontier Kernel
• Graphics Hardware Archives
• LispNYC ErLisp
• Los Alamos From Below Reminiscences 1943-1945, by Richard Feynman
• Making the Jump to tableless design
• Optimizing Search on an 8 Puzzle
• RSS 2.0 and Atom 1.0, Compared
• Sysinternals Freeware - Inside the Native API
• The New C Standard
• The New Guidelines for Writing Spreadsheets
• Time Series in Finance
• Cray Supercomputer FAQ
• Functional PostScript
• Journal of Statistical Software
• Metro Planet - Subway travel information
• NewtonScript Byte Code Specification
• Numerical Recipes Home Page
• Papers about Self and OO Programming
• Puyo's Page - libfov
• SELF and the Origins of NewtonScript
• The Autodesk File
• Undocumented C# Types and Keywords
• Windows A Software Engineering Odyssey
• The Gallery of Old Iron
• world subways

Blogs

• Brad Abrams
• Cockpit Conversation
• Daily Dose of Excel
• Daryll McDade - The High School Guy
• Edward Tufte Ask E.T. forum
• Exorcyst's Padded Cell
• Fabulous Adventures In Coding
• Lambda the Ultimate Programming Languages Weblog
• Land and Hold Short
• Linux Is No Longer Free
• Mike Stall's .NET Debugging Blog
• Mini-Microsoft
• MozillaZine Weblogs
• Planet GNOME
• Planet Lisp
• Quoderat
• Rob Fahrni, at the core
• SQL Server 2005 CLR Integration
• Slava Pestov's Weblog
• Stochastic Keithp
• Surfin' Safari
• The Blog of Death
• Under The Hood - Matt Pietrek
• Wadler's Blog
• Windows Shell-User
• fintanr's weblog
• jeffdav's WebLog
• rentzsch.com tales from the red shed
• simplegeek

Now that I've written a little about why you might want to replace Excel AutoFilter, here's how to actually do it. To frame the discussion, there are two problems to solve:

• Deciding which rows of the input set are part of the result set
• Displaying the result set in a contiguous sequence of spreadsheet rows.

The first problem is easy: add another column alongside the input set with a formula that evaluates to TRUE if the row belongs in the result. This can be any valid Excel formula: it can include complex logic, it can depend on other cells containing control parameters. In my example spreadsheet, this formula is in column H, labeled In Query?:

The tricky bit of the formula-based filter is the second problem: displaying the result set in a contiguous range of rows with no gaps. Each cell that might display part of the result set has to figure out itself what part of the result set to display, if any, and pull the data from the input set. A simple MATCH or LOOKUP can't handle this, since MATCH or LOOKUP can't be told to return the second, third, or nth match. They return the first match, which isn't quite enough for what we're trying to do.

As it turns out, even though having the result set compute a mapping from the input set is quite hard, solving the reverse problem isn't too bad. Having the input set compute the mapping to the result set is easy. Here's how it works, by column:

• Ord. - The row ordinal number of the row in the input set, starting with 1.
• Result Ord. - This column starts at zero, in the row preceeding the first row of the result set, and increments by 1 for each row where In Query? is TRUE. For each row with In Query? of TRUE, this column is the row ordinal number of this row in the result set.... We are almost there.
• Result Rows. - The input row ordinal of each row in the output set. This is done by using MATCH to find the first row for each number in the Result Ord..

Once the Result Rows. column has been calculated, populating the actual result set is just a matter of using INDEX. ISERROR can be called on cells in Result Rows. to identify rows that don't contain values. After all this is said and done, we have a spreadsheet range that contains only a result set, updates like every other range in Excel, and can be used in formulas like every other range. I have a sample spreadsheet that implements a lot of this here.

As rumored, Apple just refreshed the iBook. The other rumor, the one about a new chassis and a widescreen display, did not come true. Between that and Apple's desire not to encroach too much on the PowerBooks, there wasn't much headroom for major upgrades:

• 2-finger trackpad scrolling.
• Sudden motion sensing for the disk. (Is this done by the disk itself with a built in motion sensor or by the motherboard/CPU?)
• Standard Bluetooth
• A minor speed bump: the peak CPU is now a 1.42GHz G4 with a 142MHz bus.

I was hoping for more, but given Apple's total lack of manuvering room in the laptop space, this is an understandable bump. If they upgraded the iBook too much, there'd be little reason to pay extra for the PowerBook. Since they can't upgrade the PowerBook too much (thanks to the stagnant G4) they have a natural cap on the features in the iBook. Thus, Apple is restricted to selling up its five year old laptop with slogans like "a fast 133MHz or 142MHz system bus" (fast? Dell's $500 Inspiron 1200 runs its system bus at 400MHz) and "brilliant 1024 by 768 pixel resolution" (maybe it was brilliant five years ago).

Anyway, I've recently come to have a theory on the limited display resolution of Apple's notebooks. It seems obvious in retrospect, but Apple can't scale up the display resolution since they don't have the CPU or memory bandwidth to support higher resolutions as well as they want. With modern display stacks like Quartz and Quartz Extreme, pushing pixels around is one of the biggest user-visible performance burdens on a modern machine (hence, "the snappy"). While a GPU can help, there's no getting around the fact that if they doubled the resolution, they'd double the number of bytes their system has to process to render the same sized desktop on the screen. Given that Apple's best G4's have less than half the main memory bandwidth of the lowest end Centrinos, there's no wonder Apple's not chomping on the bit to eat up more of their bus.

Since Apple's first wave of Centrino laptops should bring fixes for all of this, the computing community has some pretty amazing hardware to look forwards to in a year or so.