興味の対象が変わったり、参照すべきリソースやアウトプットとなるものが変わっているので、そりゃ仕組みづくり(システム化)できないのも、当たり前っちゃ当たり前なのだった。しかしまあ、考える。

知識のインプットとアウトプットをシームレスに行うための仕組みづくりを、これまでずっと(それこそ学生の頃から)考えていたんだけれども、いまだにできておらず、騙し騙しやってきた感覚があるのであった。今年は少し考えるかな、と。

・手順の定義
・入力
・出力

を、うまく分かりやすく表現する。

プログラミングする利点として、計算の手順をルールとして決めておけば、大きくて複雑な入力(パラメタ)が来ても、速く正確に(※誤差はひとまず措く)計算できるとゆモノがある。この感覚に慣れるところから始めるのがいいだろうか。するとパソコンが必要ではあるなー。

もうひとつは、早期教育でおなじみの制御系になるのだろう。ロボットを操作するもの。これは分かりやすいけれども、プログラミングの概念としてはやや分かりづらい気がしている。

あ「姉姫は校庭をグルグル走ります」
姉姫「またおなじ?(・ω・)」
あ「同じだよ。走り終えた姉姫は、飴を10個持ってました。何周走った?」
姉姫「3しゅうで6こ、4しゅうだと10こ…あ、4しゅう(・∀・)」
あ「当たり(・∀・)じゃあ、231個持ってたときは?」
姉姫「しらねーよ!(`・ω・´)」
あ「そゆのをコンピュータに計算させるのが、プログラミング」
姉姫「ほう(・ω・)」

あ「姉姫は校庭をグルグル走ります」
姉姫「あい(・ω・)」
あ「1周目には飴を1つ、2周目には飴を2つ…と、回った数だけ飴をもらえます」
姉姫「5しゅうまわると、5つもらえるの?(・ω・)」
あ「そう。じゃあ、3周走ると姉姫は何個の飴を持っているでしょう?」
姉姫「さいしょひとつで、つぎにふたつもらえて、そのつぎみっつだから、6こ(・∀・)」
あ「当たり(・∀・)じゃあ、5周走ると?」
姉姫「6+4+5だから15こ?(・∀・)」
あ「当たり(・∀・)じゃあ、120周走ると?」
姉姫「できねーよ!(`・ω・´)」
あ「コンピュータならあっという間に計算してくれるんだよ。その計算をさせるのがプログラミング」
姉姫「ほう(・ω・)」

教材としては、あと、身近な材料で簡単に作れるものがいい。特別な材料や特殊な整形が必要なものだと、それを作ることが目的になってしまう。少なくともプロトタイプは簡素なものでいい。

プログラミングの原初的なステップは、おそらく「手順をルール化する」とゆことだろう。自分の子供を見る限り、手順自体は2歳半くらいから分かってきていると思う。それを静的なルールとして把握できるようになるのは、4歳半~5歳くらいになるのを待つことになる。自分でルールを組み立てられるようになるのが、5歳~6歳くらいから。

パソコン無しで、プログラミングの素養を養う教材を考えている。5歳くらいからできそうなやつ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Show more
mstdn.jp

Mastodon日本鯖です.