chewing
請問 tsi.src 當中的單筆頻率數據的數值上限是多少？
我試圖用我自己組的資料，卻發現候選字並未全部按照頻率數據來遞減排序：
該資料可以藉由威注音詞庫組得：https://gitee.com/vchewing/libvchewing-data 需要至少 macOS Catalina 系統＋Xcode Commandline Tools。 直接跑「make libv-chs」即可生成簡體中文版 tsi.src、phone.cin 及 phone.cin-CNS11643-complete.patch。 用以編譯 tsi.src 與 phone.cin 的 swift 腳本是先按照注音排序、再在同一讀音下以頻次遞減排序的。
vchewingdata4libchewing-chs-20220402.tar.gz 附上這次用到的 phone.cin & phone.cin-CNS11643-complete.patch & tsi.src。
It seems a bug. Could you try this patch?
diff --git a/src/tools/init_database.c b/src/tools/init_database.c
index 5bff504..1ad9762 100644
--- a/src/tools/init_database.c
+++ b/src/tools/init_database.c
@@ -531,7 +531,7 @@ void insert_leaf(NODE * parent, long phr_pos, uint32_t freq)
NODE *pnew;
for (p = parent->pFirstChild; p && GetUint16(p->data.key) == 0; prev = p, p = p->pNextSibling)
- if (GetUint16(p->data.phrase.freq) <= freq)
+ if (GetUint24(p->data.phrase.freq) <= freq)
break;
pnew = new_node(0);
@yan12125 請問我這樣是需要重新編譯整個 libchewing？還是說只需要這樣修改之後重新編譯新的 database 檔案、然後蓋掉系統內已有的新酷音輸入法的 database 檔案即可？
關於原本的問題：目前詞庫裡的頻率是用3個byte表示，最大可以到2^24-1=16777215。另有一個開發中的rust分支，看起來都是用u32表示頻率？最大應該可以到2^32-1=4294967295。我不太懂rust，需要 @kanru 確認。
如 @yan12125 所說原本的詞庫是用 3 個 byte (24 bit) 表示，而 rust 分支是用 u32 (32 bit) 但是實際上 tsi.src 裡面的最大值只有用到 327781 而已
sqlite> select max(freq) from dictionary_v1 ;
327781
@kanru 這個限制調大一些應該無大礙。 也就是我這邊覺得新酷音在 Windows / Linux 系統下已經很強了、所以我不急著做威注音的 Windows / Linux 版而已。 我就直接寫了詞庫編譯腳本、可以將威注音的詞庫編譯成 libchewing 可以編譯的 tsi.src 等檔案。 這樣一來我那些不習慣台澎金馬審音的大陸同鄉們也可以舒舒服服地使用新酷音。 比如這個票：https://gitee.com/vchewing/libvchewing-data/issues/I545GO
- 「新酷音内的注音信息非大陆标准，不是很适应。」
P.S.: 威注音詞庫同時支援兩岸的審音、以及典型的台澎金馬的民間習慣讀音（比如亞洲唸「ㄧㄚˇ」）。 P.P.S.: LibTabe 裡面錯誤內容非常多，補不勝補。我這邊威注音詞庫大概是去年年底開始養的，用的是 NAER 的詞頻資料，養到現在雖然已經可以接受了，但還會繼續養下去。
@kanru 要是你們 libchewing 能寫成 swift package 且有 api 使用手冊的話，macOS 版的維護估計會更方便些。 這方面的內容是不能指望 OpenVanilla 了，他們早就扔掉了他們自己的 SpaceChewing。
拘泥於 C++ 反而會阻礙一些小型開源專案的生命力，還是 Rust、Swift 等新型語言是王道。
先偷偷宣傳，現在開發裝的新酷音會支援分享詞庫跟使用多個詞庫的功能
非常期待！
另外，請問rust版本之後會取代C的版本嗎？還是兩者會共存？如果init_database.c短期之內會被移除，那我就不送PR了 :D
……會不會是我在編譯 data 之前得 make clean？
我用CMake測試有時得touch data/*才會重新編譯詞庫。可能是少寫了一些依賴。
能寫成 swift package 且有 api 使用手冊的話
應該可以 export swift binding
另外，請問rust版本之後會取代C的版本嗎？還是兩者會共存？
預計會同時有相容的 C API 跟新的 Rust API
預計會同時有相容的 C API 跟新的 Rust API
抱歉沒問清楚。我是想確定之後會不會移除C的實作，只保留Rust的實作？例如，移除src/tools/init_database.c等等，只保留
tools/src/bin/init_database.rs等等。
預計會同時有相容的 C API 跟新的 Rust API
抱歉沒問清楚。我是想確定之後會不會移除C的實作，只保留Rust的實作？例如，移除
src/tools/init_database.c等等，只保留tools/src/bin/init_database.rs等等。
Tool 應該只會留一種
@yan12125 其實，您這個 PR 真要是推來的話，會方便到想給酷音輸入法編譯威注音詞庫的人群。 至少在 Rust 版詞庫編譯體系正式推送之前是這樣。
如果確定不推 PR 的話，請知會我。 我這邊 libvchewing-data 的 makefile 就補上自動 patch 的環節。
我再想了一下，目前C版本使用的詞庫頻率為24-bit，而Rust版本使用32-bit，因此Rust版的init_database編譯出來的詞庫應該是無法給目前的libchewing使用的(not tested)。由於新版本libchewing可能不會那麼快出來 (https://github.com/chewing/libchewing/issues/307) ，所以修正C版本的bug還是有必要的 - #337
@yan12125 新版的原廠詞庫格式注定無法用於舊版：新版用的是 SQLite (dictionary_v1)，而舊版則是明文 dictionary.dat 加上一個索引表。