# Failures

AzooKeyKanaKanjiConverterの開発上、明確に失敗だったと考えている実装や仕様をまとめます。これらは将来的に修正できるかもしれないし、できないかもしれないです。

このドキュメントの目的はAzooKeyKanaKanjiConverterの判断ミスを明確にして、今後AzooKeyKanaKanjiConverterのフォークを作成する方や、新たな日本語入力ソフトウェアを作ろうとする方に向けて知見を残しておくことです。

AzooKeyKanaKanjiConverter本体については[azooKeyをベースとするプロダクトの開発開始時に注意すべき点](https://github.com/ensan-hcl/azooKey/tree/develop/docs/advice_for_azooKey_based_development.md)もご覧ください。

## コストの設計

辞書データのコストはざっくり言って対数尤度です。azooKeyの開発初期、コストは対数尤度をそのまま使っていました。これを続けてしまったため、普通は`Int`などにするのですが、azooKeyのコストは`Float16`になっています。

`Float16`の現実的に不便な点は以下の通りです。

* 整数型に比べて(おそらく)和の計算が遅い
* macOSが`Float16`に対応していないことに由来する困難がある

今から作り直すなら、`UInt16`か`UInt8`にしています。サンプリングを工夫することで、`UInt8`でも十分な表現ができる可能性があります。

なお、今後のバージョンアップでこの変更を行う場合、ユーザ側でもマイグレーションが必要になります。

* 絵文字・顔文字・ユーザ辞書の再コンパイル
* 学習データの再コンパイル

逆にいうと、気合と正しいマイグレーションの実装ができれば今からでも修正可能ではあります。

## CharIDの設計

`LOUDS`検索を高速化するため、`LOUDS`のラベルは文字コードそのものではなく、それに対応するCharIDにしています。

しかし、このCharIDをかなり雑に決めたところがあり、なぜか入っている文字やなぜか入っていない文字があります。

この辺りは一度再設計したいのですが、これもやはり上記のマイグレーションが必要になります。

## 品詞IDの設計

品詞IDは「ipadic+独自拡張」という形になっています。具体的には、かな漢字変換上分離したほうが良い3つの品詞を追加しています。

* 1316: EOS（文頭と文末は区別されるべきである）
* 1317: ？（疑問助詞等との接続の可能性が高い）
* 1318: ！（強意の助詞等との接続の可能性が高い）

しかし、ipadicはさまざまな点で難しい面のある品詞体系です（[参考](https://zenn.dev/azookey/articles/c201408af14ae0)）。もし最初から作り直すのであれば、品詞IDはUnidicのものを用いていたのではないかと思います。

上の2つと違って、品詞IDの変更は現実的でないと考えています。というのも、辞書生成モジュールを含む無数のコードでipadicが前提となっており、作業量が膨大になりすぎるからです。もちろんマイグレーションも必要になります。