形態素解析辞書の使用感まとめ(2020/11/21) https://marmooo.blogspot.com/2020/11/blog-post_21.html

WSL2上のLinux環境、雑に作って雑に消せてしまうのでその都度設定してるような。

でもVMware Playerの使用頻度も随分落ちたような。超漢字を動かす機会よりも、むしろWSL2のおかげでVMware上のLinux仮想マシンの出番が激減してる。

Bulldozer系(Kaveri)のA8/A10使ってましたけど…iGPUの性能もあり、そんなに悪い印象はなかったですね。VMware Playerを動かすとBSoDすることがあったり(※)、VMware Player上でWindows9xがちゃんと動かないことを除けば、ですが。

(※)VMWareとAGESAの問題らしく、VMwareにもマザーボードのメーカーにも見捨てられていた

仮想化（およびその上で古いWindowsを動かすこと）さえ考えなければAMDは良いのですが、ちょっとそうは言ってられない状況なので今はIntel使いになってます。

格安USBホストマイコン CH559をいじってみた（大盛）(2021-08-02) https://q61.org/blog/2021/08/02/developing-with-ch559/ このサイトでなんかお洒落なフォント使ってるなー→ああこれがタイポスね、で調べてたって訳

タイポスはAdobe Fontsへの提供やめたのか… https://www.morisawa.co.jp/support/faq/6702

大量のテキストデータと形態素解析機と言語モデルでなんとなく変換辞書を作れちゃう（多分）と考えると、昔のかな漢字変換辞書ってどう作ってたんだろうかというのが気になるな。多分相当の人手あるいは時間を使って作り上げたんだろうなという気がするんだけど。

機械生成な辞書でもある程度の変換効率は出せるんだろうけど、多分最後は人の手を入れないと…という話にはなるんだろう。学習元のテキストデータの選定だの、言葉の利用頻度の調整だの、調整の余地はいくらでもありそうだし。

物理コアがたっぷり乗ればHT（論理コア）は滅びるさ、って話は昔どっかで見た気がするけど…意外とHTは生きてますよね。OpenBSDはセキュリティ向上のためHTをデフォルトで無効化していたりしますが（有効にもできます）。

kakasiに食わせて読み仮名を付けるのが適切なのかどうか、という問題もあるのか。
mecabとかjumanとか、他の形態素解析エンジンの利用もあり得る…と。

uaa@framboise:~$ cat test.cc
#include <cstdio>
#include <unordered_map>

int main(int argc, char *argv[])
{
std::unordered_map<int, int> m;

::printf("%lu\n", m.max_size());
return 0;
}
uaa@framboise:~$ c++ -std=c++11 test.cc; ./a.out
768614336404564650
uaa@framboise:~$

こんだけあれば余裕？（OpenBSD上のclangでの結果）

物を数えるのにstd::unordered_mapが使えそうだと思っていたが…max_sizeの制約があるのか。

srilmのソース見るに、本来ならvocabsize等の情報はN-gram作成時に生成されるみたいなんだけど…なんかそれを別途補わないといけないらしいってことらしい。

lm/src/NgramCountLM.ccのNgramCountLM::write()ないしread()辺りの処理から追っていけば、これらのパラメータの意味が分かるんだろうか。

NAISTコーパスをざっくり眺めてるけど、これどうやってsrilmに食わせて.arpa得るの…？

まだかなーと思ったら、google driveで共有できてた。スマホ見るまで通知来てるなんて知らなかったよ！

400GB程度のテキストなら、ストレージに余裕があればなんとかなるよね…って感覚だよなあ。困ったことにその余裕は無いんだけど。 https://www.s-yata.jp/corpus/nwc2010/texts/

これでもくらえ…TTYF?

このアカウントは、notestockで公開設定になっていません。

Xは課金してないので、この程度の文字数で意図が伝わってるか不安
https://twitter.com/uaa/status/1698613051585655013

全文検索システム『ひまわり』/『日本語学習者作文コーパス』の利用(2023/1/31) https://csd.ninjal.ac.jp/lrc/?%C1%B4%CA%B8%B8%A1%BA%F7%A5%B7%A5%B9%A5%C6%A5%E0%A1%D8%A4%D2%A4%DE%A4%EF%A4%EA%A1%D9/%A1%D8%C6%FC%CB%DC%B8%EC%B3%D8%BD%AC%BC%D4%BA%EE%CA%B8%A5%B3%A1%BC%A5%D1%A5%B9%A1%D9%A4%CE%CD%F8%CD%D1 とか、今後どうするんすかね…（利用できないみたいっすよそのデータ、と一声かけとく？）

日本語学習者作文コーパス http://sakubun.jpn.org/ も閉鎖になってるけど、そこにある全文データ http://sakubun.jpn.org/corpus/doc/data.zip も削除って…

「今後のため：10年前に比べ、現在はデータ収集も容易になりましたし、公開の方法も多様化しました。これからは，古いコーパスに頼ることなく、ご自分の力でご自分の研究デザインにあったデータを集めてほしいと思います。」というのは結構だけど、同じ手法でコーパスがどう変化したかとかだって立派な研究になるでしょうに…

何故SATAの電源ケーブルの長さが足りない→4pin/SATA変換ケーブルの手持ちも無いかなあ…

必要な時に必要なものがそこに無いの法則、発動！orz

NAISTの日本語コーパス、利用申請出してから１時間経過していますがまだお返事はありませんね…やはりどこの馬の骨とも知れぬものにデータは渡さぬわ、でしょうかね。１時間で判断するのは拙速なのでもう少し待ちますが。

（メールアドレス、面倒だったので日頃使ってるフリーメールの奴にしてたけど…昔所属してた研究室のアドレスを使った方が良かったのかな）

N-gramについてもGPGPUを使って色々できそうな感じだけど、当然CUDAの独壇場か…うぐぐぐぐ

イマドキの日本人は「盗んだバイクで走り出せ」という歌詞だけでケシカランケシカラン騒ぐって聞くけど…歌詞の評価はその歌が流行った時代背景を踏まえたうえで行うのが当然だし、それがその時代に対する最低限の礼儀になるはずなんだけど。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

ん－む、CUDAだとC++も使えるのか。OpenCL C++って無い訳じゃないけどあんまり聞かないみたいだし。 https://github.com/XapaJIaMnu/gLM/blob/master/gpu/gpu_search_v2.cu

コーパスにしろAIにしろ、元となるデータの権利問題が絡んでくるから…簡単には学習結果は渡さないよ（部分のチラ見せだけです）というのが基本思想になるのかな。

…なんか、最後は「権利上問題の無いテキストデータを大量に入手して自分で作ってね」という選択肢しかないような気がしてきた。10年前に比べれば使用できる計算機の能力は上がっているから、どこの馬の骨とも知れぬ個人がそういう領域で何か足掻いてみるというのも不思議な話ではなさそうではあるんだけど。

NAISTの日本語コーパスもなんかgoogle formっぽいもので個人情報出した後、さらにダウンロード申請という二段構え（意訳）なので今すぐにダウンロードできるわけじゃないっぽい…

他に使えそう（お金をかけずに簡単に閲覧できそう、という意味）なコーパスっていうとNAISTテキストコーパス https://sites.google.com/site/naisttextcorpus/ くらいなんだろうか。

なんか日本語コーパス作るとか使って何かするっていうのもブームが過ぎちゃったみたいで、コーパス日本語学の情報館 http://jhlee.sakura.ne.jp/ みたいに閉鎖しちゃったりリンクがどっか行っちゃったりで今から手を出すにはかなりハードル高い感じがする。

ていうかなんでlibkkcの辞書っぽいものを作ろうとするだけでこんな沼地に沈まないといけないのさ自分…

問題は（Google N-gramコーパスを使うなら）google.countlm.0の記述方法なんだよな。order 5じゃなく3-gramなのでorder 3になるだろうという想像はつくけど…vocabsize, totalcount, countmodules, mixweights, あとパスの指定はgoogle-countsで問題無いのかどうか。

Web日本語Nグラム第1版 https://www.gsk.or.jp/files/catalog/GSK2007-C/GSK2007C_README.utf8.txt でもvocab.gzを見よと書いてあるけど…日本語ウェブコーパス2010にはこれに相当するものがない。

元データが公開されてるなら、AWS借りるなりして自分で作れってことなんですかね…（まさか？）

どうやらやっていたことが激しく間違ってたみたい。
日本語ウェブコーパス 2010 https://www.s-yata.jp/corpus/nwc2010/ から形態素N-gramの頻度1000以上のリストで、3-gramのデータだけ引っ張ってあれこれやってたけど多分1-gram, 2-gramのデータも必要なはず。

あと、Google N-gramコーパスと同様にってあるけど…多分srilmでの処理もそれに準じた扱いにしないとダメなんだと思う。SRILM-FAQ http://www.speech.sri.com/projects/srilm/manpages/srilm-faq.7.html のB6の項みたいに。

本日はお休みを頂いとります

X32とか、もっと流行っても良かったはずなんだけど結局廃れちゃった…

このアカウントは、notestockで公開設定になっていません。

（でもCPUのレジスタ数が増えるとかビット幅が増えると、コンテキスト退避/復帰のコストがかかる訳で、それがリアルタイム性にどの程度影響を及ぼすのかという問題はあるんだけど…多分気になるならFPGAとかもあるしハードウェアでやっちゃいなYO!というのが今の時代と理解している）

ARMv8(64bit)でRTOS使いたいって呟きをTwitterで見たけど、「64bit環境で何すんの？32bitで十分じゃね？」と思ってしまったのは自分が古い人間だからなんだろうなあ。

多分、「32bit環境でRTOS？16bitで十分じゃね？」という歴史の繰り返し…

ARMv8になってからATF必須…みたいな流れを見ると、それに嫌気がさしてRISC-Vどうなん？という話になっているのかなーと感じてしまうのだけどRISC-Vな板を何も持ってないのでその感覚が正しいかどうかは何とも。

以前居た某社、業務の都合上ベアメタルにこだわっている部分が（あの頃は）非常に強かったのだけど今もそうなんだろうか。

OrangePi One Plus(Allwinner H6)向けのU-bootのビルドを試してみたけど、なんかARM Trusted Firmware(ATF)が無いと動かないようになっていて、なんつーかベアメタルで触るのではなく既に動いているブートローダの上で何かをした方が良さげという…