Indian origin kid wins $100,000 for speech recognition

Inspired by the science fiction movie "I, Robot," two high school students, one of them an Indian American, have developed a speech recognition technology that has won them a $100,000 grand prize.

Akash Krishnan and Matthew Fernandez of Portland, Oregon, who developed a computer algorithm that can detect a speaker's emotions better than current technology, would share the team prize, the Siemens Competition for America's top math and science students announced Monday.

Krishnan, 16, and Fernandez, 17, watched "I, Robot," while taking a break from trying to come up with a project idea. The movie featured a robot that could detect when its user was stressed, and they decided to try to improve on the existing technology.

Their algorithm has a 60 percent accuracy rate, compared with about 40 percent for a previous system. They say their work could be used to improve computer automated phone systems, helping, for example, to tell if a caller was becoming irate.

"The duo built a computer algorithm that allows us to listen to an auditory signal from a human, analyse it and assess the emotional state of the speaker," said competition judge Gert Lanckriet from the department of electrical and computer engineering, University of California, San Diego.

"It can help identify if the speaker is angry, sad, bored, anxious or happy. They came up with a strong creative idea and brought it from theory into practice."

"Using an emotional speech database with 18,215 files and five emotions -- anger, positive, neutral, emphatic, rest-the team developed, trained and tested a classification engine to determine emotions from an input signal," he said.

Lanckriet said that their work could even be used to enhance
cellphone technology.

"In cell phones, most of the encoding is designed to ensure words are understood, but the emotional background of the conversation may be lost. Krishnan and Matthew's work could help ensure that the emotion comes through," he said.

Krishnan was not the only one in the competition who has his roots in India. Three other students of Indian origin-Santosh Narayan of Munster, Indiana, Nikhil Mehandru of Roslyn, New York and Sonia Prasad of Roslyn Heights, New York-bagged the fourth position in the team category in the national championship and were awarded a $30,000 scholarship.

China reveals world's fastest train

China played host to railway authorities and railway experts from around the world in Beijing , and used the opportunity to showcase a high-speed train that clocked the fastest ever speed in a test run last week.

In the spotlight is the 16-car CRH380A, a new generation of high-speed train which Chinese Ministry of Railways officials say recorded a top speed of 486.1 kilometers per hour on Friday, far exceeding Japan's bullet trains.

Chinese railway officials say the CRH380A, designed to operate at a cruising speed of 380 kph, is the fastest train in operation in the world today.

China is reportedly in the process of developing a super high-speed train that can run at 600 kph.

China South Locomotive & Rolling Stock Corp., which designed the CRH380A, was clearly the focus attention as foreign railway experts toured an international exhibition of railway technology organised by the Ministry of Railways on the sidelines of a world congress on high speed rail.

After attending a briefing by China South Locomotive, an Iranian government official said Iran is considering buying the Chinese high-speed train.

"We definitely want to import it," an Israeli railways executive also said.

Railways executives from the US State of California also listened attentively as China South Locomotive officials briefed the international visitors.

China boasts the world's longest high-speed railway network, which totals 7,531 km, and Chinese railway officials say the country plans to expand the system to 16,000 km by 2020.

The exhibition, held at the China National Convention Center in Beijing, has drawn entries from more than 200 companies worldwide, each showcasing its wares and know-how to a global audience of railway experts and transport officials.

Twelve common mistakes done by programmers

Most often, software developers seem locked into certain failure modes that can't be avoided and such is the frequency with which they fall prey to a particular poor programming practice. Peter Wayner of Computerworld writes about twelve most common programming mistakes, each of which is accompanied by its opposing pair. Below are the twelve programming pitfalls developers should stay away from.

Playing it fast and loose
Failing to prop up the basics is the easiest way to make errors in coding. There are a lot of small places where a developer may make a mistake which causes software to fail. And the worst part about sloppy programming is that advances in language design aimed to fix these problems don't do their job. There have been improvements in syntax in programming languages. For instance, the latest version of Java tries to make null-pointer checking easier by offering shorthand syntax for the endless pointer testing. But such syntax improvements can only prevent code from crashing. They don't eliminate the root of the problem: the proliferation of null values due to fast and loose programming.

Overcommitting to details
On the flip side, overly buttoned-up software can slow to a crawl. Relentless devotion to detail can even lock up software if the obsessive checking requires communicating with a distant website over the network. Here, the challenge is to design the layers of code to check the data when it first appears, which is much easier said than done.

Not simplifying control
Not simplifying control over tasks in their code may invite disaster for developers. The software assumes that if someone creates an object of type Name with two fields first and last, then it should immediately create a database table called Name with two columns, first and last. The names are specified in only one place, avoiding any problems that might come if someone fails to keep all of the layers of configuration in sync.

Delegating too much to frameworks
Sometimes the magic tools lead only to confusion. By abstracting functionality and assuming what we want, frameworks can all too often leave developers at a loss for what's gone wrong in their code. The rules are, while quite reasonable, not entirely trivial. As the app grows, it depends on more and more of these almost-trivial bits of external knowledge.

Trusting the client
Many of the worst security bugs appear when developers assume the client device will do the right thing. For example, code written to run in a browser can be rewritten by the browser to execute any arbitrary action. If the developer doesn't double-check all of the data coming back, anything can go wrong.

Not trusting the client enough
Sometimes too much security can lead paradoxically to gaping holes. Because of this, many Web developers are looking to reduce security as much as possible, not only to make it easy for people to engage with their products but also to save them the trouble of defending more than the minimum amount of data necessary to set up an account.

Relying too heavily on magic boxes
Many programmers assume they can link in the encryption library, push a button, and have iron-clad security. But many of these magic algorithms have subtle weaknesses, and avoiding these weaknesses requires learning more than what's in the Quick Start section of the manual.

Reinventing the wheel
Then again, writing your own libraries just because you think you know a better way to code can come back to haunt you. But grow-your-own cryptography is a welcome sight to attackers. Many libraries don't need to be perfect, so grabbing a magic box is more likely to be better than the code you write yourself.

Opening up too much to the user
Placing the onus on users to customize functionality they do not fully understand can invite disaster in the form of inadvertent security holes and privacy violations. When making purchasing decisions, most users can't handle the breadth of features offered by any given piece of software.

Over determining the user experience
Some developers decide to avoid the trouble of too many features by offering exactly one solution. But if users don't like the idea, they will look for ways to work around these limitations, and it will lead to an outcome that could translate into security vulnerabilities.


Closing the source
The decision to not distribute code works against the integrity of that code and it can discourage innovation and fixing bugs. Just opening up the code forces you to make the info more accessible, understandable, and thus better.

Assuming openness is a cure-all
While openness can make it possible for others to pitch in and, thus, improve your code, the mere fact that it's open won't do much unless there's another incentive for outside contributors to put in the work. Opening up a project can also add new overhead for communications and documentation. Moreover, a good open source project comes with extensive documentation of the API and road maps for future development.

Facebook was my idea, not Mark Zuckerberg's - Claims an Indian

A 28 year old, Divya Narendra, son of an Indian immigrant doctor couple in the U.S., has moved to courtroom in battle with Facebook CEO Mark Zuckerberg. He believes that he, and not Mark Zuckerberg, came up with the idea of social networking website Facebook, reports Ishani Duttagupta from The Economic Times.

Narendra, along with his former Harvard University classmates Tyler Winklevoss and Cameron Winklevoss, has charged Zuckerberg with stealing the idea they conceived over a year, when they were students at Harvard University.
Who is the owner of Facebook? Court to decide

"I spent almost one year developing the concept and searching for programmers (along with the Winklevoss twins) to build what was then called Harvard-Connection.com (a social network for Harvard students which was to expand to other schools). When I heard about Mark Zuckerberg for the first time in the fall of 2003, he seemed like a natural fit to join our team. Three months later, Facebook launched and all the time and effort I had put into my vision had been taken away," Narendra said.

He and the twins first tried to convince Harvard's administrative board and president (Larry Summers) to take action against Zuckerberg. But they had to file a lawsuit as the matter was outside the jurisdiction of the university. While an initial settlement had been reached in the suit, reportedly at $65 million, it was reopened in May 2010. If the current suit goes in favour of Narendra and his friends, the value of the settlement could escalate to about $466 million.