Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Natural Language Processing for the Working Programmer

nlpwp.org

Post reply on HN
Print view View original

41–48 of 48 posts

Re: Natural Language Processing for the Working Programmer

#41

Post by fusiongyro »

eric_bullington wrote: post #40
fusiongyro wrote: post #17

Earlier quoted context omitted.

What worked for me was going through worked examples with IO, List, Maybe and State. You don't want to just do List, Maybe and Either or you'll associate it with holding onto particular data. You want to use highly disparate things so you can get to the fully abstract understanding. You might try to understand monoids first, because you already have familiarity with many applications of monoids. The realization "oh,…

Thanks so much for your advice -- much appreciated. I've pulled back out my copy of Learn You a Haskell and have just re-read the Haskell wikibook chapter on monads.

No problem. Feel free to drop me an email if you get stuck.

Re: Natural Language Processing for the Working Programmer

#42

Post by PeterisP »

bane wrote: post #3
nubela wrote: post #2

I was working with NLP, and its various toolkits (python-nltk I'm looking at you). The thing about NLP is, there just isn't enough libraries (for humans) to simply plug NLP into use. Even nltk, the premier python library for NLP, seems to be an NLP core-library for building NLP solutions, rather than for building NLP-powered apps. It also seems to extremely unpythonic. Is there a missing link there? I don't know. So…

yeah, for the vast majority of uses, most people really want to do just a fairly small set of things fairly well. NER comes to mind, lots and lots and lots of toolkits for building up to NER, but very few that let submit English text and get back a list of people, places and things without having to virtually build my own NER system from scratch anyways. Give me NER, Entity relationships (ER) and a couple kinds of se…

Well, if you want to get a really good accuracy, then you need a model specific to your domain - which most likely you'll need to train up yourself.

The NLP systems leading in competitions such as CONLL conference tend to be publicly available, so you can get a "general purpose" system there; but the current way usually is to train specific model for a specific purpose - since if you don't have a predetermined purpose, you can't really tell which of items should be tagged as places (instead of things); you can't tell which things should be tagged as 'things' and in what way they should be classified deeper - the list of classes tends to be application-specific.

Re: Natural Language Processing for the Working Programmer

#43

Post by PeterisP »

microtonal wrote: post #30

One of the authors here: we wrote this during the Pragmatic Programmer's writing month in 2010 and some more in 2011. Then I got caught up writing my PhD thesis, and now a new job (as an NLP engineer, but in Java ;)). So, the book is basically frozen. We hope to have more time in the future to continue the writing...

Basing the examples on standard String class seems dangerous.

As soon as you get a corpus of any reasonable size (and you'll have to use large corpora for any meaningful, non-toy results), the various Haskell String-like classes and laziness-control options are mandatory, but tricky/ugly when starting to use them.

Re: Natural Language Processing for the Working Programmer

#44

Post by PeterisP »

phantom-scald wrote: post #34
microtonal wrote: post #30

One of the authors here: we wrote this during the Pragmatic Programmer's writing month in 2010 and some more in 2011. Then I got caught up writing my PhD thesis, and now a new job (as an NLP engineer, but in Java ;)). So, the book is basically frozen. We hope to have more time in the future to continue the writing...

Nice endeavor, but finished up as the most endeavors - unfinished. :) That was the first book in NLP (and the only for now) that I read. I've been interested both in NLP and Haskell. In that respect it fitted, thanks! A few points to criticize. For the frequency list one should use multisets, not dictionaries. There are a few multiset packages at Hackage. Suffix arrays are badly explained. Monads - very badly. With t…

Take a look at Coursera, the NLP course by Jurafsky/Manning (authors of recommendable books) was ok; and right now there's another course starting by Collins, another state-of-art researcher in NLP.

Re: Natural Language Processing for the Working Programmer

#45

Post by KirinDave »

robrenaud wrote: post #32
KirinDave wrote: post #28

Earlier quoted context omitted.

> Not much. It's a more expressive and cleaner language, but on the other hand python has NLTK + scipy community. Haskell's mechanisms for defining parsers, lexers, and other pattern match tools is so good it probably passes over the line from "pretty" to "objectively better". A lot of people who need to lex and parse data and then act on it turn to Haskell. It has some really remarkable and efficient libraries. And…

I am guessing you might be conflating parsing natural language with parsing something that has a rigid and well defined grammar (like a programming language). NLP is a whole different beast.

> NLP is a whole different beast.

The very same patterns that define "packrat-like" parsers (which share a strong relationship to the monadic and "arrow-adic" parsers) can be extended to define things like DFAs and semantic pattern matching. And languages with support for rich, somewhat lazy pattern matching like Haskell and Prolog wipe the floor with eager languages without (e.g., C), which is ideal for semantic analysis.

While not an "authority" in the subject, I've spent a lot of time working with some very skilled folks in the field of NLP, Linguistics. Most tools they used (in our case licensed from X/PARC) had C underpinnings for performance, but ultimately consumed specifications that were very much like Prolog or Haskell in character. Talking to some of the linguists who wrote those tools suggested that had GHC existed (or Allegro or a fast prolog been cheaper) then they would have been much easier to write in those languages.

Re: Natural Language Processing for the Working Programmer

#46

Post by yummyfajitas »

KirinDave wrote: post #45
robrenaud wrote: post #32

Earlier quoted context omitted.

I am guessing you might be conflating parsing natural language with parsing something that has a rigid and well defined grammar (like a programming language). NLP is a whole different beast.

> NLP is a whole different beast. The very same patterns that define "packrat-like" parsers (which share a strong relationship to the monadic and "arrow-adic" parsers) can be extended to define things like DFAs and semantic pattern matching. And languages with support for rich, somewhat lazy pattern matching like Haskell and Prolog wipe the floor with eager languages without (e.g., C), which is ideal for semantic ana…

Do you have more info on this? I'd love to read more.

Re: Natural Language Processing for the Working Programmer

#47

Post by KirinDave »

yummyfajitas wrote: post #46
KirinDave wrote: post #45

Earlier quoted context omitted.

> NLP is a whole different beast. The very same patterns that define "packrat-like" parsers (which share a strong relationship to the monadic and "arrow-adic" parsers) can be extended to define things like DFAs and semantic pattern matching. And languages with support for rich, somewhat lazy pattern matching like Haskell and Prolog wipe the floor with eager languages without (e.g., C), which is ideal for semantic ana…

Do you have more info on this? I'd love to read more.

I'm afraid I can't say much more beyond what I have without talking out of my rear. But you can read about X/P's XLE project here: http://www2.parc.com/isl/groups/nltt/xle/

Re: Natural Language Processing for the Working Programmer

#48

Post by robrenaud »

KirinDave wrote: post #45
robrenaud wrote: post #32

Earlier quoted context omitted.

I am guessing you might be conflating parsing natural language with parsing something that has a rigid and well defined grammar (like a programming language). NLP is a whole different beast.

> NLP is a whole different beast. The very same patterns that define "packrat-like" parsers (which share a strong relationship to the monadic and "arrow-adic" parsers) can be extended to define things like DFAs and semantic pattern matching. And languages with support for rich, somewhat lazy pattern matching like Haskell and Prolog wipe the floor with eager languages without (e.g., C), which is ideal for semantic ana…

Maybe I've been brainwashed by statistical NLP people, but I think this summarizes my understanding pretty well.

http://en.wikipedia.org/wiki/Frederick_Jelinek

> "Every time I fire a linguist, the performance of the speech recognizer goes up"

As far as I know, modern, successful NLP systems don't have much human knowledge baked in and are produced by training on large data sets.

Post reply on HN