habeanf

Apologies, could you add yet more clarity? According to the blog post your results are:

Parser Accuracy Speed (w/s) Language LOC

Stanford 89.6% 19 Java > 50,000[1]

parser.py 89.8% 2,020 Python ~500

Redshift 93.6% 2,580 Cython ~4,000

Are these the labeled parsing results you are referring to? How many sents/sec? Using same PTB data sets as Zhang and Nivre '11?

You can do better than O(cfkn). You can precompute the results of some features seen together (i.e. S0w/S0t/S0wt), and store a ref to them on the words. This saves feature lookups per feature. If you store them as vectors for the classes, you can get a nice perf. boost from SIMD.. you can knock off at least an order of magnitude if not two. something like O(c'f'kn), where c' is the # of SIMD ops to aggregate pre computed weight vectors and f' is the number of feature template groups. Also Yoav Goldberg mentioned feature signatures in one of his papers which can do a bit better.

A significant problem with unlabeled dep. parsing is that you can't differentiate important things like subject vs object dependents. In the sentence "They ate the pizza with anchovies.", how would a program distinguish between 'they' as the subject and 'pizza' as the object? In other words, who ate what?

First things first: hats off on a concise, accurate and efficient implementation in python.

But the Cython parser is not doing labeled parsing.. a significant number of feature templates are relevant to labeled parsing.

To reach Nivre and Zhang's 2011 results I think you'll find labeled parsing will degrade performance significantly and you'll need more complex code

1. you have more than an order of magnitude more transitions (80 vs 4)

2. you need to add beam search, with early update for training. beam size = 64 to be consistent with zpar

3. an order of magnitude more feature templates, with more complex features

So now you'll be evaluating 20x more transitions, on ~64x more candidates, with ~10x more feature templates. You can't multithread properly in python, you can maybe get some more juice by using some form of SIMD (w/ or w/o GPU). Your model is much larger in memory, so any luck you had in L2/L3 caching is probably gone. Python has limits and this is the point you start hitting them.

Edit: I see you've updated your comment, I guess we're on the same page. It's nice to see a concise implementation. I wrote one in golang for my masters thesis. I achieved perfect parity with zpar, but it took two order of magnitude more LOC.

State of the art research indicates that joint processing (segmentation, tagging and syntactic analysis) achieves better results than a pipeline model. For an example, see Hatori et al: http://aclweb.org/anthology//P/P12/P12-1110.pdf

Also, OPs model only runs unlabeled dependency parsing. Most applications require labeled dependency parsing, which is much harder. State of the art results for English are currently ~93% established by Joakim Nivre and Yue Zhang in http://www.sutd.edu.sg/cmsresource/faculty/yuezhang/acl11j.p... and based on the zpar parser framework (see http://www.cl.cam.ac.uk/~sc609/pubs/cl11_early.pdf ).

zpar ( http://sourceforge.net/projects/zpar/ ) is the fastest dependency parser I am aware of, and it achieves lower parsing rates.

In all papers, note how many more feature templates are specified. More recent work contains yet another order of magnitude more feature templates. I'm betting python (w/ or w/o Cython) won't last very long as competition.

All that being said, the most significant problem in this part of NLP is that the best corpus files required for training modern accurate models are very expensive to license for both research and commercial purposes (tens if not hundreds of thousands of $s).

Sometimes a need arises for browser-based apps that are not on the net, usually as part of a system installed at a location without access to public internet for various reasons.

If these systems are planned to have a life time of say 5-7 years, it would be best to not start developing parts of them with libraries and frameworks that are due to be phased out in just 2 or 3 years.

E.g. AngularJS, the writing is clearly on the wall. Google are investing in a number of libraries and technologies that are the "next thing": Polymer, Dart, Web Components + Shadow DOM in Chrome etc. It appears that in the big picture AngularJS is a stepping stone, which is a problem when you plan on building something that should be supportable for 5+ years.

Remember GWT? 5 years ago it was all the rage. At the 2012 Google I/O event they announced they're handing over control to a steering committee - their way of letting go and moving on. Imagine if you needed to continue supporting GWT based code for another few years, when the catalyst for the technology are phasing it out themselves. The worst part of this is the lack of developers - they see Google dumping GWT and stop learning about it. How do you hire developers to continue maintaining your software? This should qualify as being "in a rut".

So it begs the question, should an organization start using AngularJS (or any other fashionable framework trend) for long-term support systems? If so, how should one decide?

I volunteer at the Public Knowledge Foundation (an Israeli version of The Sunlight Foundation), we develop and maintain oknesset.org (like opencongress.org). For the past couple months we've been researching the possibility of representing Israeli law as a git repository, so that oknesset.org can visualize the diff to a law a bill proposal represents, and track it as a branch until it is merged into law. Since Israel is a relatively young and small country the number of laws and changes is orders of magnitude smaller than most western/democratic countries which publicize the legislative process. Israel's legislative branch is unicameral so the process itself is relatively straightforward; supposedly we'd be a good test case. We already have quite a lot of insight but in general it seems that git (and generally, any VCS) has significant impedance mismatch with the legislative process, specifically regarding the ability to compile/link all the different laws into one comprehensive database representing the law. One prominent example is the existence of multiple timelines of ratification. There are at least three dates relevant to the ratification of bills:

1. Date of third (and final) vote = the date the parliament has voted a bill as law

2. Date of publication (for technical reasons this might not coincide with the vote date)

3. Date of validity - a bill is usually passed with a date of validity, between the date of publication and validity the bill is not formally law yet. Sometimes there are separate dates of validity for separate parts of the bill. To make matters more complicated, dates of validity can be changed when the bill designates government ministers with the authority to change them (the dates).

Also, in Israel many laws never "make it" to their date of validity since the yearly Law of Arrangements (http://www.knesset.gov.il/lexicon/eng/hesderim_eng.htm) decides which laws passed in the previous year have proper funding, such that officially some laws get "punted" into the future, possibly indefinitely. It gets quite confusing because from a legal point of view, the dates that are relevant to the justice system (as in, when a bill is relevant or not to the court) are usually the date of voting, whereas when it comes to government the third date is the important one.

We are still moving forward with our initiative, but it seems that for now there are no version control systems which are a good solution to the law management problem.

(edited for formatting)

The Century of the Self by Adam Curtis http://www.youtube.com/watch?v=UcYBSXgtmKQ - Episode 1 of 4, the rest are also on youtube

It's a bit tendentious but overall insightful and interesting IMO.

RAC uses shared disks (http://www.oracle.com/technetwork/database/clustering/overvi...) So unless EBS or an EBS-like service will allow the attachment of a volume to multiple instances or Oracle changes how RAC works, there won't be Oracle RAC on AWS.