Talk:CYK algorithm

message: I don't like this article because it gives an example about categorizing NP(noun phrase) VP(verb phrase) and so forth, and this would be useful for someone who wanted to build a POS tagger.
However, this article is not about POS taggers, it's about CYK, so examples should be given with that in mind.
Just give a grammar, and a word, and have various states of the matrix P for the example.
Not that complicated.  —Preceding unsigned comment added by 188.26.48.167 (talk) 12:56, 23 January 2011 (UTC)
replies: text: The example given is for parsing sentences into NP, VP and so on, which is more than part-of-speech tagging. It may be more common to introduce CYK with artificial examples, but I don't see anything wrong with using an example from an application area. Computational linguistics is one of the areas where CYK is applied, and CYK is sometimes studied as part of a CL curriculum. But I've reconstructed the grammar from the example and added it to the article. It should now make more sense. -- UKoch (talk) 17:25, 20 December 2011 (UTC)
thread_title: I don't like the article

message: The fact that binary form (no RHS longer than 2) should be used, rather than CNF has been known for about 40 years. It was not published, because it was considered obvious, as the complexity results from the length of right-hand sides. It is also the only way to preserve conveniently the shape of parse trees.
Beau Shiel had a nice paper about it at Coling 76. The empty word is a problem that cannot be escaped, if parse-trees are to be preserved, which is implied by the name parser (but sometimes not described with the algorithm).  If no parse tree is kept, it is a recognizer.
The size of a grammar should be defined explicitly, or a reference given.Teetooan (talk) 20:32, 27 February 2014 (UTC)
thread_title:  I think there is still much room for improvement 

message: Original threadstarter did not title this thread. --131.234.234.12 (talk) 11:59, 23 January 2009 (UTC)
thread_title: Give examples!

message: : Done. Ceroklis 10:01, 26 September 2007 (UTC)
thread_title:  Another article on CYK 

message: So far, I have come across three different names for letter C:
* Cook
* Cocke
* Coke
Which one is correct?
—Preceding unsigned comment added by 89.133.45.42 (talk • contribs) 21:36, 21 June 2007
: Cocke, according to the Jurafsky and Martin book.  Ealdent 15:26, 23 October 2007 (UTC)
thread_title:  What does C stand for in CYK? 

message: I'm almost sure there is a mistake in the algorithm,
but I'll write it here first just in case...
The line:
"Let the grammar contain r terminal and nonterminal symbols R1 ... Rr."
should be:
"Let the grammar contain r nonterminal symbols R1 ... Rr."
There is no need to consider the terminals also.
Sararkd (talk) 02:37, 18 January 2008 (UTC)
thread_title:  Mistake in the Algorithm? 

message: Is there any objection to changing the algorithm indexing from 1-indexed to 0-indexed? This would make converting from pseudocode to real code much easier.  —Preceding unsigned comment added by Jhm718 (talk • contribs) 11:40, 24 April 2009 (UTC)
thread_title:  Change algorithm indexing 

message: Is there any good reason for naming the input string Carlos? It seems silly and irrelevant to me.
Sigurdmeldgaard (talk) 08:34, 17 May 2009 (UTC)
thread_title:  Why "Carlos" 

message: External Link to "CYK parsing demo in JavaScript" (http://homepages.uni-tuebingen.de/student/martin.lazarov/demos/cky.html) is broken.
A short search didn't result in any alternative location.
I haven't removed the link, since maybe it's a temporary problem (don't think so) and maybe someone else might come up with something.
--84.109.241.65 (talk) 05:08, 27 December 2010 (UTC)
thread_title:  403 Access Forbidden 

message: I think it should be 
set P[i,1,j] = true
instead of 
set P[i,i,j] = true
if the second index denotes the length of a span.  —Preceding unsigned comment added by 93.138.47.91 (talk) 00:58, 7 May 2011 (UTC)
thread_title:  Mistake in the Algorithm? 

message: I'm not aware of any literature that mentions |G|. Of course the actual time the algorithm takes depends on the "size" of the grammar (I assume |G| is supposed to be the number of productions), but in this kind of problem, I've only ever seen n mentioned. In particular, in the pseudocode given, the loop over all productions is unnecessary, or at least unnecessarily specific: One would implement that as a hash table lookup, which is much faster. -- My point: If nobody disagrees, I'll erase the |G| part. -- UKoch (talk) 22:14, 9 December 2011 (UTC)
thread_title:  |G| in time complexity 

message: In the article, the CYK algorithm is called the most efficient parsing algorithm in terms of worst-case asymptotic complexity. Where does that come from? As discussed above, the time complexity is O(n^3), and Hopcroft and Ullman mention Earley parsing, which has the same time complexity, and they write that there's an algorithm whose time complexity is O(n^{2.8}), and another one whose time complexity is O(n^3/\log n). (Of course, they give sources for all of these.) I'll remove the "ost efficient" part if no-one objects. -- UKoch (talk) 17:38, 14 December 2011 (UTC)
replies: text: I changed "the most efficient parsing algorithm" to "one of the most efficient parsing algorithms". -- UKoch (talk) 14:08, 20 December 2011 (UTC)
thread_title:  Most efficient parsing algorithm? 

message: I tried to fix the broken link in the external links section as well as adding a visualization I published on my site: https://www.xarg.org/tools/cyk-algorithm/
Unfortunately, the change was reverted automatically as I got explained here: https://en.wikipedia.org/wiki/User_talk:Xarg 
However, as I wrote, I don't think this is an advertising other than bringing in a valuable reference to Wikipedia and so I would be glad if you add the link permanently if the resource meeds your quality demands. I assure that this link will be available and that I own the site.  — Preceding unsigned comment added by Xarg (talk • contribs) 03:04, 21 July 2018 (UTC)
thread_title:  External Links 

message: Aside from the fact that one-letter variable names obfuscate meaning and are difficult to follow, having a lowercase letter L in a font where it looks nearly identical for the numeral for "one" (cf. l and 1) only compounds the issue. Antigravity711 (talk) 17:06, 27 January 2020 (UTC)
thread_title:  Pseudocode Difficult to Read