形態素解析辞書について

はじめに

形態素解析の辞書は色々あるので、知識整理のために主要なものをまとめました。 ただのメモです。

juman辞書

• 形態素解析システムjumanに含まれている辞書
• システムと分離されているがjuman以外で使われてないので事実上juman専用

ipadic

• Chansen用に開発
• IPA品詞体系をベースに拡張された
• 形容動詞を使っていない
  • 名詞の再分類として分類している -可能性に基づく品詞体系を採用
  • 局所的な情報で品詞を判断できない場合は併記する
• 枯れた辞書

UniDic

• 国立国語研究所で規定された短単位と呼ばれるゆれのない斉一な単位で設計
  • 現代語で意味をもつ最小単位＝短単位を認定後、最小単位を分節境界の範囲内で短単位認定規則に従って結合
  • UniDicでは最小単位の認定と結合規則が厳密に定義されているため個人によって捉え方に幅のある単語単位基準の標準化がなされている
    • 一方で最小単位定義と短単位認定規定の語認定規則は人の直感と反することがある
• 見出し語に、語彙素、語形、辞書形、発音形といった改装構造をもたせる
  • 表記ゆれの差異を吸収できる
• 語源主義に基づく脱文脈化
  • 表記の違いに関わらず、辞書の見出し語として同一であれば同一の語彙として区別しない
  • 文脈に即した意味まで扱わない
• 音声認識、音声合成に有益な韻律情報が豊富である一方、短単位の影響から単語の読み曖昧性を抱える
  • 「筑波山（つくばさん）」「吉田山（よしだやま）」どちらになるかはケース次第

NEologd

• Unidicの拡張機能
• あまり更新されていないUnidicにweb上の言語資源から得た固有名詞を約300万語採録した
• 文を形態素単位ではなく固有名詞や複合名詞を長単位として認定して読みを正確に付与することができる
• 固有名詞の認定が精度に影響するようなタスクで効果が期待できる
  • 文書分類には適切
  • 情報検索では検索もれをおこすことも

Django template viewのリクエストから表示までの流れ

はじめに

Class-based viewでのtempalteViewのリクエストからレンダリングまでの流れを調べた。

templateView

TemplateViewはViewクラスをオーバライドしたテンプレートを表示するためのViewクラス。 実装は以下。 github.com

templateViewのコードリーディング

継承

• View
• ContextMixin
• TempalteResponseMixin

(継承順)

View

Viewクラスで使っているのは以下のメソッド

• as_view
  • https://github.com/django/django/blob/master/django/views/generic/base.py#L52-L83
  • Main entry point for a request-response process.
  • クラスビューを関数ビューに変換している(?)
    • functools.update_wrapperでview()をclsでwrapしている
  • view()でdispatchにrequestを渡して返す
• dispatch
  • https://github.com/django/django/blob/master/django/views/generic/base.py#L93-L101
  • self.http_method_namesに指定のないメソッドなら405を返す
  • handler = getattr(self, method)
    • 定義している自信のメソッドを返す
  • handler=定義したメソッドにrequest, *args, **kwargsを渡して呼び出す
  • viewに属性を付加したい場合はdispatchをオーバーライドする
    • なにもオーバーライドしていないtemplateView だけならここでget()がよばれる

ContextMixin

Viewクラスで使っているのは以下のメソッド

• https://github.com/django/django/blob/master/django/views/generic/base.py#L19-L30
• テンプレートにわたす変数を追加
• self.get_context_data()がここをget()等各メソッドで呼び出す
• 変数変更する場合はget_context_data()をオーバーライドする
  • ただし親=ContextMixinのget_context_dataを継承しないとviewという変数がテンプレートで使えないので注意

TempalteResponseMixin

• https://github.com/django/django/blob/master/django/views/generic/base.py#L121-L154
• ここでレンダリングする
• response_classはtempalteViewの場合は触らない
  • たぶんAPIResponseとかになるのかな？

メソッド

• get()
  • https://github.com/django/django/blob/master/django/views/generic/base.py#L157-L164
  • self.get_context_data()
  • self.render_to_response(context)

処理順

1. リクエストをうける
2. (多くの場合)urls.py経由でas_view()がよばれる
3. dispatch()にrequest, *args, **kwargsが渡される
4. dispatchでhttp_requestを確認して、定義されたhttp request methodを呼び出して返すか、405を返す
5. 定義されたhttp request methodでget_context_dataを呼び出してcontextを生成＆＋α処理をする
6. render_to_responseでcontextをtempalteに描画する

参考

https://e-tec-memo.herokuapp.com/article/85/

Python is と ==の違い

はじめに

会社のチームの勉強会でこの話題になったので調べてみたことのメモです。

まとめ

pythonのisと==は違いがあるので注意する。

ちがい

==

オブジェクト同士が等価であるか判定する演算子。 つまり、等価=同じ値・同じ順番・同じ型のこと。

 　   
v1 = [1,2,3]
v2 = [1,2,3]
v3 = [2,3,1]
v4 = (1,2,3)
 　     
v1 == v2 # true
v1 == v3 # false
v1 == v4 # false

　
== はオブジェクトが定義している__eq__メソッドを見ます。 オブジェクトに定義されてない場合は、最上位の基底クラスで定義されている__eq__を参照します。

is

同じオブジェクトであるか。等価 = objectのidが同じこと。

v1 = [1,2,3]
v2 = [1,2,3]
 　     
v1 == v2 # true
v1 is v2 # false

比較

自ら定義したクラスなどの場合、__eq__を定義していないと==がobjectクラスの__eq__メソッドをたどるため、結果isと同じ処理になります。 なので、直接isを使ったほうが無駄がないぶん速いです

Noneの判定

isを使う

Noneはシングルトンで常にひとつしかないオブジェクトのため、Noneが代入された時点でオブジェクトのidはNoneのものと同じになります。 ちなみにsingletonはisを使うようにpep8で決まっています。(https://www.python.org/dev/peps/pep-0008/#id51) 　
==はオーバーロードできてしまうので、同一のオブジェクトとして判断するならisを使いましょう。 自分で__eq__を定義でおきるので比較するオブジェクトがどう定義するかをいちいち把握するのは手間なのでisを使ったほうが早い。