The first fully functional version of socelect.org is now published, up and running.
It uses an algorithm invented by Andrew Davenport in the early oughts (about fifteen years ago) to aggregate multiple preferences into a ranking that accurately represents the preferences of the majority. To quote the site, “Find alternatives that satisfy most.”
The series that follows is a personal story about the development of socelect.
What is preference aggregation?
The following will help with some of the jargon necessarily used here.
partial order is just an ordering of things, one before the other, in which some things are equal. This is opposed to a full order in which everything comes before or after every other. You can say “broccoli before spinach before brussels sprouts before cabbage.” That is a full ordering. You can say “broccoli before spinach and brussels sprouts, and after those cabbage.” That is a partial ordering because, while you prefer broccoli to spinach and brussels sprouts, you don’t prefer either of spinach or brussels sprouts before the other. You do prefer both over cabbage.
preference aggregation is taking some number of individual preferences for broccoli, brussels sprouts, spinach and cabbage, and putting them together to decide which to serve as a vegetable with dinner. (Steak and potatoes all the way for the rest, and chocolate cake for desert.) Although you’re choosing one vegetable to serve, everyone knows that their second choice is as meaningful as the first, particularly if they don’t want to eat cabbage.
In another scenario you might be choosing top three, or ranking everything. The Davenport algorithm provides a partial order ranking for all of the alternatives.
When attempting to measure group preference given more than two alternatives, it is well established that asking each person to choose one, and then selecting that which gains more votes than the others (plurality), is likely to result in a selection that the majority of the group dislikes. There are many alternative systems that are better. I believe that preference aggregation is the best.
Having each individual rank the alternatives gives full information about which alternatives they prefer over others (although it doesn’t tell how much). With that, we can truly select alternatives that satisfy the most.
To make it happen required these projects:
- A user interface for specifying partial orders.
- An implementation of the Davenport algorithm.
- The web site built around a database system.
It made most sense to implement the Davenport algorithm in the C language because the C language has great compilers that make it very fast for most computers, and it needs to be very fast. Others might have chosen C++. Never did like it.
The combination of C and Ruby meant one more project:
- A Ruby extension library to use the C implementation of the Davenport algorithm with the Ruby code of the web site.
Some of the projects have dependencies on others. The web site depends upon the user interface. The Ruby extension depends on the Davenport implementation. After that, I had two criteria:
- interest and motivation
- risk mitigation
It makes sense to do the riskiest parts first, because failing these all of the other work is for naught. To me the implementation of the Davenport algorithm was the riskiest. It’s complex, and the C language can punish little mistakes with hard to solve problems.
The posts that follow track development of the four projects. Hopefully, they will contain insights about how to develop software, what it’s like, and lessons learned. They will chronicle a journey, some of the choices, important crossroads, mistakes, and difficult passages.
Ride along with me a spell. Let’s see what we’ll discover. Meantime, try out socelect.org. Let me know what you think!