英語圏をはじめとした文字の認識も、アルファベットを一文字ずつ読んでいるわけではなく、分かち書きされた単語単位をパタンとして読んでいるみたい。

Cambridgeとゆ単語について、単語の最初と最後の文字を以外をランダムに入れ替え、例えばCabmridgeとしてもCambridgeと読めてしまう。BoWとかの発想も、ここら辺から基礎づけることができそうに思う。

まだその手の研究を読んでいないので、当てずっぽうだけれども、特に漢字圏では、文字は様々なアスペクトから「読まれて」いると考えられる。個別の文字のグリフはもちろんだけれども、それ以外の情報もヒントにしている。

例えば、文字列を系列として考えたとき、知っている語彙と前後の文字から確率的に判断できる。これは姉姫の例。

また、漢字の部首から音を判断することもできる。例えば「誰何」とゆ言葉はあまり知られてないけれども、旁を見れば「誰」の旁は推論の「推」と同じだし、「何」の旁は可能の「可」なので、勘のいい人は「すいか」と読むと分かると思う。

日本語の文字は全て集めると、約12000種以上ある。常用漢字に絞っても2136文字ある。これらを文字のグリフだけから機械的に「読む」のは、ほぼ不可能だと思う。文字の読みと意味を絞り込み、瞬時に判断していると考えられる。

小学1年生の姉姫が「たんぱく質」とゆ言葉を読んでいたんだけれども、この子は「質」とゆ漢字を知らない。でも読めてしまう。「どうして読めたの?」と聞くと、「『たんぱく』はひらがなだからよめるし、そうしたら、つぎにくるのは『質』でしょ?」と言う。

「たんぱくしつ」とゆ言葉は保育園の頃、食育で教わったのだった。確率的に「たんぱく」に続く言葉(音)は「しつ」である可能性が高いと弾き出したのだろう。

画像処理関係の私的プログラムをまとめている。これまで、私的な実験用のワークベンチだったんだけれども、もう少し汎用的にならないかと云々。

この中で、文字列の切り分けの部分は、人間の認識からするとだいぶ不自然なことをやっている。古典的な方法で、今もよく使われている手法としては、横書きなら縦方向のプロジェクションヒストグラムを取って、値が閾値未満になる箇所で切るとゆもの。これは文字のパーツが分かれない欧文にはある程度有効だけど、日本語では対応できない。欧文もアルファベットを1文字ずつ読んでるわけじゃないので、どちみち切り分けのパラダイムは不自然になる。

OCRの基本的な処理の枠組みは、今も昔もそんなに変わっておらず、前処理→文字の塊をみつける→切り分け→識別みたいなことをやっている。性能の良し悪しはこの枠組みの中での改善であることが多い(あくまでも「多い」であるけれども)。

お、家内のパソコンはCore i3 6006Uなんだけれども、AVX2が入ってた。ラッキーである。AVX2使おうっと。

なかなか難しいんだけど、きちんと作るとかなりの効率化とアプリケーション自体の汎用化につながるのであった。

1ピクセルあたりのデータ型は8/16/32-bitの整数値(符合ありなし)と32/64-bitの浮動小数点数、それとこれらに対する複素数型がありえる。プレーンとゆのは、バッファの1チャンネル分でレイヤーみたいなもんだと思えばいい。結局これらを統一的に操作するデータ構造と、個別的に実装する手法をどう組み合わせるか、とゆ話になるのであった。

ビットマップ画像のデータ構造とゆのも、味わい深いテーマであり、なかなかいい具合にできず、作ったり壊したりを繰り返しているのだった。一番の問題は、画像に対する操作はほとんど共通しているのに、ピクセルの幅と次元、それとプレーンの枚数が異なること。最初はC++のテンプレートと継承で作ってたけれども、手間としてはそんなに変わらない。

語彙的意味と構成的意味を区別する理由が、文法的な説明に依存しているだけのように見える。まあ、素人考えだけど。、

含意関係分析における、語彙的意味と構成的意味の説明を読んでいるんだけど、この区別って割と相対的なもんじゃないのかな。

会社の事業を邪魔しない形で何かしらのアイデアを形にできればとは思うものの、いざ考えてみると、なかなかいいアイデアには出会えない。それだけ会社の事業に(悪く言えば)毒されているとゆことだよなー。

う…会社のメアドかと思ったら、ウェブサイトのメアドに、とある案件の引き合いが来ている…。いつも会社に届く引き合いメールそっくりだったので、まさかウェブサイトを見てこっちに来るとは思わなかった。
東証一部上場企業様から引き合いが来るとはなー…。しかし、工数的に余暇の範囲で対応できる案件じゃない(´・ω・`)

例えば、機械学習のプログラムでは、特徴ベクトルを学習や推論に使うけれども、特徴ベクトルの構成と学習/推論のインターフェイスは、そんなに変わらない。SVM/RVMだろうが、k-meansだろうがDNNだろうが、基本的にはベクトルの作り方と、それを使った学習/推論の過程は同じように扱われる。

一方、機械学習を利用した開発プロジェクトは、一般に様々な実験を伴うことが多く、中のアルゴリズムや特徴ベクトルと内容はゴリゴリと変わる。なので、きちんと設計している機械学習の開発者は、特徴ベクトルの作り方や学習/推論のアルゴリズムについて、ある程度共通のフォーマットを用意することになる。このフォーマットに合わせて開発すれば、その他の部分について、特別に考えなくても従来通りの挙動を期待できる。これが抽象化。

OOな言語を考慮するとき、開発規模の要素が強調されることもあるんだけど、実のところ、開発規模も副次的な問題で、結局、より根本的には、拡張や再生産を容易に行う仕組みをどれだけ簡単に作れるか、とゆ問題に帰着する。開発規模が大きくなると、プログラムの内容を逐一全部覚えることはできない(IDEを使ってても同じ)ので、部品ごとに分解して半製品化するアプローチが採られる。そのためのOOであり、抽象化だったりする。

オブジェクト指向でプログラムを書く際の要請は「書きやすい」とか「手早く作れる」とかではなく、言うなれば「保守・拡張しやすく書ける」なんだよね。なので、

(1)ある程度の規模のプログラム(数十万ステップ程度から)を「保守」したり「改修」したりするタスクがあること
(2)使い捨てでなく少なくとも5年程度は保守を続けるプログラムを書くタスクがあること

がないなら、はっきり言ってOOで書く意味はない。どんな言語で書いても結果は同じだし、OOな考え方で書くと、却って非効率になることもある。
逆に、これくらいの要請のないプログラムしか扱っていないなら、OOについてはまだありがたみが分からないんじゃないかと思う。

staticおじさんの話が再燃しつつあるようなので、少し書いておこうと思う。

qiita.com/minebreaker/items/45

んー…やっぱり熱くなるな…。CPUも低速で回ってるのに熱くなるってことは、もうこのパソコン、構造的に熱くなる仕組みになってるんだろうか。どうしよ。

もっと見る
mstdn.jp

Mastodon日本鯖です.