反向索引：

說明見Similarity.java的javadoc信息：


算法請參考javadoc的，它使用的是Vector Space Model (VSM) of Information Retrieval。

       ------------------------------------
        Store.COMPRESS  Store the original field value in the index in a compressed form. This is useful for long documents and for binary valued fields.壓縮存儲；
        Store.YES Store the original field value in the index. This is useful for short texts like a document's title which should be displayed with the results. The value is stored in its original form, i.e. no analyzer is used before it is stored. 索引文件本來只存儲索引數據, 此設計將原文內容直接也存儲在索引文件中，如文檔的標題。
        Store.NO  Do not store the field value in the index. 原文不存儲在索引文件中，搜索結果命中后，再根據其他附加屬性如文件的Path，數據庫的主鍵等，重新連接打開原文，適合原文內容較大的情況。
        決定了Field對象的 this.isStored 和        this.isCompressed
     ------------------------------------
        Index.NO Do not index the field value. This field can thus not be searched, but one can still access its contents provided it is Field.Store stored. 不進行索引，存放不能被搜索的內容如文檔的一些附加屬性如文檔類型, URL等。
        Index.TOKENIZED Index the field's value so it can be searched. An Analyzer will be used to tokenize and possibly further normalize the text before its terms will be stored in the index. This is useful for common text. 分詞索引
        Index.UN_TOKENIZED  Index the field's value without using an Analyzer, so it can be searched. As no analyzer is used the value will be stored as a single term. This is useful for unique Ids like product numbers. 不分詞進行索引，如作者名，日期等，Rod Johnson本身為一單詞，不再需要分詞。

        Index.NO_NORMS 不分詞，建索引。norms是什么???字段值???。但是Field的值不像通常那樣被保存，而是只取一個byte，這樣節約存儲空間???? Index the field's value without an Analyzer, and disable the storing of norms.  No norms means that index-time boosting and field length normalization will be disabled.  The benefit is less memory usage as norms take up one byte per indexed field for every document in the index.Note that once you index a given field <i>with</i> norms enabled, disabling norms will have no effect.  In other words, for NO_NORMS to have the above described effect on a field, all instances of that field must be indexed with NO_NORMS from the beginning.
        決定了Field對象的 this.isIndexed  this.isTokenized  this.omitNorms
     ------------------------------------
        Lucene 1.4.3新增的：
        TermVector.NO Do not store term vectors.  不保存term vectors
        TermVector.YES Store the term vectors of each document. A term vector is a list of the document's terms and their number of occurences in that document. 保存term vectors。
        TermVector.WITH_POSITIONS Store the term vector + token position information 保存term vectors。（保存值和token位置信息）
        TermVector.WITH_OFFSETS Store the term vector + Token offset information
        TermVector.WITH_POSITIONS_OFFSETS Store the term vector + Token position and offset information 保存term vectors。（保存值和Token的offset）
        決定了Field對象的this.storeTermVector this.storePositionWithTermVector this.storeOffsetWithTermVector

Closure: http://en.wikipedia.org/wiki/Closure_%28computer_science%29
我還比較喜歡Microsoft的一段說明，位于鏈接http://msdn.microsoft.com/msdnmag/issues/07/09/BasicInstincts/Default.aspx?loc=zh中，查找“Lambda 表達式和變量提升”

最早接觸Closure是在學javascript, 前年還寫了篇關于Closure對javascript內存泄露的文章http://www.tkk7.com/tim-wu/archive/2006/05/29/48729.html
一直以為這就是函數式語言的特性，頂多就是.net的委托和它有幾分相識，
沒想到現在Java7也要支持了，有興趣的朋友可以去讀讀：
http://www.javac.info/
沒細讀，不知道Lambda在Java這種強類型檢查的語言中表現的如何。

作為函數語言，Ruby中一直都有closure的用法，http://samdanielson.com/2007/3/19/proc-new-vs-lambda-in-ruby有個簡單例子。

def foo
  f = Proc.new { return "return from foo from inside proc" }
  f.call # control leaves foo here
  return "return from foo" 
end

def bar
  f = lambda { return "return from lambda" }
  f.call # control does not leave bar here
  return "return from bar" 
end

puts foo # prints "return from foo from inside proc" 
puts bar # prints "return from bar"

 最近，ruby 1.9又提供了新的定義lambda

x = ->{puts "Hello Lambda"} 

以下內容均為轉載,url見具體鏈接:

最常見的四個Analyzer,說明:  http://windshowzbf.bokee.com/3016397.html 
WhitespaceAnalyzer  僅僅是去除空格，對字符沒有lowcase化,不支持中文
SimpleAnalyzer :功能強于WhitespaceAnalyzer,將除去letter之外的符號全部過濾掉,并且將所有的字符lowcase化,不支持中文
StopAnalyzer: StopAnalyzer的功能超越了SimpleAnalyzer，在SimpleAnalyzer的基礎上.增加了去除StopWords的功能,不支持中文.類中使用一個static數組保存了ENGLISH_STOP_WORDS, 太常見不index的words
StandardAnalyzer: 用Javacc定義的一套EBNF，嚴禁的語法。有人說英文的處理能力同于StopAnalyzer.支持中文采用的方法為單字切分。未仔細比較，不敢確定。

其他的擴展:
ChineseAnalyzer:來自于Lucene的sand box.性能類似于StandardAnalyzer,缺點是不支持中英文混和分詞.
CJKAnalyzer:chedong寫的CJKAnalyzer的功能在英文處理上的功能和StandardAnalyzer相同.但是在漢語的分詞上，不能過濾掉標點符號，即使用二元切分
TjuChineseAnalyzer: http://windshowzbf.bokee.com/3016397.html寫的,功能最為強大.TjuChineseAnlyzer的功能相當強大,在中文分詞方面由于其調用的為ICTCLAS的java接口.所以其在中文方面性能上同與ICTCLAS.其在英文分詞上采用了Lucene的StopAnalyzer,可以去除 stopWords,而且可以不區分大小寫,過濾掉各類標點符號.

例子:
http://www.langtech.org.cn/index.php/uid-5080-action-viewspace-itemid-68, 還有簡單的代碼分析

Analyzing "The quick brown fox jumped over the lazy dogs"

WhitespaceAnalyzer:

[The] [quick] [brown] [fox] [jumped] [over] [the] [lazy] [dogs]

SimpleAnalyzer:

[the] [quick] [brown] [fox] [jumped] [over] [the] [lazy] [dogs]

StopAnalyzer:

[quick] [brown] [fox] [jumped] [over] [lazy] [dogs]

StandardAnalyzer:

[quick] [brown] [fox] [jumped] [over] [lazy] [dogs]

Analyzing "XY&Z Corporation - xyz@example.com"

WhitespaceAnalyzer:

[XY&Z] [Corporation] [-] [xyz@example.com]

SimpleAnalyzer:

[xy] [z] [corporation] [xyz] [example] [com]

StopAnalyzer:

[xy] [z] [corporation] [xyz] [example] [com]

StandardAnalyzer:

[xy&z] [corporation] [xyz@example.com]

參考連接:
http://macrochen.blogdriver.com/macrochen/1167942.html
http://macrochen.blogdriver.com/macrochen/1153507.html

http://my.dmresearch.net/bbs/viewthread.php?tid=8318
http://windshowzbf.bokee.com/3016397.html

推薦
http://gceclub.sun.com.cn/developer/technicalArticles/Intl/Supplementary/index_zh_CN.html
http://www.linuxpk.com/3821.html
=======================================
BMP的解釋：
http://zh.wikipedia.org/w/index.php?title=%E5%9F%BA%E6%9C%AC%E5%A4%9A%E6%96%87%E7%A8%AE%E5%B9%B3%E9%9D%A2&variant=zh-cn
http://zh.wikipedia.org/w/index.php?title=%E8%BE%85%E5%8A%A9%E5%B9%B3%E9%9D%A2&variant=zh-cn#.E7.AC.AC.E4.B8.80.E8.BC.94.E5.8A.A9.E5.B9.B3.E9.9D.A2
1個BMP和16個輔助plane，需要21個bits.

======================================
ISO-10646與Unicode關系
http://zh.wikipedia.org/wiki/%E9%80%9A%E7%94%A8%E5%AD%97%E7%AC%A6%E9%9B%86

ISO-10646術語	Unicode術語
UCS-2	BMP UTF-16
UCS-4	UTF-32

注意：UTF-16可看成是UCS-2的父集。在沒有輔助平面字符前，UTF-16與UCS-2所指的是同一的意思。但當引入輔助平面字符後，就只稱為UTF-16了，因為我們會使用2個UTF-16，也就似乎4bytes保存一個輔助平面字符。現在若有軟件聲稱自己支援UCS-2編碼，那其實是暗指它不能支援輔助平面字符的委婉語。
======================================
UTF-8要完整表達unicode需要4bytes，表達BMP需要3bytes，見http://en.wikipedia.org/wiki/UTF-8，注意“The range D800-DFFF is disallowed by Unicode. The encoding scheme reliably transforms values in that range, but they are not valid scalar values in Unicode. See Table 3-7 in the Unicode 5.0 standard. ”

另：
Java 1.0 supports Unicode version 1.1.
Java 1.1 onwards supports Unicode version 2.0.
J2SE 1.4中的字符處理是基于Unicode 3.0標準的。
J2SE v 1.5 supports Unicode 4.0 character set.

而：
Unicode 3.0：1999年九月；涵蓋了來自ISO 10646-1的十六位元通用字元集（UCS）基本多文種平面（Basic Multilingual Plane）

Unicode 3.1：2001年三月；新增從ISO 10646-2定義的輔助平面（Supplementary Planes)

在大約 1993 年之后開發的大多數現代編程語言都有一個特別的數據類型, 叫做 Unicode/ISO 10646-1 字符. 在 Ada95 中叫 Wide_Character, 在 Java 中叫 char.

ISO C 也詳細說明了處理多字節編碼和寬字符 (wide characters) 的機制, 1994 年 9 月 Amendment 1 to ISO C 發表時又加入了更多. 這些機制主要是為各類東亞編碼而設計的, 它們比處理 UCS 所需的要健壯得多. UTF-8 是 ISO C 標準調用多字節字符串的編碼的一個例子, wchar_t 類型可以用來存放 Unicode 字符.

代碼為QueryParser.jj，語法為JavaCC實現的LL()：
完整文檔：http://lucene.apache.org/java/2_0_0/queryparsersyntax.html

和正則一樣：
?表示0個或1個
+表示一個或多個
*表示0個或多個


以下是Token部分：

以下為解析部分

btw: 猜測: javacc中,如果使用[],則允許出現0次或1次

今天讀了lucent中的PriorityQueue.java, 一個很巧妙的復雜度為log(n)的排序堆棧.

始終確保數組A[1...n]中:
A[i]<A[2*i]  & A[i] < A[2*i +1]
很容易推論出A[1]一定是最小數值, 并且每次put()和pop()至多移動log(n)個數值

真是好久沒接觸算法了:)

http://www.cse.iitb.ac.in/~soumen/doc/www1999f/html/

http://www.cindoc.csic.es /cybermetrics/pdf/68.pdf

今天翻了util包，發現自己對float的匱乏知識，好在有偉大的wiki百科：
http://en.wikipedia.org/wiki/IEEE_754
很清楚得解釋了IEEE 754規范

可惜看不懂lucene對small float的結構定義。
如果按我的理解，似乎類SmallFloat的函數byteToFloat()和byte315ToFloat()有bug，通過編寫測試代碼：
SmallFloat.byte315ToFloat(Byte.parseByte("01111000", 2)得到的float值為0.5f，

但按照byte315ToFloat()函數的說明，"01111000"的mantissaBits尾數長度為3, zeroExponent為15，無負數，
而01111按IEEE 754規范，應該理解為1，所以01111000表達的數值應該為1.0×2^0=1，而不是0.5f
非常之tricky。

通過讀byte315ToFloat()函數實現，發現"01111000"轉換為32位值0,01111110,00000000000000000000000,
該值按IEEE 754規范的確為0.5f， 其中正負位為1位，指數(exponent)位為8位，尾數(mantissa)位為23位。

而在byteToFloat()和byte315ToFloat()的實現中，我們可以常看到作者將尾數位偏移24-mantissa位，
也就是說，他理解的IEEE 754規范中尾數位不是23位而是24位。

以上僅為我的猜測，因為還沒有看到byteToFloat()的具體使用環境。

而且通過測試代碼，發現byte和float對應關系：
10000,000==2.0f= 1*2^1
10001,000==8.0f=1*2^3
10010,000==32.0f=1*2^5
01111,000 = 0.5f = 1*2^-1
01110,000==0.125f= 1* 2^-3
完全看不出合理的small float的結構，tricky!!!

swt中，默認只有用戶線程被允許訪問UI圖形控件和一些圖形API，其他非用戶線程如果直接訪問這類資源時，SWTException直接被拋出。
如果真有這種需求，必須使用*.widget.Display類中的兩個線程同步方法：syncExec(Runnable)和asyncExec(Runnable)。方法syncExec()和asyncExec()的區別在于前者要在指定的線程執行結束后才返回，而后者則無論指定的線程是否執行都會立即返回到當前線程。

例子:
Display.getCurrent().asyncExec(new Runnable() {
　public void run() {
　　butt.setText("Push");
　}
});

以下載自某論壇（sorry,忘記了出處），關于內存釋放：

Rule 1: If you created it, you dispose it.
Rule 2: Disposing the parent disposes the children.
(from http://www.eclipse.org/articles/swt-design-2/swt-design-2.html)

當使用構造函數來創建小窗口或圖形對象時，使用完時必須用手工來除掉它。
如果沒有使用構造函數就獲取小窗口或圖形對象，則一定不能用手工來除掉它，因為您未分配它。
如果將對小窗口或圖形對象的引用傳送至另一個對象，則一定要小心，仍在使用它時一定不要除掉它。與在使用圖像的插件模式中所描述的規則相似。）
當用戶關閉Shell時，將遞歸地銷毀 shell 及其所有子代小窗口。在此情況下，不需要除掉小窗口本身。然而，必須釋放與那些小窗口一起分配的所有圖形資源。
如果創建圖形對象以便在其中一個小窗口的生命周期內使用它，則在除掉小窗口時必須除掉圖形對象。這可以通過向小窗口注冊銷毀偵聽器，并在接收到銷毀事件時釋放圖形對象來實現。

這些規則有一個例外。簡單的數據對象（例如，矩形和點）不使用操作系統資源。它們沒有 dispose() 方法，您也不需要釋放它們。如果有疑問，則檢查特定類的 javadoc。

?

第一種方式，zkjbeyond的文章中有很詳細的說明http://www.tkk7.com/zkjbeyond/archive/2006/05/05/44676.html
簡單說，就是利用Ajax讀取包的.js文件后，直接使用eval()運行代碼。

除此外，dojo還有另一種加載方式，用在調試階段（例如使用firebug活Venkman調試dojo時都需要用到，不過我沒試過使用MSE7或Visual Studio時是否需要使用這種加載方式）。

你在加載包前，將djConfig.debugAtAllCosts設置為true，那么包的加載方式會有所變化，采用第二種方式。例如：

   djConfig.debugAtAllCosts=true;
    dojo.require("dojo.widget.TimBar");
    dojo.hostenv.writeIncludes();

此時，dojo會使用加載brower_debug.js文件，
brower_debug.js重載了函數dojo.hostenv.loadUri，這兒，不再直接使用eval()運行，而只是把需要的包push到dojo.hostenv.loadedUris數組中。實現代碼：

                var text = this.getText(uri, null, true);
		var requires = dojo.hostenv.getRequiresAndProvides(text);
		eval(requires.join(";"));
		dojo.hostenv.loadedUris.push(uri);  //push要加載的包到loadedUris數組中
		dojo.hostenv.loadedUris[uri] = true;
		var delayRequires = dojo.hostenv.getDelayRequiresAndProvides(text);
		eval(delayRequires.join(";"));

從代碼可以看出，dojo為了保證加載的順序，使用dojo.hostenv.getRequiresAndProvides函數將提前依賴的包摳出來，用遞歸提前push到dojo.hostenv.loadedUris中。
而后，在代碼最后，我們只要主動使用dojo.hostenv.writeIncludes();函數，就可一次性將被依賴的包利用document.write包含進來。

btw:
當然，這種方法有不少缺陷：
1、使用document.write方式加載包，會有延遲效應，會等待本頁面中代碼都執行完才執行包中的代碼，自己編碼時有點繞，影響可讀性；
2、從上面代碼中看出，dojo會有更多的IO操作，第一dojo已經完整讀取了包代碼，但是不馬上執行，只是用來分析依賴關系；之后，瀏覽器又要加載一次包代碼。
3、包絕對不允許循環引用。當然，從OO角度，不循環引用是好的方式

所以，這種方式只能用在調試期間