Just about any pie recipe can be easily converted into jar pie. It’s really just a matter of form factor. Prepare a bunch, leave them in the freezer, thaw before use and bake at 375°F for 45 minutes. Couldn’t be simpler.
Alternate ideas: layer on multiple pie flavours, or partition them horizontally with the aid of construction paper. The photo below is cherry on the left, blueberry on the right.
If you need to determine which columns in a database contain a certain type of string, the pseudocode is fairly simple: list all tables in a database, list their columns that are text-oriented, filter those that match some given format. For large tables, this script won’t bother looking at too much.
############################################
# Imports
import MySQLdb
import sys
############################################
# Initialize the database connection
database = MySQLdb.connect(
host = "localhost",
user = "username",
passwd = "password",
db = "database")
cursor = database.cursor();
############################################
# Find all matching columns
cursor.execute("SHOW TABLES")
tables = [table[0] for table in cursor.fetchall()]
for table in tables:
cursor.execute("DESCRIBE %s" % table)
columns = [column for column in cursor.fetchall()]
for column in columns:
if column[1].count("text") or column[1].count("char"):
cursor.execute("SELECT `%s` FROM \
(SELECT `%s` FROM `%s` LIMIT 20000) AS subtable \
WHERE `%s` LIKE %s LIMIT 1" \
% (column[0], column[0], table, column[0], '"%foo%"'))
results = cursor.fetchall()
if results != ():
print "%s.%s -- %s" % (table, column[0], results)
############################################
# Close the database connection
database.close()
Cream the “butter” and mix the rest in slowly, one at a time. When you’re done, you can coat each with melted chocolate (as pictured above), roll them in cinnamon, top them with an almond perhaps. These keep fairly well in the fridge when they’re done, although I’m no chocolatier, so venture with caution.
Back in 2009, Google’s coverage of Canadian streets was limited to major cities.
Seems as though there was an update in the meantime.
The following details Greg Opperman‘s recipe for vegan macaroni and “cheese”. Likely one of the tastiest of dishes I’ve ever had. It’s a touch elaborate, but well worth the effort.
Take the a:visited pseudo-class and use it to determine if the client’s browser has visited a site. Do this en masse with a subset of Alexa’s top 1m websites and you can build up a fairly detailed profile of a visiting brower’s history.
var sites = [
'http://google.com',
'http://facebook.com'
];
$(function(){
for (var i in sites) {
$("#test").html("
<li><a href='"+sites[i]+"'>"+sites[i]+"</a> </li>
");
if ($("#test a").css('color') == "rgb(0, 204, 0)")
$("#test li").appendTo("#visited");
else
$("#test li").appendTo("#not-visited");
}
});The ethics of this technique are questionable, especially if you retain this data and associate it with an email address or a registered user account. The only way I can see to protect against it is to disable JavaScript on all but the few sites you trust.
You could augment it to only send a sampling of 50 sites, respond with an ajax post, then determine which 50 to check next (e.g. if a user has visited a site specific to tech news, poll your next 50 on the most popular tech news sites). This concept is used at What The Internet Knows About You.
This recipe works well both as fondue (while hot) and a soft fudge (while cold).
Polls and elections aren’t the same type of thing. The former asks for descriptive data, the latter for prescriptive preferences. To illustrate the hazards of this common misunderstanding, let’s go over some other ways data can partitioned and the problems that arise from confusing them.
Ordered data has an innate linear ordering, whereas unordered data doesn’t.
When unordered data is confused as ordered data, a relationship is erroneously implied between the items.
When ordered data is confused as unordered, data trends are buried.
With discrete data, there exist two values for which there is no valid value in between, whereas continuous data can always be broken down into more detail.
When discrete data is confused as continuous, inappropriate conclusions can be reached (chances are you have 2.3 thermostats in your house).
When continuous data is confused as discrete, granularity is lost. We can’t tell from the graph below whether there’s a large portion of 0.0km entries, if only odd decimal entries exist (0.1, 0.3, 0.5…), or any other detail hidden by these brackets.
Compound data have multiple values that bear some relation to each other.
Compound data can be misrepresented as multiple simple data axes by ignoring the coupling between the two values, whereby the conditional probabilities are lost. Worse, it can be restricted down to a single simple data axis, whereby relevant data is entirely discarded (e.g. do sampled televisions only exist at certain aspect ratios?).
The difference is subtle, but it’s there. With descriptive data, respondents have no incentive to tactically misrepresent their opinions. With prescriptive preferences, respondents (aka voters) are aware that their response will influence a future that likely affects them and will vote accordingly.
When prescriptive preferences are confused as descriptive data, a few things can happen:
Both confusions are present when Plurality voting is used in lieu of a more expressive ballot, where in voters could express more than just a single binary preference for a single option. Maybe this comes from ignorance of alternative voting methods, technical restrictions from the online voting application used, or seeing everything as a nail when you’re holding a hammer; Take your pick.
When Plurality voting is used to obtain prescriptive preferences, the same type of analytical fallacy is being made as is detailed in the above examples, all of which lead to a poor understanding of the underlying reality the data represents.
Thus far, my implementation of Schulze STV has worked fairly well. The downside I’ve recently run into is in simulating real world multiple winner elections. Take Vancouver’s 2008 municipal election as an example, in which 32 candidates ran for 10 seats. The problem-space we’re looking at consists of 32 choose 10 nodes and (32 choose 10) x 11 edges. For those unfamiliar with binomial coefficients, that’s roughly 64 million nodes and 709 million edges. Exponential runtime is a bitch.
For the purposes of heuristic development, let’s look at Tideman’s A03. It’s a set of 989 ballots to elect 7 winners from 15 candidates. Schulze STV computes the winning set as B/D/E/F/H/K/N by looking at 6435 nodes and 51480 edges. How do we best prune the number of candidates down so as to look at a smaller subset, yet still produce the same winning set in most cases? Well, what’s quickly available? We can easily calculate the sum of all votes, standard deviation, and whatnot.
If we wanted to prune off the least preferred by sum (indicated by larger sums), we’d be cutting off one of a winner Schulze STV would want to elect. Alternatively, let’s look at the number of voters that mark each candidate in first place. If a voter marks two candidates in first place, split their vote between the two.
That heuristic seems great at first as it didn’t accidentally eliminate winning candidates and it reduced the number of nodes to 120, a 98% reduction in problem space size. However, the winning set would now be computed by SchulzeSTV as A/B/D/E/G/L/N, which is significantly different. Furthermore, the heuristic is going to incentivize tactical voting. Sometimes there aren’t any easy shortcuts and the best thing to do is just optimize the implementation.
Some months ago, there was talk in Vancouver about opening up the city’s data. As of yesterday, that data is now widely accessible in open formats at data.vancouver.ca. One such data layer is the bike routes in the city. There’s a lot more and it’ll be fun to see where it leads.