自然語言處理的另類選擇： spaCy 初探

安裝見 https://spacy.io/usage/ ，線上示範參 https://demos.explosion.ai/displacy/

速度上的確是比 Stanford coreNLP 快一點 ( 但也沒有到官方文件說的一個數量級那麼誇張 ) ，分析有時會比較合理，但 google scholar 上參考數很少

問題可能是出在安裝上，對 visual studio 和 c 的編譯不熟的話，安裝會有極大困難

( 我想這也是為何在 github 上， spaCy 的人氣反而超過 Stanford coreNLP 的原因 )

上圖是 spaCy 的分析結果，下圖是同一句子在 coreNLP 的分析，其中 calls 都被誤認為是名詞

一個句子/子句的中心就是動詞， spaCy 的分析結果很尊重這個原則。

在一些日常的英文中， "with" 這個單字的解析在 spaCy 也是比較正確的，而 spaCy 出錯時， coreNLP 也不見得正確。但是在一些很簡單的範例上， spaCy 會錯得很離譜，而 coreNLP 卻能得到正確結果。而且 spaCy 目前還不能處理中文。 只能說有一好就沒兩好吧?

使用 perl one liner 進行檔案搜尋取代的流程 ( SOP ) ( 三 )

(上圖是 kuso 快遞公司 FedEx)

承接 2013 年 使用perl one liner進行檔案搜尋取代的流程(SOP) 一文，如果要串接多個層次的處理也是沒有問題的。(沒辦法，RE 真的是太好用太強大啦!!)

| 這個重新導向算子可以把前面的結果傳給後面，所以可以這樣使用：

perl -pe /xxxxxxxx/ abc.txt | perl -ne /xxxxxxxxxxxxx/ > def.txt

另外還可以衍生出一種使用的情境，就是資料的過濾，這必需要 -ne 參數搭配上 print 函數，合於條件時才利用 print 輸出以進入下一層處理。以下這行簡單的 one-liner 可以證明， | 兩側的 perl instance 是同時執行，且輸出入是即時重導的：

github上python 套件的 fork 與修改、測試、上傳

1. 按下 github 網頁上的 fork 圖示
2. 在生成的專案頁面上，複製 clone 的專用網址 
3. 解除安裝對應的套件，下達 pip uninstall XXX
4. 修改程式碼
5. 在 clone 生成的目錄，下達 python setup.py build 及 python setup.py install
6. 測試確定結果無誤
7. git add 剛修改到的檔案
8. git commit -m "註解"
9. git push ； 會要你輸入 github 上的登錄資訊，也就是帳密

python3 對 html 的高速剖析-- lxml

bs4 的速度在處理大家資料時有點令人不耐，此時 lxml 不失為一個好方案

參 http://lxml.de/

在處理文字時，如果有 tag 與文字混雜的情況，可參考 http://yshblog.com/blog/151

基本上就是會把文字放在 tag 的 tail 屬性當中，要花點工夫去找出來、串起來

Stanford coreNLP的非官方 python 介面 "stanford-corenlp" 初探

主頁在 https://github.com/Lynten/stanford-corenlp ，可以直接用 pip3 安裝

測試檔可以試試 https://github.com/Lynten/stanford-corenlp/blob/master/test.py

(已經改寫為 python3 的語法)