make clean

January 19, 2008

Penrose : Shadows of the mind

Filed under: Uncategorized — harshadrj @ 10:08 am
Tags: ,

Shadows of the mind is an attempt by Roger Penrose to prove that a computing machine can never achieve human like intelligence; the implication being that human brains are something more than “mere” computing machines.

I have been skimming through this book the last few days and I find it very well written. Though, that is its very downfall! The central argument is clearly presented and hence it is easy (for an average mind like mine) to see it’s fallacy.

I will try to show the fallacy here in informal terms. The central argument in the book is just about a page long and tries to combine the halting problem with Godel’s theorem. Expressed informally, it goes like this:

Assume that all algorithms can be arranged into an (infinite) ordered list, C0, C1, C2….

Let A(n) be an algorithm that halts if Cn does not halt. Now A(n) itself has to be listed in the above list, say as Ck. The question is “will A(k) ever halt”? This kind of self-reference obviously leads to a paradox and Penrose uses it to argue that humans are somehow better than computing machines.

However, we can construct a very similar argument with “humans” instead of algorithms:

Assume that all humans can be arranged into a (finite) ordered list, H0, H1, H2..

Let O be a human with oracle like powers that, upon hearing n, winks if Hn doesn’t wink. Now, this oracle herself has to be listed in the above list, say as Hk. The question is “will O wink if she hears k”?

Here, the human O will crumble just as easily as the algorithm A. The real problem was not with O or A, but with the paradoxical question(s) that they were asked.

This book has been a major disappointment in this regard. However, there are some interesting sections that deal with general theory of relativity and quantum physics, which are a good introductory read.

Update: While writing this post, I did a quick search on the web, and there is a similar formal refutation of Penrose’s argument here.

Update: An even better refutation is here, which deals with “systems of reasoning” and their limitations.  A parody of Penrose’s own dialog here.


December 29, 2007

Yummier yumex

Filed under: Uncategorized — harshadrj @ 9:56 am
Tags: , , ,

After many days of struggling with yumex code I finally managed to add a nifty feature to it. With this fix, yumex shows the version difference for an update in bold font.Yumex snap small

I find this very useful to quickly determine if an update is a major upgrade or not. In the above example, rosegarden is a major upgrade, while qt4-x11 is a minor one.

I am posting the patch here, since the yumex website seems to be rather sparse and ill-maintained. This patch is against the 2.0.3 release. (more…)

December 27, 2007

Some cool new programs

Filed under: Uncategorized — harshadrj @ 3:07 pm
Tags: , , ,

I don’t know if this just some fanciful graphics or something truly marvelous. Check it out if you can (it’s for Mac only):

NodeBox | Evolution

The other cool application I stumbled upon:

Scala Ray 

It’s hard to implement a ray-tracer and, yet, these guys seem to have implemented Ambient Occlusion in version 0.1 itself. Render times seem to be a bit slow though.

December 17, 2007


Filed under: Uncategorized — k2sings @ 2:16 pm
Tags: , , ,

C as popularly called, is a spartan language that requires a lot of self
discipline to master it and make use of it.

The obsolute freedom and the straight interaction with hardware demands lot of
care, insight and discipline. There are questions on whether a programmer
should be forced to adapt to the ways of a particular language and I personally
dont know whether one should or shouldnt. Nevertheless it is interesting to go
reflect back on C language as a C programmer.

The winning advantages for C are,

No better language to do system programming (kernel, drivers)
across a varied computing architecture. And if an attempt is made to
create a new language in this domain, it will more or less look like C.

Performance. I dont know whether it is to do with the syntax of the
language or to do with the semantics of the language. Or whether it is do
with the people who were chosen to write the compilers. C compiled
binaries are the fastest.

Popularity. I leave it to the reader, since he could be knowing better than

Ecosystem. The toolchain, debugger, IDE, editors are best available for C.
Probably Java programmer could also make that claim, but I dont know any
other language which could measure up in providing that sort of
developer/development ecosystem.

What sucks ?

Pointers. One thing that demands atmost discipline.

Lack of constructs. Programming languages have evolved a lot, to be more
expressive. But when C was made into C++, it increased as much frustration
as it increased fun. Okay, did it increase the fun part ?

Preprocessors. Today it has become an indespensable supplementary tool for
the C language itself, especially for large projects. Without it is very
hard to make the C code portable.
But when a programmer wants to maintain a code, he had to parse two
languages in his mind and very many architectures along with that. Atleast
I find that harmful for my brain.

Portability. A programmer in 1980s would have made portability as a
winning advantage for C language, but the wheel of history have turned the
table around. Faster processors, mature virtual machines, dynamic
translation have made languages like Java and Python as reasonable options
for programmers. There is a section which cover the “features” in C
language that makes it less portable

Undefined features. Compile and run the following code snippet on Irix,
GCC and sparc machines. You will know what “Undefine feature” means.

int i = 10;
printf(” %d %d %d %d %x “, i++, –i, ++i, ++i, i++ );

And, there are quite a few “features” like this.

Is C Portable ?

Not when you compare it with Java or python. Especially Java.

Endianess. There is a perinnial problem of big endian or little endian.

Size of datatypes. The program/programmer cannot make assumptions on the
size of the basic data types like int, shot, long, char, pointer etc…

Memory alignment. Some processors require that the half-word, word, dword
memory access are aligned. That is a half-word (2 byte) memory access
should be only through address which are multiples of 2, a word (4
byte) memory access should be only through address which are multiples of
4 and so on.

Structure packing. Based on mem alignments and packing directives, the way
in the structure members are packed and padded can vary.

Pointer arithmetic. Goddammit !!

Compiler extensions. Not all compilers play the same music. So a program
can be non-portable across compilers even on the same architecture.

Binary and binary files. Another spartan feature of C program is the
control the compiler/language can provide, on where to store sections of
data and code. A C programmer is not yet a complete C programmer without
learning linker scripts and the ELF file format. And beware, knowing them
can lead to as much pain as not knowing them.

Application Binary Interface. The problem is C language does not have one,
and it is left to the compiler to decide on that. So it is better to know
how function calls are made and return values passed back for specific
compiler tool chains that the programmer uses.

Non-exhausting list of portability problems. Well, some might disagree,
and I suggest them to complete this list.

All said, C cannot be replaced and the claims like C has outlived its need are
false. We can choose other languages if they suit better, but on any day, I
would want one language which gives enough power to the programmer. Like C.
Let us just make ourselves more spartan like.

December 15, 2007


Filed under: Uncategorized — harshadrj @ 11:37 am
Tags: , , ,

Eclipse never ceases to impress me, with it’s refactoring and auto-fix features (for the java platform). Clover is a code coverage tool that (apparently) works very well with Eclipse.

At one time, there was this TogetherJ IDE, which provided a complete path from UML to Java and back. You could edit your java source, and see the UML changing instantly! And it all worked flawlessly.. no gotchas! But it sadly got taken-over by Borland, I think, and I haven’t heard of it since.

Anyway, I have never seen such good IDE support for other languages I have worked with (C/C++/Perl/Python/Prolog/Lisp and oh well Fortran/Cobol/blah blah). I am just saying..

It is not that I can’t work without IDEs. I am very comfortable using Vim/Cscope/Ctags, and even consider myself a power user of these. But, I can’t ignore the productivity boost I get from a (good) IDE.

December 6, 2007

Graph Layout using Genetic Algorithms

Filed under: Uncategorized — harshadrj @ 11:48 pm
Tags: , , ,

The field of Genetic Programming (GP) has always fascinated me, due to my interest in AI. But GP is a tough nut to crack. Genetic Algorithms (GA) is an easier stepping stone, that I wanted to try first. So, my interest was kindled when I saw jiva-ng, a scala based framework for GA.

After trying out some of the stock examples in the jiva-ng wiki, I was itching to try something a bit more involved, and I decided to try Graph Layout-ing.


December 1, 2007

Game programming

Filed under: Uncategorized — pharaoh @ 5:24 pm
Tags: , , , , ,

The field of Game programming (writing computer games) has been breeding ground for many innovative ideas, and is always pushing computer science into newer frontiers. And, I don’t mean just the graphics FX, but also the algorithms/data structures used inside the game.

Here is a random collection of links:

Pathfinding algorithms

Interesting description of path-finding algorithms. I wish they had taught algorithms like this back in college.


The objective of this game is to program robots, which are then run inside a simulated environment, and they can compete and attack each other. The robots can be programmed in any language and only communicate via stdin/stdout. I have played with this game many years back, and has helped me understand many concepts in computer science, AI and fishing. Ok, the last one might be wrong.. but who knows 🙂

One thing that this game taught me is the concept of Actors, which seem to be getting a lot of attention these days (Erlang Actors/Scala Actors or this or this or this)

Playing chess with a bayesian spam filter

The author of dbacl, a spam filter based on bayesian models, writes an interesting story of getting dbacl to play chess!

In fact, this is the approach used in most chess playing programs, in the opening section of the game. The opening section is more challenging to deal with because the number of legal moves is very high, and the scores of both players are very likely to be equal (by most heuristic algorithms).

Functional Programming and automatic type inference

Filed under: Uncategorized — pharaoh @ 12:28 pm
Tags: , ,

The power of functional programming combined with type inference is amazing. Consider for example this code snippet, written in Scala, and taken from here:

class Knapsack extends jiva.ProbDefiner {
     def gaProblem = buildBooleanProb {buildr =>
        buildr name "Knapsack"

It’s an amazingly compact piece of code which does a lot of things under the hood.

  • It defines a function “gaProblem”. The return type is automatically inferred to be the return type of the function buildBooleanProb() which is defined in ProbDefiner.
  • The function buildBooleanProb() takes another function as it’s argument. This is the hallmark of functional programming languages. They support “first-classed functions”, which means that functions are like any other objects, and can be passed around as values!
  • The => notation creates an anonymous function automatically. Let’s give it a name, say “monkey_1”
  • The monkey_1 function takes as argument an object called “buildr”, and calls some functions on it. Note that the type of “buildr” has not been declared. The syntax ‘buildr name “Knapsack” ‘ is translated in Scala to ‘“Knapsack”)’

Note that Scala is a strongly type language, and yet for all the above objects not a single type definition has been specified. It is all inferred by the compiler. The benefits of this are, less boiler-plate code to type, which means it is suitable for RAD*, and type-checking at compile time, which prevents common errors.

For example, if the programmer types “buildr xyz” and xyz is not defined in that class, Scala will complain at compile time.

*Although type inference might be suitable for RAD, the functional programming paradigm itself may not be suitable for RAD if programmers are not comfortable/familiar with it.

Hello world!

Filed under: Uncategorized — pharaoh @ 6:25 am

Welcome to This is your first post. Edit or delete it and start blogging!

« Previous Page

Blog at