Avian’s Blog

Yesterday at Zemanta headquarters, there was a discussion about the validity of some statistics. It went something like this:

(brought to you by the Creative Commons NC-SA 2.5 license of the original xkcd comic)

I just saw this interesting tooltip when I moved the mouse over the System menu.

I'll be spending the next week in Alexandria, at this year's Wikimania. I was at the first Wikimania in Frankfurt three years ago and it has been a pleasant experience (if I forget the desperate search for working wireless, but I guess that is mandatory at such events).

I wonder how much the conference has grown in these years. I remember Frankfurt as a nice, relatively small scale event. Halls were full of discussions about Wikipedia trivia and inside jokes (a lot of which I didn't get at that time) and Jimmy Wales was a kind of a celebrity everyone wanted to meet in person. I also recall the bad opinion I got about Richard Stallman from the way he answered questions at that conference. My impressions are still available at Cyberpipe's webpage by the way (Slovene text over English comment spam: day 1, day 2, day 3)

This year I'll be giving a 20 minute talk about Wikitag, the automatic link generation system I developed for Zemanta and a related lightning talk about an open-source MediaWiki dump preprocessor Wikiprep. So, if you're interested in the magic behind Zemanta's suggestion service and you'll be on that continent next week, you're kindly invited.

Back in 2004 I did some research into analysis of signals recorded by an instrumented tracer (English abstract). The problem I was working on involved this instrument in form of a metal sphere that you put into a river and let the water carry it just like a normal stone cobble. The tracer then measures and records the acceleration profiles of impacts with bedrock and other stones. The purpose is that from these measurements you can get some idea of what material there is in the river bed and what kind of erosion is going on there.

What I basically did is that I developed a pretty simple method of automatically recognizing the type of material that is hitting a tracer by looking at the output of three accelerometers.

To my surprise, dr. Matjaž Mikoš, one of my mentors, contacted me a few days ago with news that our work has been presented as a poster at the European Geosciences Union and the he held in invited talk about the topic at SDHR (Slovenian Association of Hydraulic Research).

(Click on the image for the full poster)

I'm really glad that the work I did turned out to be that useful.

Update: I've fixed the image so that now you can actually read the text on the poster. Thanks to Andraž for notifying me about that.

Today I spent a couple of hours hunting down a bug in some of Zemanta's C++ code. I won't bore you with details, but I did learn something interesting about the way GCC works.

In essence the bug was due to a broken implementation of string comparison. Like this for example:

int cmp_strings(const char *x, const char *y)
{
	return x == y;
}

Now, if you know some basics you should see right away that this won't compare strings at all. What it will do is that it will compare the memory locations at which the strings are stored. But that's not the interesting part.

The interesting part is that a function like this had a couple of unit tests and they all passed with flying colors, while in real usage it broke horribly (as it should).

How was this possible? Consider the following program using the function above:

int main()
{
	printf("%d\n", cmp_strings("en", "en"));
	printf("%d\n", cmp_strings("sl", "en"));
	return 0;
}

Can you say what the output looks like without compiling it first?

Interestingly, at the first glance the output of this program supports the (wrong) theory that cmp_strings does in fact compare string content (and that's why the unit tests I mentioned passed).

What is really happening is that GCC is optimizing memory usage of the program and is merging equal constant strings. There is no use in storing the same constant "en" string three times in three different locations when one copy will do just fine (they are constant after all). So cmp_strings will work correctly for constant strings, but not for variable ones.

Oh, and -fno-merge-constants doesn't help with this, since it only affects merging of identical constants over multiple compilation units (on GCC 4.2.3 at least). In fact I see no way of disabling this optimization so that I could quickly check if any other code is also broken in this way.

Today Slovenian highways switched from a modern contactless toll collection system called ABC to a piece of paper that you stick on your windshield and has to be manually checked by an army of inspectors.

ABC in all its tuned microstrip glory

ABC was a prepaid system where the amount you paid was proportional to the usage of the highways (well, to some approximation). The new sticky paper costs the same, no matter how much you actually drive. What is even funnier is that the speed limit through the tollgate is now 30 km/h while with ABC it was 40 km/h (and with the old system something actually had to be done while you drove through).

Welcome to back to 1950s.

This step back does have some bright sides though. One is increased privacy. Since the old system registered your tag on every entry and exit of the highway, it was possible for it to be used to track vehicles. An interesting step in the time when governments want to track citizensterrorists on every occasion. On the other hand you can already hear talks about Slovenia being the first country in Europe to adopt a new electronic system using satellite tracking, so this may not last long.

For people commuting daily by car like me the stickies also bring yearly toll expenses down to one tenth of what they were with ABC. Great for us, not so much for tourists just passing through our country and certainly not for Slovenian railways. And then people wonder why our public transport is in such a sorry state.

Back in April I posted a question about the definition of the coupling coefficient. Well, I got the answer almost immediately via email from A. B., who confirmed my suspicions of the derivation given in the book and explained to me the correct way of defining k. Now I finally got around to writing a follow up post about this (and I can also at last clear all those books from my desk).

So, the correct way of arriving at the coupling coefficient and the formula for mutual inductance would go like this (using previous flux and current designations):

Mutual inductance between coils 1 and 2 is by definition:

Due to principle of reciprocity, we can reverse the roles of coils:

Now you can define the coupling coefficient k as:

From this definition you can see that the value of k only depends on the values of mutual inductance and self inductances of both coils, which themselves only depend on the geometry (i. e. shapes and positions of coils).

Finally, from this equation it also follows that:

So what is wrong with the derivation in the book? Basically it's this single assumption, that:

and

One clear case where this equation doesn't hold is when coils 1 and 2 have the same cross-sections and are placed one on top of another (so that both magnetic fluxes through their cross-sections are equal). By varying the number of turns of both coils, you can set an arbitrary ratio between Φ₂₁ and Φ₁₁.

This example shows that the ratio between both fluxes depends on self inductance of both coils. And indeed the correct equation that follows from the definition of k is:

So, thanks again to the anonymous reader for clearing this up.

Today I had the opportunity to play with an USB HSDPA modem. This is the latest generation of the packet data connection through a cellular network which can in theory get you a 7.2 MB/s downlink. You get it in a soup can in combination with some subscription plans at Mobitel.

The modem itself obviously has several names, depending on who you trust:

• The advertisement says it's "GlobeSurfer iCON 7.2",
• the front side of the modem says "Option",
• the back side says "Qualcomm 3G CDMA model GI0205"
• and finally lsusb says it's "Globetrotter HSDPA Modem".

It certainly gives you the warm feeling that various marketing departments are working together to reduce the confusion here. Just for the record, USB ID is 0af0:6911.

Anyway, the thing works without problems on Linux. It is used as a standard serial modem with a PPP connection, except that you need to give it some special AT commands first.

When I plugged the modem in I got three USB serial devices: /dev/ttyS0, ttyS1 and ttyS2. First two didn't respond to any AT commands, while ttyS2 responded with the usual OKs. I didn't need to do any extra steps to switch the hardware from the simulated CD mode to modem mode as some people reported.

The actual configs I used are here. I don't know why, but sometimes two attempts are necessary to get a connection.

# pppd configuration (e.g. /etc/ppp/peers/qualcomm)

# Change if using with some other mobile provider
user "mobitel"

connect "/usr/sbin/chat -v -f /etc/chatscripts/qualcomm
/dev/ttyUSB2
115200

noipdefault
usepeerdns
defaultroute

noauth
crtscts
passive
modem
idle 7200

# No support for compression
noccp
novj

# chat script (e.g. /etc/chatscripts/qualcomm)
ABORT		BUSY
ABORT		VOICE
ABORT		"NO CARRIER"
ABORT		"NO DIALTONE"
ABORT		"NO DIAL TONE"
TIMEOUT		5
""		ATZ
OK 		ATE1
OK		AT+CPIN?
# insert your PIN here
READY\r\n\r\nOK-AT+CPIN=your_pin_here-OK	AT
OK		AT+CGDCONT=1,"IP","internet","0.0.0.0",0,0
OK		AT+CGDATA="PPP",1
CONNECT   	""

You also need to enter a proper username and password into chap-secrets file (PAP authentication isn't supported). For Mobitel this pair works:

# Secrets for authentication using CHAP
# client	server	secret			IP addresses

mobitel		*	internet		*

NewScientist writes about a paper that explores the possibility of using tequila as a precursor material for growing thin diamond films by chemical vapor deposition.

The Mexican authors have written this wonderful introduction, with half of the text explaining state of the art in CVD and other half explaining state of the art in tequila production.

They claim that tequila contains just the right proportion of carbon, oxygen and hydrogen for carbon atoms to bond into a nano-scale diamond coating on a silicon and steel substrate. Such diamond films are a target of research into alternative semiconducting substrates for integrated circuits.

It's a funny discovery and I would really like to know the circumstances that led to the researchers pouring alcoholic beverages into their precious equipment. From my limited experience owners of such machinery are pretty paranoid about contaminating them with unknown substances and I can't imagine someone using a chemical that isn't semiconductor grade. On the other hand they used only some 1 dl of the liquor for the experiment, so the rest of the bottle's content may have helped them with that.

I'm a bit skeptical about the repeatability of their experiment thought. I doubt that all Orendain brand Tequilas blanco have the same C-H-O atomic relationships to two significant figures (or they must use some pretty impressive distilleries).

Last week Zemanta released Re-blog - a feature that allows easy and proper quotation by clicking on a small icon on the bottom of a blog post.

I found the previous Zemanta icon visually annoying and did not want to include it in posts on my blog. However, in the spirit of "don't just complain, but suggest a solution", I started up GIMP and came up with these in an hour or so:

Compare this to the old icon:

When I got back from Tenerife I was surprised to learn that my "Traditional" version of the icon is now one of the icons you can choose in the preferences page.