Posts from May 2016
Coding has begun for Google Summer of Code 2016
Monday, May 23, 2016
Today marks the start of coding for the 12th annual Google Summer of Code. With the community bonding period complete, about 1,200 students now begin 12 weeks of writing code for 178 different open source organizations.
We are excited to see the contributions this year’s students will make to the open source community.
For more information on important dates for the program please visit our timeline. Stay tuned as we will highlight some of the new mentoring organizations over the next few months.
Have a great summer and happy coding!
By Josh Simmons, Open Source Programs Office
Google Summer of Code 2016 statistics: Part one
We share statistics from Google Summer of Code (GSoC) every year — now that 2016 is chugging along we’ve got some exciting numbers to share! 1,206 students from all over the globe are currently in the community bonding period, a time where participants learn more about the organization they will be contributing to before coding officially begins on May 23. This includes becoming familiar with the community practices and processes, setting up a development environment, or contributing small (or large) patches and bug fixes.
We’ll start our statistics reporting this year with the total number of students participating from each country:
We’d like to welcome a new country to the GSoC family. 2016 brings us one student from Albania!
In our upcoming statistics posts, we will delve deeper into the numbers by looking at universities with the most accepted students, gender numbers, mentor countries and more. If you have additional statistics that you would like us to share, please leave a comment below and we will consider including them in an upcoming post.
By Mary Radomile, Open Source Programs
Correction: A previous version of this blog post erroneously reported the total number of students as 1,202 and the number of students from Cameroon as 1. This has been updated to reflect the actual totals as 1,206 and 16 respectively.
We’ll start our statistics reporting this year with the total number of students participating from each country:
Country | Accepted Students | Country | Accepted Students | Country | Accepted Students |
Albania |
1
|
Greece |
10
|
Romania |
31
|
Algeria |
1
|
Guatemala |
1
|
Russian Federation |
52
|
Argentina |
3
|
Hong Kong |
2
|
Serbia |
2
|
Armenia |
3
|
Hungary |
7
|
Singapore |
7
|
Australia |
6
|
India |
454
|
Slovak Republic |
3
|
Austria |
19
|
Ireland |
3
|
Slovenia |
4
|
Belarus |
5
|
Israel |
2
|
South Africa |
2
|
Belgium |
5
|
Italy |
23
|
South Korea |
6
|
Bosnia-Herzegovina |
1
|
Japan |
12
|
Spain |
33
|
Brazil |
21
|
Kazakhstan |
2
|
Sri Lanka |
54
|
Bulgaria |
2
|
Kenya |
3
|
Sweden |
5
|
Cambodia |
1
|
Latvia |
3
|
Switzerland |
2
|
Cameroon |
16
|
Lithuania |
1
|
Taiwan |
7
|
Canada |
23
|
Luxembourg |
1
|
Thailand |
1
|
China |
34
|
Macedonia |
1
|
Turkey |
12
|
Croatia |
2
|
Mexico |
2
|
Ukraine |
13
|
Czech Republic |
6
|
Netherlands |
9
|
United Kingdom |
18
|
Denmark |
2
|
New Zealand |
2
|
United States |
118
|
Egypt |
10
|
Pakistan |
4
|
Uruguay |
1
|
Estonia |
1
|
Paraguay |
1
|
Venezuela |
1
|
Finland |
3
|
Philippines |
2
|
Vietnam |
4
|
France |
19
|
Poland |
28
|
||
Germany |
66
|
Portugal |
7
|
We’d like to welcome a new country to the GSoC family. 2016 brings us one student from Albania!
In our upcoming statistics posts, we will delve deeper into the numbers by looking at universities with the most accepted students, gender numbers, mentor countries and more. If you have additional statistics that you would like us to share, please leave a comment below and we will consider including them in an upcoming post.
By Mary Radomile, Open Source Programs
Correction: A previous version of this blog post erroneously reported the total number of students as 1,202 and the number of students from Cameroon as 1. This has been updated to reflect the actual totals as 1,206 and 16 respectively.
Announcing SyntaxNet: The World’s Most Accurate Parser Goes Open Source
Friday, May 13, 2016
Originally posted on the Google Research Blog
By Slav Petrov, Senior Staff Research Scientist
At Google, we spend a lot of time thinking about how computer systems can read and understand human language in order to process it in intelligent ways. Today, we are excited to share the fruits of our research with the broader community by releasing SyntaxNet, an open-source neural network framework implemented in TensorFlow that provides a foundation for Natural Language Understanding (NLU) systems. Our release includes all the code needed to train new SyntaxNet models on your own data, as well as Parsey McParseface, an English parser that we have trained for you and that you can use to analyze English text.
Parsey McParseface is built on powerful machine learning algorithms that learn to analyze the linguistic structure of language, and that can explain the functional role of each word in a given sentence. Because Parsey McParseface is the most accurate such model in the world, we hope that it will be useful to developers and researchers interested in automatic extraction of information, translation, and other core applications of NLU.
How does SyntaxNet work?
SyntaxNet is a framework for what’s known in academic circles as a syntactic parser, which is a key first component in many NLU systems. Given a sentence as input, it tags each word with a part-of-speech (POS) tag that describes the word's syntactic function, and it determines the syntactic relationships between words in the sentence, represented in the dependency parse tree. These syntactic relationships are directly related to the underlying meaning of the sentence in question. To take a very simple example, consider the following dependency tree for Alice saw Bob:
This structure encodes that Alice and Bob are nouns and saw is a verb. The main verb saw is the root of the sentence and Alice is the subject (nsubj) of saw, while Bob is its direct object (dobj). As expected, Parsey McParseface analyzes this sentence correctly, but also understands the following more complex example:
This structure again encodes the fact that Alice and Bob are the subject and object respectively of saw, in addition that Alice is modified by a relative clause with the verb reading, that saw is modified by the temporal modifier yesterday, and so on. The grammatical relationships encoded in dependency structures allow us to easily recover the answers to various questions, for example whom did Alice see?, who saw Bob?, what had Alice been reading about? or when did Alice see Bob?.
Why is Parsing So Hard For Computers to Get Right?
One of the main problems that makes parsing so challenging is that human languages show remarkable levels of ambiguity. It is not uncommon for moderate length sentences - say 20 or 30 words in length - to have hundreds, thousands, or even tens of thousands of possible syntactic structures. A natural language parser must somehow search through all of these alternatives, and find the most plausible structure given the context. As a very simple example, the sentence Alice drove down the street in her car has at least two possible dependency parses:
The first corresponds to the (correct) interpretation where Alice is driving in her car; the second corresponds to the (absurd, but possible) interpretation where the street is located in her car. The ambiguity arises because the preposition in can either modify drove or street; this example is an instance of what is called prepositional phrase attachment ambiguity.
Humans do a remarkable job of dealing with ambiguity, almost to the point where the problem is unnoticeable; the challenge is for computers to do the same. Multiple ambiguities such as these in longer sentences conspire to give a combinatorial explosion in the number of possible structures for a sentence. Usually the vast majority of these structures are wildly implausible, but are nevertheless possible and must be somehow discarded by a parser.
SyntaxNet applies neural networks to the ambiguity problem. An input sentence is processed from left to right, with dependencies between words being incrementally added as each word in the sentence is considered. At each point in processing many decisions may be possible—due to ambiguity—and a neural network gives scores for competing decisions based on their plausibility. For this reason, it is very important to use beam search in the model. Instead of simply taking the first-best decision at each point, multiple partial hypotheses are kept at each step, with hypotheses only being discarded when there are several other higher-ranked hypotheses under consideration. An example of a left-to-right sequence of decisions that produces a simple parse is shown below for the sentence I booked a ticket to Google.
Furthermore, as described in our paper, it is critical to tightly integrate learning and search in order to achieve the highest prediction accuracy. Parsey McParseface and other SyntaxNet models are some of the most complex networks that we have trained with the TensorFlow framework at Google. Given some data from the Google supported Universal Treebanks project, you can train a parsing model on your own machine.
So How Accurate is Parsey McParseface?
On a standard benchmark consisting of randomly drawn English newswire sentences (the 20 year old Penn Treebank), Parsey McParseface recovers individual dependencies between words with over 94% accuracy, beating our own previous state-of-the-art results, which were already better than any previous approach. While there are no explicit studies in the literature about human performance, we know from our in-house annotation projects that linguists trained for this task agree in 96-97% of the cases. This suggests that we are approaching human performance—but only on well-formed text. Sentences drawn from the web are a lot harder to analyze, as we learned from the Google WebTreebank (released in 2011). Parsey McParseface achieves just over 90% of parse accuracy on this dataset.
While the accuracy is not perfect, it’s certainly high enough to be useful in many applications. The major source of errors at this point are examples such as the prepositional phrase attachment ambiguity described above, which require real world knowledge (e.g. that a street is not likely to be located in a car) and deep contextual reasoning. Machine learning (and in particular, neural networks) have made significant progress in resolving these ambiguities. But our work is still cut out for us: we would like to develop methods that can learn world knowledge and enable equal understanding of natural language across all languages and contexts.
To get started, see the SyntaxNet code and download the Parsey McParseface parser model. Happy parsing from the main developers, Chris Alberti, David Weiss, Daniel Andor, Michael Collins & Slav Petrov.
By Slav Petrov, Senior Staff Research Scientist
At Google, we spend a lot of time thinking about how computer systems can read and understand human language in order to process it in intelligent ways. Today, we are excited to share the fruits of our research with the broader community by releasing SyntaxNet, an open-source neural network framework implemented in TensorFlow that provides a foundation for Natural Language Understanding (NLU) systems. Our release includes all the code needed to train new SyntaxNet models on your own data, as well as Parsey McParseface, an English parser that we have trained for you and that you can use to analyze English text.
Parsey McParseface is built on powerful machine learning algorithms that learn to analyze the linguistic structure of language, and that can explain the functional role of each word in a given sentence. Because Parsey McParseface is the most accurate such model in the world, we hope that it will be useful to developers and researchers interested in automatic extraction of information, translation, and other core applications of NLU.
How does SyntaxNet work?
SyntaxNet is a framework for what’s known in academic circles as a syntactic parser, which is a key first component in many NLU systems. Given a sentence as input, it tags each word with a part-of-speech (POS) tag that describes the word's syntactic function, and it determines the syntactic relationships between words in the sentence, represented in the dependency parse tree. These syntactic relationships are directly related to the underlying meaning of the sentence in question. To take a very simple example, consider the following dependency tree for Alice saw Bob:
This structure encodes that Alice and Bob are nouns and saw is a verb. The main verb saw is the root of the sentence and Alice is the subject (nsubj) of saw, while Bob is its direct object (dobj). As expected, Parsey McParseface analyzes this sentence correctly, but also understands the following more complex example:
This structure again encodes the fact that Alice and Bob are the subject and object respectively of saw, in addition that Alice is modified by a relative clause with the verb reading, that saw is modified by the temporal modifier yesterday, and so on. The grammatical relationships encoded in dependency structures allow us to easily recover the answers to various questions, for example whom did Alice see?, who saw Bob?, what had Alice been reading about? or when did Alice see Bob?.
Why is Parsing So Hard For Computers to Get Right?
One of the main problems that makes parsing so challenging is that human languages show remarkable levels of ambiguity. It is not uncommon for moderate length sentences - say 20 or 30 words in length - to have hundreds, thousands, or even tens of thousands of possible syntactic structures. A natural language parser must somehow search through all of these alternatives, and find the most plausible structure given the context. As a very simple example, the sentence Alice drove down the street in her car has at least two possible dependency parses:
The first corresponds to the (correct) interpretation where Alice is driving in her car; the second corresponds to the (absurd, but possible) interpretation where the street is located in her car. The ambiguity arises because the preposition in can either modify drove or street; this example is an instance of what is called prepositional phrase attachment ambiguity.
Humans do a remarkable job of dealing with ambiguity, almost to the point where the problem is unnoticeable; the challenge is for computers to do the same. Multiple ambiguities such as these in longer sentences conspire to give a combinatorial explosion in the number of possible structures for a sentence. Usually the vast majority of these structures are wildly implausible, but are nevertheless possible and must be somehow discarded by a parser.
SyntaxNet applies neural networks to the ambiguity problem. An input sentence is processed from left to right, with dependencies between words being incrementally added as each word in the sentence is considered. At each point in processing many decisions may be possible—due to ambiguity—and a neural network gives scores for competing decisions based on their plausibility. For this reason, it is very important to use beam search in the model. Instead of simply taking the first-best decision at each point, multiple partial hypotheses are kept at each step, with hypotheses only being discarded when there are several other higher-ranked hypotheses under consideration. An example of a left-to-right sequence of decisions that produces a simple parse is shown below for the sentence I booked a ticket to Google.
Furthermore, as described in our paper, it is critical to tightly integrate learning and search in order to achieve the highest prediction accuracy. Parsey McParseface and other SyntaxNet models are some of the most complex networks that we have trained with the TensorFlow framework at Google. Given some data from the Google supported Universal Treebanks project, you can train a parsing model on your own machine.
So How Accurate is Parsey McParseface?
On a standard benchmark consisting of randomly drawn English newswire sentences (the 20 year old Penn Treebank), Parsey McParseface recovers individual dependencies between words with over 94% accuracy, beating our own previous state-of-the-art results, which were already better than any previous approach. While there are no explicit studies in the literature about human performance, we know from our in-house annotation projects that linguists trained for this task agree in 96-97% of the cases. This suggests that we are approaching human performance—but only on well-formed text. Sentences drawn from the web are a lot harder to analyze, as we learned from the Google WebTreebank (released in 2011). Parsey McParseface achieves just over 90% of parse accuracy on this dataset.
While the accuracy is not perfect, it’s certainly high enough to be useful in many applications. The major source of errors at this point are examples such as the prepositional phrase attachment ambiguity described above, which require real world knowledge (e.g. that a street is not likely to be located in a car) and deep contextual reasoning. Machine learning (and in particular, neural networks) have made significant progress in resolving these ambiguities. But our work is still cut out for us: we would like to develop methods that can learn world knowledge and enable equal understanding of natural language across all languages and contexts.
To get started, see the SyntaxNet code and download the Parsey McParseface parser model. Happy parsing from the main developers, Chris Alberti, David Weiss, Daniel Andor, Michael Collins & Slav Petrov.
Googlers on the road: OSCON 2016 in Austin
Monday, May 9, 2016
Developers and open source enthusiasts converge on Austin, Texas in just under two weeks for O’Reilly Media’s annual open source conference, OSCON, and the Community Leadership Summit (CLS) that precedes it. CLS runs May 14-15 at the Austin Convention Center followed by OSCON from May 16-19.
OSCON 2014 program chairs including Googler Sarah Novotny. Photo licensed by O'Reilly Media under CC-BY-NC 2.0. |
This year we have 10 Googlers hosting sessions covering topics including web development, machine learning, devops, astronomy and open source. A list of all of the talks hosted by Googlers alongside related events can be found below.
If you’re a student, educator, mentor, past or present participant in Google Summer of Code or Google Code-in, or just interested in learning more about the two programs, make sure to join us Monday evening for our Birds of a Feather session.
Have questions about Kubernetes, Google Summer of Code, open source at Google or just want to meet some Googlers? Stop by booth #307 in the Expo Hall.
Thursday, May 12th - GDG Austin
Sunday, May 15th - Community Leadership Summit
Monday, May 16th
Tuesday, May 17th
Wednesday, May 18th
1:50pm Open source lessons from the TODO Group by Chris DiBona, Chris Aniszczyk, Nithya Ruff, Jeff McAffer and Benjamin VanEvery
Thursday, May 19th
11:00am Kubernetes hackathon at OSCON Contribute hosted by Brian Dorsey, Nikhil Jindal, Janet Kuo, Jeff Mendoza, John Mulhausen, Sarah Novotny, Terrence Ryan and Chao Xu
11:00am Kubernetes hackathon at OSCON Contribute hosted by Brian Dorsey, Nikhil Jindal, Janet Kuo, Jeff Mendoza, John Mulhausen, Sarah Novotny, Terrence Ryan and Chao Xu
5:10pm PANOPTES: Open source planet discovery by Jennifer Tong and Wilfred Gee
Haven’t registered for OSCON yet? You can knock 25% off the cost of registration by using discount code Google25, or attend parts of the event including our Birds of a Feather session for free by using discount code OSCON16XPO.
See you at OSCON!
By Josh Simmons, Open Source Programs Office
XRay: a function call tracing system
Tuesday, May 3, 2016
At Google we spend a lot of time debugging and tuning the performance of our production systems. Some standard practices when doing this involves using profilers, debuggers, and analysis of logs and execution traces. Doing this at scale, in production, is difficult. One of the ways for getting high fidelity data from production systems is to build applications with instrumentation, and then reconstruct the instrumentation data into a form humans can consume (summary statistics, reports, etc.). Instrumentation comes at a cost though, sometimes too high to make it feasible to deploy in production.
Getting this balance right is hard. This is why we've developed XRay, a function call tracing system that has very little overhead when not enabled, but can be dynamically turned on and only impose moderate costs. XRay works as a combination of compiler-inserted instrumentation points which functionally do nothing (called "nop sleds") and a library that can be enabled and disabled at runtime which replaces the nop sleds with the appropriate instrumentation instructions.
We've been using XRay to debug internal systems, from core infrastructure services like Bigtable to ad serving systems. XRay's detailed function tracing has enabled several teams in Google to debug issues that would be really hard to solve without XRay.
We think XRay is an important piece of technology, not only at Google, but for developers around the world. It's because of this that we're working on making XRay opensource. To kick-start that process, we're releasing a white paper describing the technical details of XRay. In the following weeks, we will be engaging the LLVM community, where we are committed to making XRay available for wide use and distribution.
We hope that by open-sourcing XRay we can contribute to the advancement of debugging real-world applications. We're looking forward to working with the LLVM community and other projects to make the data XRay generates useful for debugging a wide variety of applications.
By Dean Michael Berris, Google Engineering
Getting this balance right is hard. This is why we've developed XRay, a function call tracing system that has very little overhead when not enabled, but can be dynamically turned on and only impose moderate costs. XRay works as a combination of compiler-inserted instrumentation points which functionally do nothing (called "nop sleds") and a library that can be enabled and disabled at runtime which replaces the nop sleds with the appropriate instrumentation instructions.
We've been using XRay to debug internal systems, from core infrastructure services like Bigtable to ad serving systems. XRay's detailed function tracing has enabled several teams in Google to debug issues that would be really hard to solve without XRay.
We think XRay is an important piece of technology, not only at Google, but for developers around the world. It's because of this that we're working on making XRay opensource. To kick-start that process, we're releasing a white paper describing the technical details of XRay. In the following weeks, we will be engaging the LLVM community, where we are committed to making XRay available for wide use and distribution.
We hope that by open-sourcing XRay we can contribute to the advancement of debugging real-world applications. We're looking forward to working with the LLVM community and other projects to make the data XRay generates useful for debugging a wide variety of applications.
By Dean Michael Berris, Google Engineering