CHISE_Value (Re: chise_swig_perl)

守岡知彦 / MORIOKA Tomohiko tomo @ kanji.zinbun.kyoto-u.ac.jp
2006年 12月 12日 (火) 20:56:34 JST


守岡です。

お返事遅くなってすみません。

>>>>> [chise-ja : No.00517] にて
>>>>> KAMICHI Koichi <kamichi @ fonts.jp> さま曰く:

> > > ところで、chise.hのなかの「CHISE_Value」について、よくわかっていません。

> > > これらの関数で使われるCHISE_Valueとは何でしょうか?文字列データの抽象ク

> > 素性値を格納するための型で、現在の実装ではその実体は Berkeley DB の
> > DBT です。

> > 素性値を抽象的に扱いたい気持と、メモリー管理やコピーを避けたい気持が相
> > 反する訳ですが、とりあえず、抽象化された CHISE_Value* 型のデータをアク
> > セス関数を介して操作するという方式にしとけば、高レベルのアクセス関数を
> > 用意することで、拡張も可能になるかなあという意図でこうなってます。

> なるほど。とりあえず現状ではC(libchise)とPerlとの文字列データのやりとり
> はすべてSWIGに任せているので、結果としてchar*型を介しています(libchise
> の文字列はunsigned char*型なので面倒…)。今はCHISE_Value*型を使うメリッ
> トがないので後回しにしていますが、そのうちtypemapを使ってCHISE_Value*型
> を直接Perlのスカラーに取り込むようにしたいと思います。

すみません。byte 列は unsigned char* かなと思って unsigned char* を乱
用してしまいました。libconcord では、素性値のように本質的に byte 列な
ものはunsigned char* だけど、名前のように本質的に文字列なものは char* 
にするようにしたんですが、libchise をいまさら変えると API 変更になっちゃ
うので悩ましいです。個人的には変えても良いと思いますが。


> さて、早速ですがモジュール化作業に入りました。従来のchiseperl.plは捨
> てて、libchiseの命名に沿って再度chise.hにある関数をラッパー化し、読
> み込み系はすべて終わり、次は書き込み&更新系です。

> あと、動作確認のためサンプルスクリプトもcvsに入れました。こんどのモ
> ジュール化でだいぶ素直に書けると思います。

ありがとうございます。

サンプルがあると助かると思います。



> (1)残りの関数が終わったら、今度は念願のPerl/CHISE関数の取り込み、
> およびRuby/CHISEの内容とも整合性を取ることにチャレンジしたいと思いま
> す。

> 今日、別件で野村英登さんと話をしていて、Perl/CHISEはChaonモデルの活
> 用(実証)を目的とした関数が多いけれども、私が主として考えているのは
> 漢字構造情報や漢字同士の関係に関する操作関数で、すこし目的がずれてい
> ることを認識しました。なので、優先順位をつけようと思います。このこと
> については、ご意見を頂戴したいと思います。もしくは自分のほしい関数か
> らやっていきます。

現状の libchise がサポートしている機能は非常に低レベルのものなのですが、
XEmacs CHISE では文字間の関係や漢字構造情報等に関する高レベルな機能が
あります。正直、メモリ管理とかオブジェクトシステムがない現状の 
libchise でそういうのをがりがり書くのは大変だし、ナイーブに書くと、多
分、効率も良くなさそうなので、どうしたものか悩んでいるのですが(Gauche
等の Scheme を使ったデフォルト時の高機能 API を実装するというのが良い
かなと思ってたりします)、それはさておき、おそらく、Perl で高レベル 
API を実装するのが良いのではないかと思います。


> (2)新しいchar_idを取得するのに0xF0000から未使用のものを探していく、
> という方法については、Perlだと今のところ30秒かかります。もちろん文字
> オブジェクトが増えればもっと遅くなるわけですが、よい解決法はないでしょ
> うか?とりあえずC言語側で書きなおすことを考えています。

これは libchise に API を追加すべきだと思います。

;; っていうか、サボっててすみません。


> (3)CCSについてchar_idからコードポイントを得る向き(feature)と、コー
> ドポイントからchar_idを得る向き(index)で、対称関係になっていますが、
> 片方についてchise_char_set_feature_valueで新たに値を登録したときに、
> 逆向きのindexにはデータが自動登録されるのでしょうか?前に聞いたとき
> は「される」だったと思いますがこれはXEmacs/CHISEの話であり、
> libchise/concordレベルでは実装されていないと(ソースを見て)思ったの
> ですが、正しいでしょうか?

実装されてないようです。

> また、たとえば新たにCCSに相当するfeatureを作った場合、index側も作る
> 必要があり、またpropertyの「type」を「CCS」とする、などの作業につい
> ても、現在は手作業になるのでしょうか?libchiseはシンプルなので理解し
> やすいのですが、逆にXEmacsで実装できていることが複雑で追いつけない
> 印象です。

その通りだと思います。すみません。

XEmacs CHISE だと独自の内部 chache を持ってて、libchise で同期されると
かえって邪魔なもんで、ついつい libchise での実装が疎かになってますが、
同期する API を用意すべきだと思います。

同様に、関係系の素性に関しても逆関係を同期する機能を用意すべきだと思い
ます。ただ、こっちは素性値の parse が必要になってくるので、若干面倒な
んですが、現状の枠組でも不可能ではないと思います。


> (4)char_idから実体参照への変換について、現在XEmacsではlispコード
> で実装していますが、これをpropertyを参照すれば変換できる形式(CCSに
> 対する頭置語の登録?)に移行することはいかがでしょうか。スクリプト内
> に変換情報をハードコードするのに抵抗があります。

CCS 素性の属性として記載するのが良いと思っています(例によって、実装追
い付いていません。すみません(^_^;)。


まとめると、実装追い付いてなくてすみません、という感じです。すみません。
-- 
┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━
││ ─ │  ─  /    ─   ┼─     ┬                ─   ─┼ ┬┴─
┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) <tomo @ m17n.org> ─ ─┬
┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━




More information about the CHISE-ja mailing list