Here is what happened, pure and simple: Randiv bowled. The umpire called ‘no-ball’. There is a reason the umpire calls it as soon as a bowler bowls one – it is to let the batsman know that there are no real penalties attached to having a go. A batsman, on hearing that call, knows he can have a swing without running the risk of being bowled, caught, declared LBW.

So Randiv bowled. The umpire called. Sehwag had a swing, and despatched the ball over the ropes.

That logically is seven runs added to the total – one to the team total as an extra, the other six to Sehwag, the batsman who was quick to seize on the opportunity. Simple.

This is where the idiocy of umpires and the ambiguity of the rule book come in: How could the game be over as soon as Randiv over-stepped? A ball, to be deemed bowled, has to be delivered; the batsman has to play/miss it; in the case of the former the ball has to be retrieved while the batsman runs, or not…there is no provision in cricket for declaring a result, and ending a match, at some intermediate stage of this process.

Thus, for umpires to declare that the game was over as soon as Randiv overstepped is plain folly. To understand this, consider a hypothetical situation: Randiv bowls. It is a no-ball. Sehwag decides the game is over, lets the ball go and walks off. Sangakkara collects and whips off the bails.

Is the batsman out? Of course he is. The extra run cannot be counted until the ball in question is officially dead; in our example Sehwag left his crease while the ball was in play, therefore he is out.

So, if his dismissal off a no ball counts, why were the runs he scored off that no ball not counted to his name?

via Fit to Post: Yahoo! India News » Blog Archive Sehwag Did Get His Century! «.

And so, we come swiftly to a conclusion: allow me to introduce the Natty Narwhal, our mascot for development work that we expect to deliver as Ubuntu 11.04.

The Narwhal, as an Arctic (and somewhat endangered) animal, is a fitting reminder of the fact that we have only one spaceship that can host all of humanity (trust me, a Soyuz won’t do for the long haul to Alpha Centauri). And Ubuntu is all about bringing the generosity of all contributors in this functional commons of code to the widest possible audience, it’s about treating one another with respect, and it’s about being aware of the complexity and diversity of the ecosystems which feed us, clothe us and keep us healthy. Being a natty narwhal, of course, means we have some obligation to put our best foot forward. First impressions count, lasting impressions count more, so let’s make both and make them favourable.

via Mark Shuttleworth » Blog Archive » N-imal?.

Interestingly, Narhwal pictures seem to be pretty rare on the Internet. Here is a one hosted at National Geographic:

From: Yahoo! News at http://news.yahoo.com/s/yblog_upshot/20100811/od_yblog_upshot/behold-americas-educational-system-captured-in-a-single-photograph

But why is parallel processing so challenging? An analogy helps here. Programming is in many ways like writing a news story. Potentially, 10 reporters could complete a story 10 times as fast as a single reporter could ever manage it. But they’d need to divide a task into 10 equally sized pieces; otherwise they couldn’t achieve a full tenfold speedup.

Complications would arise, however, if one part of the story couldn’t be written until the rest of it was done. The 10 reporters would also need to ensure that each bit of text was consistent with what came before and that the next section flowed logically from it, without repeating any material. Also, they would have to time their efforts so that they finished simultaneously. After all, you can’t publish a story while you’re still waiting for a piece in the middle to be completed. These same issues—load balancing, sequential dependencies, and synchronization—challenge parallel programmers.

Further along:

All in all, things look pretty bleak.

But he continues:

Nevertheless, there has been progress in some communities. In general, parallelism can work when you can afford to assemble a crack team of Ph.D.-level programmers to tackle a problem with many different tasks that depend very little on one another. One example is the database systems that banks use for managing ATM transactions and airlines use for tracking reservations. Another example is Internet searching. It’s much easier to parallelize programs that deal with lots of users doing pretty much the same thing rather than a single user doing something very complicated. That’s because you can readily take advantage of the inherent task-level parallelism of the problem at hand.

Other success stories referred to are Computer Graphics, Weather Prediction (one of the workhorse applications for supercomputing – one of PARAM’s main use has been in the National Centre for Medium Range Weather Forecasting (NCMRWF)) and simulations.

The La-Z-Boy era of program performance is now officially over, so programmers who care about performance must get up off their recliners and start making their programs parallel.

Despite these reasons for hope, the odds are still against the microprocessor industry squarely completing its risky Hail Mary pass and finding some all-encompassing way to convert every piece of software to run on many parallel processors. I and other ­researchers at the main centers of parallel-­computing research—including Georgia Tech, the University of Illinois, Rice University, Stanford, and the University of California, Berkeley—certainly don’t expect that to happen. So rather than working on general programming languages or computer designs, we are instead trying to create a few important applications that can take advantage of many-core microprocessors. Although none of these groups is likely to develop the ultimate killer app, that’s not the intention. Rather, we hope that the hardware and software we invent will contain some of the key innovations needed to make parallel programming straightforward. If we’re successful, this work should help to usher in whatever application ultimately wins the “killer” distinction.

He finishes off with:

No matter how the ball bounces, it’s going to be fun to watch, at least for the fans. The next decade is going to be interesting.

via IEEE Spectrum: The Trouble With Multicore.

Found a nice set of articles at: http://www.smashingmagazine.com/tag/typography/ and they pointed me to the awesome “The League of Moveable Type”

Infographic byWordStream Internet Marketing

Infographic by the PPC Blog.com

The impetus to post this came from this posting “Indic transliteration on computers – brief history and now” on Shashikant Joshi’s blog – Practical Sanskrit. Its an interesting account of the old days of Indic transliteration – ITrans was my first introduction to Indic on computers. Thanks, Shashi

These articles that I got from a Slashdot article are:

• Hello from a libc-free world! (Part 1) from the ksplice blog. The article explains a lot that goes on under the hood.
• A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux

  “This document explores methods for squeezing excess bytes out of simple programs. (Of course, the more practical purpose of this document is to describe a few of the inner workings of the ELF file format and the Linux operating system. But hopefully you can also learn something about how to make really teensy ELF executables in the process.)”

These articles look to good, interesting and well written. For those interested more on this topic, do not miss Peter van der Linden's amazing book on C – “Expert C Programming”, now also available in an economical Indian edition. BTW, for anyone looking for technical books in Bangalore, your search stops at Tata Book House in the sprawling campus of the Indian Institute of Science, Bangalore. Another book for those interested in the esoteric topic of linkers and loaders is the 1999 book on the subject: “Linkers and Loaders” written by John R. Levine. The draft manuscript is available on the site, but the Indian edition (if you can find it) is surprising cheap.

P.S.: Sorry for a broken link earlier.