Journal of Complexicism

2008 predictions

Tue, 01 Jan 2008 20:17:07 GMT

It's fun recording your predictions, so that you can have a laugh reading them in the future. I still remember the space conquest predictions of the 20th century culminating in the movie 2001 Space Odyssey.

Unfortunately, we still only have one space station in orbit and no colonies on the Moon, not to mention Mars or the moons of Jupiter. Hal, the on-board computer in 2001, despite tremendous progress in computing, is still beyond the reach of our technology.

At this point I should take a shot at Singularitarians, but it would be like dynamiting fish in the barrel.

The big thing that is lurking just around the corner are new display technologies. Remember the CRT's? I still have one or two in my basement. Some of the technologies that came later are already on the way out--rear-projection TVs and plasma displays. But there are new kids on the block that will compete against the currently dominating LCDs.

OLED, or Organic Light-Emitting Diode. It works similar to LCD, except that the semiconductive organic polymer emits light (as opposed to transmitting light) when voltage is applied to it. That means there's no need for back-lighting. OLED consumes less energy and produces higher contrast image than the LCD. If it can become competitive in price, it will definitely replace the LCD. I've seen a demo of an 11'' OLED TV in the Sony store (U-Village in Seattle) and I'm impressed.

E-Ink, or electronic ink display. The amazing property of the e-ink display is that it looks like paper. It doesn't emit or transmit light--it reflects it. So, unlike other types of displays, it's hard to read in the dark but easy to read in full sun. E-ink consumes very little power and only when the image changes. The image persists evan if you switch off the power.

I played with the Amazon Kindle, which has e-ink display (my "$100" laptop hasn't arrived yet). It's a developing technology, so in some aspects it's still a bit clunky. It's black and white and it takes more than a second to rewrite the screen (and you can see a blink between images). But other than that it's pretty amazing. I love working outdoors, and no other display stands up to the sun's rays.

I don't think e-ink will replace other display technologies, because there will always be a need for light-emitting displays. But for laptops (and electronic books, like the Kindle) it's the best.

Speaking of the Kindle, it still looks and works like a prototype, but its future incarnations will revolutionize the way we interact with (formerly) printed matter. Two technologies contributed to this breakthrough: e-ink display and high-bandwidth internet access.

The Kindle accesses the internet not through Wi-Fi, which is limited to hot spots, but by the cellular phone network, which has much wider coverage. And, incredibly, lifetime internet access is included in the price of the Kindle! Not that, with limited display capabilities, you'll be able to have a full internet-browsing experience on a Kindle. Net access is still mostly limited to downloading purchased books. But you can glimpse what the future has the store.

Maybe not in 2008, but soon enough, I imagine myself owning a laptop with wide-band, always on, cellular internet access; and a fast, color, e-ink display. I can't wait!

Glossary for future readers:

CRT stands for cathode-ray tube. It's a large bulbous vacuum glass jar. It has a little electric heater in the back that emits free electrons that are accelerated by high-voltage electric field towards the front of the tube, which is coated with phosphorescent chemical--a substance that glows when bombarded by electrons.

Rear Projection TV has a projector on a chip in the back, and the image is projected using lenses and mirrors on the semi-transparent screen in the front. The projector on a chip is a clever combination of electronics and micromechanics. It is covered by an array of miniature mirrors--one mirror per pixel--which are toggled by electric fields.

Plasma Display is essentially an array of miniature fluorescent bulbs.

LCD stands for Liquid Cristal Display. Special semi-crystalline liquid is poured between two sheets of glass covered with semi-transparent electrodes. When electric potential is applied to one vertical and one horizontal electrode, liquid crystal becomes transparent at the crossing of the two. A fluorescent bulb is used to back-lit the display and it shines through the transparent openings in the liquid crystal.

Relativistic particle simulation in Java

Sun, 30 Dec 2007 03:36:42 GMT

I finally had some time to rewrite a little Java applet that I wrote some time ago when computers were slower. You can see it here. The original version was just throwing animation frames as fast as possible, which was slow enough back then. However, on modern computer, it become just one big blur.

So I downloaded Eclipse and started working. Eclipse is pretty good considering that it's free. The amazing thing about Java is that it's so easily parseable. Eclipse runs a parser in the background, while you're editing, so you see your errors almost in real time. It's also easy to do various kinds of bulk code modifications and refactoring. This will never happen with C++. I hope, however, that such things will be possible with D.

Another funny thing is that threads are not as alien to Java as they are to C++. My little applet now uses a thread to drive frame refreshing.

Debugging is also easy in Eclipse. My main problem was in gluing the applet to an HTML page. Java runtime just couldn't find the class files. It turned out that I mistakenly created a "package" and that screwed up the naming of classes. Oh, well. Shows you how little Java I know.

I wrote this applet after reading one of the Feynman lectures on physics. There is this incredible relativistic effect that blows your mind when you understand what's going on. Unfortunately, when you just look at the equations, all you see is that they are pretty complicated. Feynman had the unique ability to see through equations. Plus, he was able to communicate what he saw in relatively simple terms.

Nowadays, thanks to computers, we have powerful visualization techniques. I decided to use them to expose the weird reality behind the equations, the reality Feynman was able to see with his "naked brain."

The effect is all encoded in Maxwell's equations. It so happens that even though Maxwell couldn't have anticipated general relativity, his equations have. In fact, the first glimpse of relativity was the discovery of Lorenz transformation as a symmetry group of Maxwell's equations. Lorenz himself didn't fully understand the deeper meaning of his equations, because they were telling something really weird about space and time. It was Einstein who decoded them and came up with his theory of relativity.

So here's the setup--a charged particle generates an electric field. When the particle moves, the field moves with it. When the particle accelerates, the field ripples--electromagnetic waves are generated. Shake the particle hard enough and it will emit light, which is a particular kind of electromagnetic radiation. As I said, all this is encoded in Maxwell's equations. They are just not so easy to solve. For the case of a charged particle, the equations were solved by Lienard and Wiechert (the Lienard-Wiechert potential).

So if you want to see what kind of field is generated by a charged particle moving along an arbitrary trajectory, you just plug the trajectory into the L-W potential and get the result. With a computer, we can calculate the field numerically at any point and moment of time.

That's what I did in my applet. I simulated a charged particle moving along a straight line, back and forth; with a period of uniform movement in the middle, and two bouts of deceleration near the ends. I calculated the electric field generated by this particle at one point in space, at regular time intervals. The result is an animation, which shows how the vector of the electric field tracks the position of the particle, gives the insight into what's happening--something that Feynman described in words only. The mind-blowing part is that the field at the observer's location anticipates the position of the particle as well as the available information permits. Notice that the information cannot travel faster than light, so the observer can only use obsolete information. Based on this information he can calculate where the particle should be "right now." And that's the direction the field vector is pointing at!

Studies

Wed, 19 Dec 2007 22:51:34 GMT

So far I have audited two Computer Science grad courses at the UW. The first one was about Distributed Systems. It turned out to be very useful in my work at Reliable Software, since we have implemented a distributed peer-to-peer version control system.

I was able to position our system among other distributed systems. I saw how other people solved similar problems in various context, and how unique our solution was. Essentially, one could try to build a distributed VCS on top of a distributed database, and it would work, but progress would be hard to make, since distributed transactions could wait for a very long time until they fully commit or abort. We have to be able to make progress based on transactions that haven't committed yet. Very interesting problem, as it turns out. And our solution seems to be very close to optimal.

The second course was completely different. The title, Concepts of Programming Languages , sounds deceptively vague, but it was hard-core CS. One of the side effects of the course was that I learned functional programming in OCaml. There is something very elegant and, at the same time, very unnatural about functional programming. No matter what some people say, recursive thinking is not built into our reptilian brains. You can learn it and even get used to it, but it doesn't just flow naturally from your brain.

But functional programming is not only about recursion. It's also about using functions as first-class objects. Constructing them on the fly, passing them back and forth, storing them in containers, etc.

This course turned out to be very useful in my work on D. I started implementing a thread library in D. The cool thing about the D programming language is that it makes generic programming easy. I would not have been able to implement such a library in C++.

For instance, how do you create a thread? Thread creation has to be parametrized by a thread function--each thread must execute its own function. When the function returns, the thread dies. But the realm of all possible functions is huge! Functions are parametrized by the set of arguments they take and by the return value (possibly void). And you are supposed to write a generic function, newThread, to which you can pass any thread function and the values with which it should be called.

Imagine a C++ implementation. You'd have to write separate templates for newThread0 (thread function taking zero arguments), newThread1, newThread2, and so on, up to some magic maximum number of arguments. Then you would have to parametrize these function by passing the return type of the function. Finally, you'd want it to work not only with function pointers, but also with functors (objects that have operator() defined). It's a monumental task.

In D it took me a few hours to write one generic function, newThread, that works with an arbitrary thread function, functor, delegate, or closure. Ta dah! Here it is:

ThreadHandle newThread (F, A...) (F f, A a)
{
    alias ReturnType!(F) RetType;
    alias Thunk!(F, A) ThreadThunk;

    auto thunk = new ThreadThunk;
    thunk.Init (f, a);

    uint tid;
    
    auto h = _beginthreadex (
        null, // security attribute
        0, // stack size (default)
        &ThreadFunction !(ThreadThunk),
        thunk,
        CreationFlags.CREATE_SUSPENDED,
        & tid);

    if (IsNull (h))
        throw new Errno ("Thread creation failed");

    auto handle = ThreadHandle (h, tid);
    handle.Resume;
    return handle;
}

Here F is the type of the function (or function-like object), and A... is the (possibly empty) list of parameter types. Not only is this code simple, but it's very easy to use. Here's how you can call it:

    // execute a closure returning void
    int shared;
    void fvoid ()
    {
       shared = 13;
    }
    auto h = newThread (&fvoid);
    h.WaitForDeath ();
    assert (shared == 13);

In this case the thread runs a closure that takes zero arguments and returns nothing. You can tell it's a closure, because it grabs the caller's environment with it, in this case the variable "shared". Once the function is executed in a separate thread, this variable has a new value. Doesn't it just blow your mind?

And I'm still not totally happy with the language. There are some rough corners in the definition of Thunk.

struct Thunk (F, A...)
{
    F _f;
    A _a;
    static if (is (ReturnType!(F): void))
    {
        void Exec () { _f (_a); }
    }
    else
    {
        ReturnType!(F) _r;
        void Exec () { _r = _f (_a); }
        ReturnType!(F) Result () { return _r; }
    }

    // Revisit: turn into constructor
    void Init (F f, A a)
    {
        _f = f;
        //_a = a;
        foreach (i, T; A)
            _a [i] = a [i];
    }
}

static extern (Windows) uint ThreadFunction (ThunkType) (void * p)
{
    auto thunk = cast(ThunkType *) p;
    thunk.Exec ();
    return 0;
}

I don't like the "static if" (compile-time if). Here it is used to special-case the void return type. I have already submitted the proposal that would eliminate the special case and treat void just like any other type (and it was already accepted in our meeting last night). The Init function is used in place of a constructor, since structs in D don't yet have constructors or destructors (coming up soon, though). Consequently, I couldn't implement reference counting for thread handles, but that is also coming soon in D (I could have used classes rather than structs, since they are garbage collected, but for thread handles you really need better deallocation control).

I'm having a lot of fun with D!

Comcast sucks!

Wed, 19 Sep 2007 20:02:09 GMT

I never thought I would be pining for Microsoft software, but that's because I underestimate the inaptness of other software companies.

Case in point: Comcast in our area was using Microsoft software as the UI for their cable boxes and DVRs. Suddenly, with total disregard for the consumer, they switched to the LAMEST piece of software ever made for TV, GuideWorks, which they wrote jointly with Gemstar TV Guide International.

I really tried using it, blaming my old habits for not getting along with it, but it's not me--it's them! Every amateur thinks that designing user interface is a piece of cake. It's not! The difference is between a usable and unusable system. GuideWorks is unusable.

To begin with, I'm going to ask Comcast to replace my current DVR box with the standard cable box. DVR programming became practically impossible, so I'm not sacrificing much. I'm also thinking of getting a cheaper channel lineup.

Copernicus was wrong!

Sat, 08 Sep 2007 19:39:45 GMT

Could you believe that?! I am cited in conservapedia, the religious right's response to wikipedia! See for yourself. I am born again! Hallelujah!

So how am I helping the defenders of intelligent design? I wrote this article in which I explained that, in view of modern science, in particular Einstein's general relativity, it is possible to describe the universe from the geocentric point of view. It would require the change of the coordinate system to the non-inertial frame that moves with the Earth. Of course, such a description would be immensely complicated and impractical, but the principle is correct. Of course, from this statement there is only one tiny step to the claim that "Heliocentric and geocentric theories are both used today, depending on which allows more convenient calculations." Frankly, I had no idea anybody still used epicycles to calculate the movement of planets, but what do I know about science curricula at religious universities.

There is a tiny problem though: Conservapedia is not very fond of the relativity theory either. Here's en interesting excerpt:

There is a correlation between enthusiasm for the theory of relativity and political views, and there is an unmistakable effort to censor or ostracize criticism of relativity. Physicist Robert Dicke of Princeton University was a prominent critic of the theory of relativity and that may have hurt him professionally, even though his theory "has enjoyed a renaissance in connection with theories of higher dimensional space-time." Despite being one of the most accomplished physicists in the 20th century, Dicke was never awarded a Nobel Prize just as other outspoken critics of scientific theories were passed over in granting the Nobel Prize to less-accompished colleagues.

Darn it! I had no idea that any time you criticize a scientific theory, you face terrible persecution (burning at a stake, being passed over by the Nobel committee?). Einstein was lucky--he destroyed the well established theory of ether and still got away with a Nobel price.

DVD Encryption

Sat, 19 May 2007 18:11:07 GMT

Things are not as bad as I though. Yesterday I attended a seminar at the UW about the state of the war between the "cease and desist" people and the rest of us. We are winning the war!

As far as copying music, the industry has pretty much given up the futile efforts at copy protection. After EMI decided to start selling unprotected soundtracks, the rest will follow in short order.

The low definition DVDs use a brain-dead protection scheme, CSS (Content Scrambling System), that has been broken long time ago--witness DeCSS. CSS contained in its design the possibility of revoking broken cryptographic keys, but the industry never used it, so all past and present DVDs are easily copyable.

The new breed, HD-DVD and BlueRay, both use a new system, AACS (Advanced Access Control System). This is actually pretty strong system, with strong encryption and the ability to revoke broken keys at will. So it was a bit of a surprise to find out how quickly it has been broken by dedicated hackers. The cryptographic key was extracted from WinDVD in a very clever way. This key is now available on the Internet, on T-shirts, coffee mugs, etc. All the "cease and desist" notices mady it only more popular. With this key, you can decrypt (and copy) all HD-DVDs and BlueRay DVDs that have been published so far.

However, this key is now being revoked. This doesn't change the ability to decrypt existing DVDs, but all new DVDs will now contain the revocation of the broken key, so they won't be copyable. At least that was the idea. The revocation of the key takes 90 days, and for the last three months there have been no new releases of high-def media. The new wave will be released next Tuesday.

Now guess what. A DVD from a new batch was somehow leaked prematurely. To everybody's surprise, a software player called AnyDVD from SlySoft can play the new disks. Either they have broken more keys, or they found a way to circumvent the system.

Why is it so important to break the DVD encryption system? After all, people who have the means to play high def DVDs have already invested thousands in their hardware, so they can afford to buy DVDs. Except that there is one more annoying copy-protection mechanism, HDCP, the one between your computer or player and your monitor. If your expensive hi-def monitor doesn't have HDCP input, you're out of luck. Your legally bought player will not play your legally purchased HD-DVDs on your legally acquired plasma display! Caveat Emptor!

Fortunately, HDCP system has been long broken, and anyway it's not required if you use a player like AnyDVD. So even if you plan on purchasing all your HD-DVDs or BlueRays, you still might need an illegal player. They are just asking you to circumvent their system.

Anyway, this is not the biggest headache of the DVD industry. In fact, from the business point of view, they would be better off dropping copy protection (including the annoying region codes, and blocked user operations). The biggest problem is the format war between HD-DVD and BlueRay.

The prediction is that both systems will die and a new system will be adopted that has no DRM.

Another Obnoxious Company that Treats Users Like Dirt

Wed, 25 Apr 2007 19:14:49 GMT

I've been using Jasc Paint Shop Pro for ages. Unfortunately they were bought by Corel and the Corel marketing scum started working on it. They added the InstallShield update manager, an obnoxious piece of software that works like a Trojan horse. It regularly pops up a window telling me that there is a new version of Paint Shop Pro which I should buy for 55% less.

I would gladly buy it, if it weren't for the Corel's way of pushing it. The message pops up regularly and there is no obvious way of turning it off. There is a tiny help link, which tells me that I should click on some non-existing button or link called "Settings". I've found a Corel bulletin board post that addresses this problem (so the bastards are aware of it!). It tells me that I have to download the uninstaller from InstallShield web site.

CONSUMER REVOLT!!!
Corel is officially the Enemy of the User!

Big Changes

Mon, 29 Jan 2007 20:00:58 GMT

I'm in the middle of big changes in my life.

For one, I bought an iMac--yes, I caved in. I'm a sucker for shiny toys. It's a beautiful machine.

I'm also reading about QT, learning D, and working on a book about Windows programming in D.

And, before I forget, I'm now a non-matriculated grad student of CS at UW.

"Stay away from Vista" consumer revolt

Sat, 13 Jan 2007 20:18:57 GMT

I'm one of these "early adopter" types, at least as far as Microsoft operating systems go. I even installed a beta of Vista on one of my computers. But this time I'm going to stop at that. I think it's time for a consumer revolt. Read a very thorough analysis of Vista DRM (digital rights management) system by Peter Gutman from the CS department of the University of Auckland and cry. The short story is that Microsoft has joined forces with digital content providers in screwing up customers. I don't think computer pirates will have any problem bypassing Vista DRM--it's the honest consumer who will be paying for the idiotic system. Don't expect HD DVD's to be playing on your Vista computer withing the next few years.

For now I'm going to stay with Windows XP and probably diversify towards Linux, which I shunned for the longest time. Since I'll be buying new computers, I will demand no pre-installed Vista.

I wonder why it had to be somebody from New Zealand to write such a paper. Are our domestic academicians too scared of the Digital Millennium act to criticize any DRM system, even the most harebrained one?

Don't download this software! Microsoft marketing scum did it again!

Fri, 15 Dec 2006 04:05:24 GMT

I am stupid! There's no doubt about it. I am the leader of the microcephalic. I am the top moron, the emperor of dumbness. In other words I used Microsoft media player.

I mean, it kind of did its job--it played my CDs and DVDs. But that wasn't enough for me! When the media player announced that there was an upgrade ready to be installed, I jumped on it like a three-legged wardrobe. Slick new UI, oh my, I can't resist it!

And then, ha ha, I wanted to play a DVD. A DVD for which I paid actual money (stupid me!). It turned out that, unbeknownst to me, the new media player installed DRM (Digital Rights Management). Mind you, I am not a pirate, I haven't even ripped my DVD. I bought it, I put it in my DVD drive, and I wanted to play it. I shouldn't care whether DRM was installed on my computer or not, right? Right?!

Guess what, the new media player refused to play my DVD. It hijacked my computer and demanded a ransom. I am not kidding you! It told me that if I want to play my precious Fellowship of the Ring I had to pay twenty bucks. Did I mention that I'm not kidding you? Microsoft decreed that, if I wanted to watch my DVDs, I had to buy a third party decoder. It even informed me, in case I was a cheap bastard, that there are NO FREE DECODERS!

I hear there is this other operating system, Linux or some such, that DOESN'T HIJACK YOUR COMPUTER AND THEN ASK FOR RANSOM! I think I'm gonna give it a try.

War in Iraq: predictions

Tue, 31 Oct 2006 21:35:36 GMT

I used the following argument in discussions about the possibility of success or failure in the war in Iraq: As long as our losses are less than 3000, American public will keep supporting the war. The number 3000 is not random--it's the number of victims of 9/11. The reasoning is that losing more American lives to try to prevent the recurrence of 9/11 than the number lost in 9/11 doesn't look like a good bargain. Unfortunately, we are very quickly approaching this number (presently more than 2800, and the attrition rate is 100 soldiers a month). Because of that, I expect that the opposition to the war in Iraq to reach critical mass some time early next year. We probably won't have riots, like the ones during the Vietnam war, but that's because there is no conscription. Of course, the November elections will already see the impact of people's dissatisfaction with the way the war was mismanaged.

So what will happen next?

A year ago I blogged this:

The constitution barely passed in Iraq. This is not very good for democracy, if two whole Sunni provinces vote overwhelmingly against something that the Shia provinces massively accept. Looks to me like these two cannot live peacefully together. Which is really bad for the Sunnis, who are in a minority. Which leads to this really crazy situation, in which Sunnis' biggest enemy--that's us--is their only protector from the Shiites. Once we are out of Iraq, it will be open season on Sunnis.

Well, it seems like the hunting season has already begun. The Shiites form a majority in the government, and they don't mind the police force being infiltrated by Shiite militias, who take orders from Mokhtada al Sadr (who takes orders from Iran). When our troops withdraw, the Sunnis will have no foreign infidels to kill, and they will concentrate on killing the Shiites. But the Shiites are stronger, and they own the police and the army, so this will be an asymmetric war. Will other Sunni countries, like Saudi Arabia, help the Iraqi Sunnis? I doubt it. More likely Shiite Iran will get even more engaged in Iraq.

Now think of this: Iraq has a weak government, but we are trying to make its army stronger. What happens in countries where the military is stronger than the government? A military coup. Bye, bye, democracy! And what will the American government do then? We'll be damned if we recognize the coup makers, and damned if we don't. In one case we'll lose face (or whatever is left of it)-- in the other we'll lose Iraq.

There is one thing we should have done in the Middle East that would change the balance in our favor: buy Bashar al-Assad. Yes, he's a villain, he probably ordered the assassination of Rafik Hariri in Lebanon. But he did withdraw his troops from Lebanon. I think he could be bought with the promise of regaining the Golan Heights and the flow of Western investments. Bashar is now a big ally of Iran, but neither he, nor most of the Syrians, are Shiites. And he greatly helped the Iranians, the sponsors of Hezbollah, in the recent war in Lebanon.

In fact, it looks like there is a beginning of a thaw in American-Syrian relations. And the weakening of the Iranian influence that would be caused by such rapproachment might have a stabilizing effect on Iraq. It's a long shot, but it's worth trying.

One of the lessons from the war in Iraq is that sometimes dictatorship is a better choice than democracy. I hate to say that, but the Iraqis were better off under Saddam than they are now. That alone proves to me that the war in Iraq was a complete fiasco. The only scenario that would be even worse, is the scenario in which Saddam dies (or is killed) while in office, the Sunni-Shia war explodes, and Iran takes Iraq (or a big chunk of it) over.

Technocrati

Thu, 26 Oct 2006 19:59:15 GMT

I just added this journal to Technocrati. I guess "technocracy" means "the rule of technology". Or is it the rule of people who develop and understand technology? The "technocrati".

Well, it's better then being ruled by religious fanatics.

Inflation basics

Fri, 08 Sep 2006 19:16:03 GMT

I started a discussion in Wikipedia about Penrose's criticism of inflation and I must say it's an interesting experience. You would think physicists should be cold and detached and use logical arguments. Instead I see a lot of trend-following, personal likes and dislikes, and even personal attacks (they don't like Penrose there!).

Anyway, I got into an argument about thermalization and I'm really confused. Here's how I understand it:

Inflationary universe expands exponentially. So it is slow at the beginning and very fast at the end. I'm interested in this slow part. I argue that it was at that time that a small region of the universe reached thermal equilibrium. It makes perfect sense to me. Expansion was slow-- horizons were expanding faster than distances. It's only when things sped up, that small region was blown up to the size of our current observable universe. So the uniformity of temperature that we are seeing now across vast distances has its source in the initial thermalization during the slow part of the expansion.

It seems like this is not what other people on Wikipedia think. They think thermalization occurred at the end of the inflationary era, when the scalar field decayed and reheated the universe. But that makes no sense to me. Whatever local reheating occurred there, it had no time to equilize over large distances. That's the horizon problem all over again.

Why was the reheating process identical at the opposite sides of the universe? The only reason I can see is that the temperatures there were already (almost) identical and the onset of phase transition was simultaneous. Why? Because of the initial thermalization at the beginning of inflation. Isn't that what happened?

I hope amnesiadust reads this and can help me understand what's going on.

Deflating the Inflation

Sun, 03 Sep 2006 17:30:25 GMT

I'm reading Roger Penrose's "The Road to Reality"--a book every physicist should read. There are very few physicist with such depth of insight and the ability to "say how it is". So Penrose is now my second favorite after Feynman. (I still think Penrose's ideas about human consciousness are embarrassing, but that's a different topic altogether.)

I read Penrose's arguments against cosmic inflation and they make a lot of sense to me.

Inflation is supposed to "solve" some cosmological problems. For instance, why is the universe so homogeneous and flat.

Look ten billion light years to the left, then the same distance to the right, and you'll be amazed at how similar the two views are. In particular, the background radiation coming from both areas has almost identical temperature. Why is it so strange? Well, normally when two object have the same temperature, we assume that they must have been in contact with each other at some point--either directly or indirectly. The two areas of cosmos we are talking about could never have been in contact, because even the light from one of them didn't have the time to reach the other during the lifetime of the universe. The light has barely had enough time to reach us, who are in between the two of them.

Thermal equilibrium spreads much slower than light!

So, either these two areas started out at the same temperature (by coincidence? by design?), or we are wrong about them never having had time to exchange heat.

The inflation theory choses the second option. It postulates that there was a very short period of time, right after the Big Bang, during which the expansion of the universe was exponential (and not hyperbolic, parabolic, or elliptic--as the Einstein's equations would suggest, without the cosmological constant). The trick with exponential expansion is that it gets very fast, but it starts out real slow. It was during that initial slow period when tiny patches of the cosmos had a chance to reach internal thermal equilibrium. Immediately after that, they were blown up to enormous sizes--our whole visible universe originated from just one such small patch.

It all sort of makes sense; so much in fact that the inflation theory became part of the canon of cosmology, even though the actual cause of inflation is not known. (Sure, there are speculations having to do with spontaneous symmetry breaking in some yet unspecified grand unification theory. All those are way beyond our mathematical reach.)

What Penrose points out is that this "solution" substitutes one conundrum with another, even bigger. The bigger conundrum is, why was the entropy of the universe so unbelievably low at Big Bang?

We live in a universe where the Second Law of Thermodynamics rules. Entropy is always increasing in leaps and bounds.

You have to understand that entropy is not unbounded. It increases only until the system reaches the state of the equilibrium. At that point the Second Law of Thermodynamics stops working. The fact that it still works proves that the universe started very-very-very-far from the equilibrium. It was very precariously balanced on the tip of an enormous needle.

The local thermal equilibriums postulated by the inflation could have only been reached by increasing the entropy (the smoothing out of differences increases entropy). It means that the inflation theory requires the universe to start with even lower entropy. The enormous needle gets even taller!

What Penrose really uncovers is how subjective science is, at least at this highly speculative level. The truth is that we have no way of deciding what the "natural" state of the nascent universe should have been. Apparently, our bias is that a uniform state in not natural. We have to explain uniformity. We don't have to explain non-uniformity. Why is it so?

Are we biased because we were brought up in the universe where the Second Law of Thermodynamics plays such an important role--in fact, making life possible?

Simplifying code

Sun, 23 Jul 2006 19:07:28 GMT

I can't stress enough how important it is to immediately follow any extension of functionality with a refactoring and simplifying step. We've learned it at Reliable Software the hard way.

What happens if you skip those steps? The complexity of your code keeps increasing until you lose control over it. We came very close to this point when developing version 4.6. We had to establish strict rules to keep complexity in check. Accompanying every development step with a small rewrite became a rule. Creating new abstractions, refactoring, or plain simplifying the code are ways of reducing complexity.

Each new abstraction frees the brain of a developer from having to remember details. In cognitive psychology they call these things "chunks". If the code is nicely split into chunks, we can easily reason about it. If it's not, we have to put a lot of effort to create these chunks on the fly. We study the code over and over until some structure dawns on us (or not!). Then we promptly forget the ad-hoc chunking, and the next time around we have to go through the same process again. What a waste of time!

So I have abstracted some functionality of the tab control. Now I'm looking at the tab controller classes, which are virtually duplicated in code co-op and the differ. They are both derived from Notify::TabHandler. They contain a View, which is the above mentioned tab control abstraction (the EnumeratedTabs template, or a class derived from it). Most of the functionality of the tab controller is simply delegated to its View--Get/Set Selection, Add/Remove Tab, etc. I could have abstracted this delegation, but a simpler solution is to expose the View to the client of the tab controller. The method GetView returns a reference to the proper instantiation of EnumeratedTab. For convenience, I have typedef'd this instantiation, so, for instance, in the differ, FileTabController::View is the same as EnumeratedTabs<FileSelection>. In practice, I don't ever use this type outside, I just make direct calls, like this:

_tabCtrl->GetView ().SetSelection (FileAfter);

This modification required some changes in the client code, but they were self-limiting. This shows the resiliency of our code in the face of local modifications. It's not always like this. Sometimes a small change in the interface of a lower-level object results in an avalanche of changes in the client code. That would be a sign of weak design.

Top-down and test-driven development

Fri, 14 Jul 2006 16:24:13 GMT

I've been always advocating top-down approach to software development. This was based on my experience. Bottom-up leads to impedance mismatch problems; top-down creates clean architecture. I know I'm right, but how do I convince others?

And whenever I do a code review I have to be convincing. Just saying, "Trust me, I've done it a million times" doesn't always work.

What got me thinking about it is the test-driven methodology. It's a gimmick, which is useful in some specific situation, and is touted by some extreme programmers as panacea for all programming ills. The main point of test-driven development is that you first design a set of tests and then develop a component that passes them. At every step you use minimalist approach--you don't design for generality, you just want your component to pass the next test. The advantage of this approach is that you end up with a component that is built exactly to the spec--the spec being defined in terms of your tests--no more no less.

Of course, the problem is now shifted to designing appropriate tests--not an easy task! These tests create an environment for your component. The component evolves to fit this environment. Conceptually speaking, to design a plane, you first build a wind tunnel. If the plane passes all tests, it will be able to fly in your wind tunnel--which, incidentally, is not the same as flying in the airspace.

So the main question is, how well does your test suit simulate the actual environment where your component will live?

Now, going back to top-down approach--when you build your software top-down, you are, at each step, creating the actual environment in which your component will live. This reasoning clearly shows both the advantages and the shortcomings of top-down.

The main advantage is that the component is built to the exact specifications of its environment--you'll know what data, and in what form, will feed your component. You'll know what output is expected from your component. You'll know its lifetime--creation and destruction time.

On the other hand, it might be difficult to re-create all testing scenarios in a live project. Testing special cases and boundary conditions might be hard.

But the main problem is when your component must serve in multiple environments. Here, from the very start, you have to abstract the environment for your component. This abstraction might be easier to describe by a test suite than by anything else.

Which brings me to the conclusion that test-driven development is best when you are designing for reuse.

Which is actually rare.

Fight Net Censorship

Sun, 28 May 2006 16:24:40 GMT

I've been thinking for some time about adding content to our web site www.relisoft.com that would trigger censorship. The idea is that if valuable resources (and our web site is a pretty good source for C++ training) were made unavailable by censorship in countries like China, their government would risk stifling economic progress. Of course, for this to work, there would have to be an orchestrated campaign. I'm happy to announce that Amnesty International came up with exactly such campaign. Go to their site http://irrepressible.info and paste a short Java Script fragment in your web page or blog. Just like the one below. It changes every time the page is reloaded.

I'm also thinking of adding a picture of the Tiananmen tankman to the setup screen for our product, the Code Co-op version control system. We do no business with China, but people there use the cracked version of our product anyway. I wonder if the Chinese censors would block our web site (although Code Co-op is downloadable from other sources as well). If not, at least some of the young Chinese would have the opportunity to see the world-famous picture, which is banned in China (and which is blocked by Chinese Google).

<script src="http://fragments.irrepressible.info/js/fragment-234.js" type="text/javascript"></script>
(For some reason Java Script doesn't work in my LJ post.)

Complex Harmonies

Sun, 28 May 2006 00:32:20 GMT

The study of music offers a very good perspective on the struggle between simplicity and complexity.

We humans find certain combinations of sounds pleasing, or harmonious. We often find music beautiful. Beauty is subjective, so harmony should be subjective too. Or is it?

The first theory of harmony is due to Pythagoras, who discovered that the juxtapositions of sounds that sound harmonious follow some simple principles. For instance, if you strike two strings, one of which is twice as short as the other, they will produce a very harmonious perfect octave. The same experiment with the ratio of 2/3 produces another very harmonious interval--a perfect fifth. Those intervals are called perfect, because they sound perfect.

Pythagoras found out that if the ratios of the lengths of strings are equal to simple fractions, they sound harmonious. The simpler the fraction (smaller numerator and denominator) the more perfect the interval. The simplest fraction, 1/2, produces an octave, which sounds almost like the unison (which is 1/1). Next comes 1/3 (an octave + a fifth) and 2/3 (a fifth). 1/4 corresponds to two octaves, and then we have fourths, thirds, etc., which are still harmonious, but progressively less so. So, according to Pythagoras, harmony is not subjective--it has its roots in mathematics.

Much later it was discovered that harmony has something to do with frequencies, which are parameters in the Fourier transform of a sounds. Shorten the string by half and it will double the frequency of the sound it produces. The ratios of frequencies (which are more commonly used) are the inverse of the ratios of string lengths.

Why is Fourier transform so important? First, because this is what our ear does with all sounds before sending them to the brain. But there is also a physical aspect to Fourier transform--sine waves, which are the basis of Fourier analysis, are closely tied to harmonic oscillators. And harmonic oscillators are some of the simplest physical systems. So harmony has its roots in physics, too.

Well, to be fair, there are no harmonic oscillators in nature; just like there are no straight lines or circles. A harmonic oscillator is a Platonic idea, an abstraction. And abstractions are subjective--they are products of our brains. Se we are back to the starting point--harmony is subjective, but at a higher plane.

But that's not the end of the story. Since harmony is based on mathematical considerations, it should be possible to codify it--derive it from first principles or axioms. Using simple intervals, one can build a simple scale--the Pythagorean pentatonic. It has the following intervals 1/1, 9/8, 5/4, 3/2, 5/3 (it can also be built by stacking up perfect fifths modulo an octave). It loosely corresponds to the sequence C, D, E, G, A.

The pentatonic scale is used all over the world. It has one shortcoming though--it has large gaps. To fix this problem two more steps were added, corresponding to F and B in Western musical notation. This was an arbitrary decision, since one could as well have added F-flat and B-flat. In fact, the blues scale plays more freely with those steps, not to mention the minor scale.

This was the origin of the diatonic scale, that we all know and love. In its basic form it consists of the steps we call C, D, E, F, G, A, B (and back to C)--the white keys on the piano. You may notice that the Western notation sort of follows the alphabet, but not really. That's because the choice of the starting note (the tonic) is to some extent arbitrary. You can, for instance, start the scale with A (A, B, C, D, E, F, G) and obtain a variation which is now called the minor scale (or Aeolian mode). In the middle ages, the accepted canon contained all seven transpositions of those steps (these are now called church modes).

For people with perfect pitch, all this makes perfect sense. As for the rest of us--we don't really care what sound starts the particular mode. All we care about is the sequence of intervals. So if you take all those church modes and transpose them in such a way that they all start on the same note, you sort of get 11 possible notes. They fall in the vicinity of our chromatic scale (C, C#, D, D#, E, F, G, G#, A, A#, B). I say "sort of" because things are not as perfect in music as one would hope.

The problem is that "transpositional invariance" (my term) is incompatible with perfect intervals. Transpositional invariance in music is something that most of us find quite natural. If somebody plays a melody starting at C, and, some time later, plays the same melody a semitone higher (starting at C#), most of us won't notice the difference. It will be the same melody--all the intervals will be the same. Only people with perfect pitch may notice the difference.

So if you play all the church modes starting on the same note, but preserving the original intervals, you'll get all kinds of small discrepancies. In essence, intervals are defined using rational numbers, whereas transpositions require real numbers (in particular roots of rational numbers). These two don't jive.

The equivalent of the Goedel's incompleteness theorem in music is the existence of the Pythagorean comma. If you take a leap of a fifth 12 times in a row (for instance, starting with C, go to G, then to d, a, etc...), you'll reach a tone that is almost exactly the same as if you made 7 leaps of an octave. The tiny difference is called the Pythagorean comma.

To have a cake and eat it too, a new scheme was adopted, called equal temperament, in which all intervals, except the octave, became irrational. That's how modern pianos are tuned. When you play a fifth on the piano, for instance by striking C and G, you won't hear a perfect fifth. In fact most people couldn't tell a perfect fifth from a tempered fifth--the difference is so small. On the other hand, because of equal temperament, the interval between C and G is exactly the same as between D and A, and so on. Also twelve tempered fifth do add up to seven octaves.

A lot of people are heartbroken when they discover that music is not perfect. Others enjoy the richness of complexity brought by little imperfections. J. S. Bach was so enthusiastic that he composed 24 musical pieces in 12 major and 12 minor scales under the common title "The Well-Tempered Clavier." Equal temperament allowed clean transitions (modulations) from any key to any other key--something we now take for granted.

The Mechanics of Free Will

Sat, 06 May 2006 19:06:10 GMT

t'Hooft makes a good point about quantum theory vs. determinism. Let me elaborate a bit.

Quantum physics can only predict probabilities of events. To many physicists (including t'Hooft) this is very disconcerting. Is it really true that the state of the universe cannot be fully predicted from moment to moment? Or is this a shortcoming of our understanding of the universe? If the next state of the universe is selected by a toss of some transcendental dice, why can't we include the physics of those dice in our theory (and thus make them non-transcendental)? In fact, why not search for dice inside elementary particles?

Suppose that there is a hidden mechanism in every particle. If we don't know about the state of that mechanism, such a particle would behave non-deterministically to us.

Since the beginning of quantum mechanics people have been trying to build theories with hidden variables that would explain the apparent indeterminism of quantum mechanics. Not only have they failed, but it was proven that such theories would be incompatible with experiment.

Well, sort of. In every proof there are some assumptions and one can always try to question these assumptions.

The best example of an experiment whose results cannot be explained using hidden variables is the one with entangled particles. You can create a pair of electrons in such a way that they must have opposite spins (because you start with a state of zero spin, and spin is a conserved quantity). Although you know that the two electrons have opposite spins, you don't know in what direction they are pointing (up/down? left/right?). Until, that is, you measure the spin of one of the electrons. At that point you not only know the direction of the spin of that electron, but you also know in which direction the other one is pointing. Now somebody can measure the spin of the second electron, and their result must agree with yours. It is as if the second electron suddenly learned about the fact that its opposite twin has been measured.

The natural reaction at this point would be to say, "But both electrons had the directions of their spins set from the start, we just didn't know them until we measured them." And there's the rub--they couldn't! The actual direction of the spin would be the "hidden variable", but it isn't. The results of the experiment cannot be explained by assuming that both electrons had a definite direction of the spin. In fact, and I won't be going into details, the results of the second measurement depends not only of the result of the first measurement, but also on how the first measurement was done. The experimenter dealing with the first electron may chose to measure the vertical component of the spin; or, by tilting his magnets, might chose to measure the horizontal component (or any other, for that matter). The really spooky thing is that the results for the second electron depend on the way the first experimenter set up his experiment.

The experimenters may allow the electrons to fly apart for hours or years. When the measurements are done, the electrons may be separated by light years. The decision on how to orient each detector can be made at the last moment. And yet it looks like the second electron will instantly know what the first experimenter did.

No hidden variables could explain this!

There's one tacit assumption in this experiment-- says t'Hooft-- and it seems obvious to us, but isn't: The assumption that the experimenters have free will. We take it for granted that the first experimenter can make the last moment decision about the orientation of his apparatus, and that the decision is free and unpredictable. In a totally deterministic universe that is simply not true! If we consider the experimenters as parts of the experiment, their state is as important as the state of the electrons. The only thing that the experiment shows is that in the system where the first experimenter is bound to make the decision to orient his apparatus vertically, the second experimenter will see a particular result. No "spooky action at a distance"! Just the old-fashioned preordained universe.

The funny thing is that a lot of people protest t'Hooft's interpretation because it contradicts the existence of free will. The fact is that

No physical theory, including traditional quantum mechanics, has room for free will.

It seems like there are still some philosophers who don't understand this fact.

Access complexity

Sun, 16 Apr 2006 20:45:37 GMT

In order for one software component to interact with another, it has to have access to it. Modern languages give programmers control over access, and for a good reason. A very important question in software development is, "Who are the clients of this object?". "What objects can modify the state of this object?". The rule of thumb is to design the system so that by default objects don't get access to other objects, unless explicitly granted. It's a very good rule, since it limits complexity.

Object access can be graphed: When object A has access to object B, you draw an arrow between them (notice, this is not a symmetric relation). The structure of the access graph for the whole system reflects its complexity. Ideally, the graph should be a tree with the branching ratio of no more than 7 plus/minus 2. The use of recursion may introduce cycles in this graph--it's important that these cycles be well understood and limited in size.

In every system there are a few global objects that can be accessed by anybody. System services are usually made global, for instance by exposing a global set of APIs. Global objects can still limit the way they are accessed. They can restrict access rights by making their methods private or selectively grant access by declaring friend classes/functions.

Some types of input/output objects (for instance std::in and std::out, but not only) can be global. So can simple feedback mechanisms (setting the hourglass pointer, or displaying a progress meter), or even message- or dialog- managers. Global objects or functions have their place in the architecture of any system; although, from the point of complexity, their number should be strictly limited (the 7 plus/minus 2 rule).

Access to non-global components can be controlled at a much finer granularity, both statically and dynamically. The strongest (static) binding between objects is when one is embedded in another. Next comes the embedding of a reference, whose initialization is dynamic, but restricted to the object's constructor. Embedded pointers can potentially be manipulated during object's lifetime. In that case the the same object might, at different times, have access to different objects (from the access-graph point of view, what counts is the totality of objects that can be access by an object during its lifetime). Finally, an object can be granted transient access to another object when that object is passed as an argument to a method.

Experience shows that, as the system grows, the number of access connections per object grows. This is mostly the result of adding new methods and generalizing existing methods to perform more tasks. Access to additional components is required for this increased functionality. It is provided either by adding new embeddings (usually through references or pointers), or passing more arguments to methods.

Next: Decreasing access dependencies through the use of interfaces

Communicating objects

Fri, 14 Apr 2006 21:24:05 GMT

In software engineering, monoliths are bad, components are good. Fair enough! Good software follows the tree-like structure. That much is obvious.

If you are a software architect worth your salt, you start designing a new system by dividing it into natural components. If it's an interactive application, you start with the Model-View-Controller troika. Then you divide the Model into subcomponents that reflect natural abstractions of the problem domain. And you keep refining the architecture, down to some arbitrary level where the nitty-gritty implementation takes over and the pedal hits the metal.

This is actually the easy part. The difficult part is designing communications between all those components. As long as the components are simple and small, which happens either at the beginning of development, or at the relatively low level in the hierarchy, the communications are pretty straightforward. One component-- usually corresponding to an object of some class--calls the methods of another component. So the architect sketches classes and their methods. Components are represented by classes and communications are defined by their methods. A class that describes a component is usually a structural class--it's instantiated in a single object.

Incidentally, the system of classes (especially the high-level ones) doesn't change that much during the lifetime of the project. It's the interfaces that undergo constant modifications--usually by growing (and growing...), both in numbers and in the complexity of arguments. Another thing that changes is the access patterns between classes. More and more classes get access to more and more classes.

That's the main reason why the complexity of a system increases exponentially during its lifetime.

We won't be able to make progress in software development methodologies unless we learn to control this complexity.

We have to understand the patterns of interactions between objects and their evolution in time.

Next: Access patterns.

Complexity and Lossy Compression

Sun, 09 Apr 2006 22:15:28 GMT

Intrinsic complexity is related to lossless compression. We measure intrinsic complexity by trying to squeeze the data into smallest size possible. This can be done by writing a program that, acting on some initial data (which are part of the program and count towards its size) , recreates the original. That's the Chaitin-Kolmogorov definition of complexity.

My claim is that structural complexity is related to lossy compression. Let me explain.

What is structure? Structure is the possibility of subdividing a larger problem into a smaller set of entities.

For instance, a procedural program has structure if it can be viewed as a series of function calls (this is the idea behind procedural decomposition). You can look at such program from bird's eye perspective and understand, to a certain extent, what this program is doing. You have to make certain assumptions about what the purpose of each function is in order to make sense of the sequence of these functions. For instance, this part of the program:

int main ()
{
    SquareState chessBoard [64];
    ReadBoardFromFile (chessBoard, "board.txt");
    Move m = FindWinningMove (chessBoard);
    PrintMove (m);
}

is pretty easy to understand.

If we were to study the program further, we would look into the implementation of each of the top-level functions in turn. Hopefully, each such function would have similar structure, and we could recurse down to the lowest level. The most important part of this decomposition is that at each level we only have to keep in mind a small number of ideas--our understanding of what each function at this level does. When studying PrintMove, we don't have to know what FindWinningMove does, or even that it exists.

Now look at the code in main: It's a compressed version of the whole program, isn't it? It's a very lossy compression, since we have no idea how FindWinningMove or any other function called from main is implemented. There isn't enough information in main to reconstruct the whole program. Yet it gives us a pretty good idea of what the program does.

A well-structured program has the form of a tree. Each node in the tree contains a lossy compression of all all its dependents.

Here, the top level node is the function main. It compresses the workings of the whole program in a few lines of code. Each line of code plays two roles: (a) it describes a large part of the program in a lossy way, and (b) it is a "pointer" to a lower-level node that implements that part of the program--the actual implementation of the function. And so on, recursively, until one reaches leaf nodes, which contain only language primitives. (By the way, those primitives are also lossy compressions of actual machine instructions that will be emitted by the compiler.)

Complexity: definitions

Sun, 09 Apr 2006 01:19:22 GMT

It's very frustrating when people use the word complexity in scientific context without defining it. And it looks like different people mean really different things when they talk about complexity. I'm trying to organize various definitions.

Intrinsic Complexity
In mathematics people use the Chaitin-Kolmogorov definition: Complexity of an output is defined by the size of the smallest program that can produce this output (obviously, this is a language-dependent definition, but the idea is that at least relative complexity is pretty stable under language changes). There is no algorithm to calculate Chaitin-Kolmogorov complexity, and in fact, as Chaitin proved, there can't be one.

This is the only objective definition of complexity, so I'll call it intrinsic complexity. It can also be expressed in terms of compression, since a program (or algorithm) can be considered a compressed version of its output. (Instead of sending you a bitmap of a circle, it might be more efficient to send you a program to draw a circle.)

Note that intrinsic complexity doesn't take into account the time or resources it takes to run the program. So, for instance, the least complex program to play chess would enumerate all possible moves and pick one that leads to a check-mate. Not a practical solution!

Chaotic Complexity
Wolfram uses a more subjective notion of complexity (without defining it!). He often says "simple rules may result in complex behavior". If the rules are simple, than the results must, by definition, have low intrinsic complexity. What Wolfram means is that the pictures created by some of his cellular automata show little structure. They look "complex" because our eyes can't find any obvious patterns in them. This is, however, misleading, because one can easily guess the rules by looking at the evolution of a pattern. This is what physicists are good about. They look at real, sometimes very "complex" phenomena, and try to explain them using simple laws. Are these phenomena "complex" if they can be reduced to simple laws?

Wolfram's understanding of complexity has more to do with chaos. Chaotic processes can be explained using simple rules, therefore have low intrinsic complexity. However, in practice, the application of these rules might be very difficult, making predictions virtually impossible. An example of a chaotic process is the movement of three bodies under mutual gravitational attraction (the famous three-body problem). Newton's laws of motion and gravity are very simple, but their application to three bodies may be arbitrarily difficult.

Structural Complexity
Finally, there is a purely subjective notion of complexity. Complex things are difficult to understand. Obviously, what is difficult for one person might be simple for another and vice versa. There is however a lot of commonality in the way human brains work. Our cognitive system can manipulate only a small number of ideas at a time--the famous "seven plus or minus two" rule (more details in my book). So if the problem can be subdivided in a tree-like system of sub-problems, it is easier for us to study it. Things that have structure are easier for us to understand, therefore seem less complex. I will call this structural complexity.

Structural complexity is the most important feature in human understanding. In particular, it is the most important feature in software development. The more structure in our programs, the easier they are to develop and maintain.

Progress in software engineering is predicated on understanding and managing structural complexity.

Singualrity

Wed, 05 Apr 2006 01:28:15 GMT

It's time to poke some fun at the Church of Singularity. It's a very scientific cult and it doesn't ask you to pay money for the enlightenment--quite the opposite in fact! Like many other religions it comes with some dietary recommendations (eat a lot of antioxidants and supplements, otherwise starve yourself as much as possible). Most of the people living today are to witness the coming of Singularity (remember early Christianity with its promise of the Second Coming before the end of the generation?).

The arguments made by Singularitarians make a lot of sense. They claim that the scientific and technological progress follows the exponential curve. At the present rate of acceleration, we are bound to reach a level of development that will make possible the creation of a superior artificial intelligence that will solve all our problems. Singularitarians' back-of-the-envelope calculations show that the breakthrough will happen within tens rather than hundreds or thousands of years.

I must confess that Singularitarianism is a very attractive proposition and when I occasionally shut down my rational mind, I believe in it. Just imagine being able to undo the ravages of time suffered by your body and mind and keep them in top shape forever. I'll take that over the promise of Heaven any time (Singularitarianism doesn't impose any undue restrictions on sex, drugs, and rock-and-roll!).

So why do I (with a heavy heart!) dismiss the whole idea as technologically based wishful thinking? Because it's obvious to me (and anybody who doesn't succumb to the allure of quick eternity) that creating an AI that is comparable, not to mention superior, to human mind is much more complex than the Singularitarians imagine. If intelligence were only a matter of brute force--like playing chess, for instance--the naive extrapolations of Singularitarians would make sense. The density of transistors, capacity of RAM, connectivity of computers, etc., indeed grow exponentially, and in a few dozen years will catch up with the superficial complexity of the human brain (considering that a neuron could be simulated with a bunch of transistors).

Unfortunately such arguments are as valid as the following reasoning: It takes nine months for a woman to create a child. If we put 40 women to work, we can shorten the process to a week!

For one, the brain of an idiot usually contains the same number of neurons as the brain of a genius. Also, a hundred thousand idiots will not come up with the theory of relativity. So much for brute force!

There is a certain amount of irreducible complexity that goes into intelligence. This complexity might be implemented in hardware or in software (or in wetware, as biological systems are sometimes called). However impressive the technological progress, it doesn't deal with irreducible complexity. Its main advances are in terms of repetition of the same patterns (which most of the current hardware and software development is about). What's more, we don't even have a good handle on estimating complexity. Superficial measures, such as size or number of connections, are very misleading.

I think Kurzweil at al. are too fascinated with the progress in hardware and pay too little attention to the glacial pace of progress in software. We are still in Stone Age as far as software development is concerned. And that's where the complexity frontier is.

It doesn't matter how many genomes we map, as long as the functional study of a single gene is worthy of a Ph.D. thesis. The number of Ph.D students does not grow exponentially and that's the biggest bottleneck. Having a complete genome or a complete neuron map of a human brain is useless if we don't have the software to creatively study it. And by creatively I mean not just statistically. We need software that can generate hypotheses and test them. The closest we came to this was the shotgun approach of chess-playing programs. Unfortunately this approach doesn't scale.

Finally, even if we could keep the exponential pace of progress, there are many things that are more powerful than the exponential. How about the factorial, which is characteristic of combinatorial problems? When you plot exponential growth using logarithmic scale, you get a straight line: log eⁿ = n. With the factorial, you get log n! ~ n log n - n (Stirling's formula). I believe the complexity of biological organisms, and brains in particular, grows like a factorial of the number of parts. So considering that our understanding of nervous systems is currently at the level of C. Elegans--a brainless worm with 302 neurons and 7000 synapses, we have a long way to go before we reach the Singularity.

What if Plato was wrong?

Sun, 02 Apr 2006 04:34:21 GMT

Plato believed that ideal abstractions existed. In fact he though that all the imperfect things we observed in our universe were but the shadows of perfect ideas. We could never create an ideal circle in our world, but the idea of a circle existed by itself. Numbers, points, geometric figures and solids, existed for Plato more than beans, dots, plots of lands, or planets.

But what if he was totally wrong? What if abstractions don't exist? To this day we assume that the process of abstraction is well defined and produces consistent results. We take 3 beans, 3 planets, 3 galaxies, and so on; and we say that the common thing between them is "number 3". Abstract the bean-ness, planet-ness, galaxi-ness, and what's left is the abstraction of a number. But how do you describe this abstraction without talking about beans, planets, and galaxies? You pick the properties of numbers that are independent of actual physical objects and divide them into axioms and theorems. And you call these abstractions "numbers." For instance, you decree that every number has its successor. If successors of two numbers are equal, these numbers are equal too. And so on...

Well, the problem is that there is no guarantee that after subtracting the bean-ness from beans we are indeed left with a viable entity. According to Goedel (with whose theorem Plato was not familiar) the little abstractions we call numbers have properties that are alien to beans. There aren't things that you can say about bean counting that are undecidable! Conversely, there are things about numbers that are!

Incidentally, all the undecidable things about numbers have to do with infinity. Now that's something that's alien to beans! You can't have infinitely many beans. You put too many beans in one place and they collapse under their own gravity into a black hole. You can't always add just one more bean to your soup and expect that things will be fine.

So what if all this "abstraction" business is flawed? Personally, I don't see any other explanation for Goedel's theorem.