形態素解析辞書の使用感まとめ(2020/11/21) https://marmooo.blogspot.com/2020/11/blog-post_21.html
OpenBSD(uaa@), Ham(JG1UAA), Ingress(Lv14, RES), Japanese(Sagamihara-city, Kanagawa)
Another side: https://social.tchncs.de/@uaa
npub1rarr265r9f9j6ewp960hcm7cvz9zskc7l2ykwul57e7xa60r8css7uf890
Messages from this Mastodon account can read via mostr.pub with npub1j3un8843rpuk4rvwnd7plaknf2lce58yl6qmpkqrwt3tr5k60vfqxmlq0w
WSL2上のLinux環境、雑に作って雑に消せてしまうのでその都度設定してるような。
でもVMware Playerの使用頻度も随分落ちたような。超漢字を動かす機会よりも、むしろWSL2のおかげでVMware上のLinux仮想マシンの出番が激減してる。
Bulldozer系(Kaveri)のA8/A10使ってましたけど…iGPUの性能もあり、そんなに悪い印象はなかったですね。VMware Playerを動かすとBSoDすることがあったり(※)、VMware Player上でWindows9xがちゃんと動かないことを除けば、ですが。
(※)VMWareとAGESAの問題らしく、VMwareにもマザーボードのメーカーにも見捨てられていた
仮想化(およびその上で古いWindowsを動かすこと)さえ考えなければAMDは良いのですが、ちょっとそうは言ってられない状況なので今はIntel使いになってます。
SMT(HT)はパイプラインストールとかで空いてる演算器を無駄なく使おうって機構なので、単純な性能向上はオマケ程度の期待だろうけど、なら整数コアは2つ分あるけどあんまり使わないor重いFPは共有して「コア数」増やしたら有利……はともかく、シングルスレッドケチりすぎて大爆死したのがBulldozerだと理解してる。ZENのプラン見た時の奇跡の安堵感……。
「同時に5体の3Dキャラが 60fps でなめらかに演技」
「眉,白目,瞳,ハイライト,瞼をリアルタイム合成」
「プログラマブルな視線制御」
「髪揺れ等」
「フルスクラッチ開発」
「設計を入力するとソースコードを出力」
「常駐コードサイズは約600KBytes」
「L2 cache に全部入る大きさ」
「(sqlite は) 要求に対してオーバースペックすぎ」「(DB を) 結局自前で作った」
?????
格安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とか、他の形態素解析エンジンの利用もあり得る…と。
物を数えるのに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/
このアカウントは、notestockで公開設定になっていません。
全文検索システム『ひまわり』/『日本語学習者作文コーパス』の利用(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変換ケーブルの手持ちも無いかなあ…
NAISTの日本語コーパス、利用申請出してから1時間経過していますがまだお返事はありませんね…やはりどこの馬の骨とも知れぬものにデータは渡さぬわ、でしょうかね。1時間で判断するのは拙速なのでもう少し待ちますが。
(メールアドレス、面倒だったので日頃使ってるフリーメールの奴にしてたけど…昔所属してた研究室のアドレスを使った方が良かったのかな)
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の項みたいに。