Algorithm Blogs

Over the last few weeks, I’ve been lightly involved in work on open knesset.
Mostly I’ve been helping two of the main developers, Benny and Ofri, and joining the discussions on the discussion group.

(For the non-Israelis: the Knesset is Israel’s congress, where laws are passed.)

The website’s mission is to improve Israeli citizens’ involvement in our democracy, and the first step in doing so is giving people more information. Ever wanted to know who keeps his promises? Who voted how? Who never votes? Which Member of Knesset is never present in discussions and votes?

Open Knesset is the place to put this information. If you know a bit of Python & Django, you can join development either on the content harvesting front, or on the front-end front (pun not intended :).

“What about algorithms?” you may ask, or “what does this project has to do with algorithm.co.il?”. Well, there’s also plenty of room for innovation and interesting features. For example, finding the correlation between Members of Knesset that always vote together. Knowing which vote is for which law. Understanding if the vote is for or against that law. Plotting the party graph, and working with it. These are all things that still need to be done. See these graphical examples to see what I’m talking about.

The website is still in its infancy, but it already has lots of content and lots of features. Nevertheless, it still needs more work.
If you’re looking for an open-source project where your work will have great impact, this might just be it.

My friend Yuval whom you might already know from the comments here, apparently composed music for the Python Zen. It made me laugh today, and as it’s been a long day, I thought it’s worth sharing here. Especially as it is Python related.

Following Ned Batchelder’s advice I’ve used pngout to minify the png’s on my startup’s web page.

It took them down from 641,281 bytes to 338,705. This is quite a nice return for the effort of a download and a single command line:

for %i in (*.png) do pngout “%i”

It’s become a fashion of late to write about the effect the Internet had on journalism, and the way people get informed. Usually the discussion revolves around blogs, twitter, how the newspapers are dying, and so on.

I’d like to point out something different that I’ve observed of late.

It started a few weeks ago, with the story of judge Drori. He acquitted a man who ran over a the clerk at the parking lot, because she refused to let him leave without paying, and stood in the way of his car. After reading the story, and the actual court ruling, there was a public outrage. Judge Drori wrote a ruling of about 300 pages, where he explains the acquittal. Many people commented about the ruling itself, its length, the reasons given in it and so on.

The second story is about the farmer Shay Dromi, who was acquitted today of killing. Two years ago, two Bedouin burglers broke into his farm at night, poisoned his dog, and then went about their business of stealing his property. At least they would have had Dromi hadn’t noticed them, confronted them, shot one to death, and wounded the other. This was amid a wave of crime and break-ins at the area, while the police weren’t doing much to stop that wave. As I said, Dromi was acquitted, the ruling was also published, and many people commented on the subject.

Now we can get to the point: usually, acquittals or convictions of the “small” people don’t merit much press. Judge Drori’s ruling probably would not have reached that publicity if he wasn’t up for a seat at the supreme court. Dromi’s story was publicized heavily a few years back, and the Knesset even changed the self-defense law because of this case.
However, the publishing of full-text rulings is new. Except for a case I was personally involved in, I never read court rulings. I don’t really know a lot about law.

Having these two stories published online, and not only in print, allows publishers to link to the full rulings. Newspapers will never come 300 attached pages of dense law text.
Yet online it’s easy as creating a link – and just like that, you have citizens reading rulings, understanding court processes, having opinions, commenting, and getting involved.

I find this amazing, and it makes me optimistic. The times are a-changing.

Python 2.6 and 3.0 are upon us.
I helped a friend set up the new Python environment for research and development, and we thought about constructing a PythonPack: a compilation of packages every home should have lying around.
(more…)

About a month ago the new Ubuntu 8.04 was released and I wanted a clean install. I downloaded an image and burned it to a CD. Just before installing, I tried "check CD for defects" and found a few. Turns out (*) this was because of bad memory - and memtest confirmed it.
So I went to the shop, replaced the bad memory, and also bought two new sticks. I went home to install the new Ubuntu, and after the installation, Firefox crashed. After rebooting back to memtest, I saw this:

Back at the computer shop, they asked me to reproduce the errors. Just firing up the computer and booting directly into memtest didn't seem to do the trick, so I suspected that I had to overwork my computer a bit to reproduce this.

Since I was at the lab, I didn't want to muck around too much.
So I thought, "what's the quickest way to give your CPU a run around the block?"
That's right - a tight loop:

However, this snippet doesn't really play with the memory.

The next simplest thing to do, that also jiggles some ram is the following (and one of my favorites):

I will talk about this peculiar piece of code at a later post.

In any case, this snippet also didn't reproduce the error. It is also quite unwieldy, as it raises a MemoryError after some time. Later at home I tried two more scripts.
The first is a variation on the one above:

I ran a few of those in parallel. However, my Ubuntu machine actually killed the processes running this one by one.

The second is smarter. It allocates some memory and then just copies it around:

After both of these scripts didn't reproduce the problem and it still persisted arbitrarily, I returned the computer to the lab. Turns out that the two replacement sticks and the two new sticks weren't exactly identical, and that was the cause of the problem. So now my memory is well again.

As for the scripts above, I once wrote a similar script at work. I was asked to help with testing some software in some stress testing. The goal was to simulate a heavily used computer. A few lines of Python later and the testing environment was ready.

Footnotes:
(*) - Finding out that it was a memory issue wasn't as easy as it sounds. I didn't think of running memtest. I checked the image on my HD with md5, and the hash didn't match. I downloaded a second image, and again the hash didn't match. I checked twice.
At this point I was really surprised: not only the second check didn't match the published md5, it also didn't match the first check. Some hours and plenty of voodoo later, a friend suggested running memtest, and the culprit was found.

Like many others, I got stuck in front of Rapidshare's captcha. After more than five attempts at reading different letters with kittens and other critters hidden behind them, I was thinking of giving up. Especially because each time I failed I had to wait a half a minute again. However, in one instance I went *back* via my browser, and tried solving the same captcha again. Turns out this works, and I got the file.

I know I could probably have solved it in a smarter fashion, but it wasn't worth the effort.

My lesson:

When someone writes crappy software, their software is probably crappy in more than one way.

This is not the first time I've seen this happen.