あー、これ詰んだかも。kakasiによる読み仮名の付与、言語モデル作成後にやらないとダメだわ。
ngram-count -text tune.text -write-vocab tune.vocab これでmixture weightsの調整を行うんだけど適当な文をtune.textで解釈させる以上、ここで読み仮名付いてると解釈の邪魔。

コーパスの掃除と、言語モデルの読み仮名付与の二段階でやらないといけないっぽい。あと、weights調整用のサンプルの用意（どうやって？）。無い状態でごり押し、という手もなくはないだろうけど。

gmake MACHINE_TYPE=i686-m64 World

昔からオーディオは宗教だと思っている（異論はあるだろうけど、そう思わせることをしてきたという事実は認識してほしいかも

togetterでまとめている割に、鍵垢で読めないツイートです！残念！！というのを見せられると、すっごく感じ悪いですね…（鍵垢のツイートをtogetterでまとめることができてしまうのも問題なのかも）

いや、単語→識別子、である以上は<s></s>も単語として扱うんだと思う。
unigram: P(<s>), P(word), P(</s>)だと、bigram: P(word|<s>), P(</s>|word)になるから、<s></s>に対応する確率を格納する場所は作っておかないといけないし組み合わせの数としても考慮しないとおかしなことになってしまう。

とはいえ…1-gramの結果を見れば分かるんじゃないのって気もするんだけどそれはまあなんか理由があるんでしょう、シロートでは分からない何かが。

vocabsizeとtotalcountについてはngram(1) http://www.speech.sri.com/projects/srilm/manpages/ngram.1.html の-count-lmオプション見ろって書いてあるじゃんSRILM-FAQ… http://www.speech.sri.com/projects/srilm/manpages/srilm-faq.7.html

totalcount C: " C the sum of all unigram counts"→ じゃあ<s></s>も含めたカウントで良いんだよな？
vocabsize V: "V gives the vocabulary size" http://lintool.github.io/UMD-courses/CMSC723-2009-Fall/session9-slides.pdf では"vocabulary size or number of unique words"ってあるから…1-gramに含まれる単語のうち<s></s>は除いたもので良いんだろうか。

日本語ウェブコーパス2010の、1-gramのデータ、これって単語とその出現数の一覧（確率になっていないので）と何が違うんだろうか…？

グラッパってボトルで買うと結構高いんだよなあ…とはいえ、サイゼリヤのワインを扱っていると言われるADDA WINE SHOPでまだ売られてるなら一本買うのもアリな気はする（他の酒屋でも大体\3k～\4kはする代物なのです）。 https://adda-wine.com/products/gra0001

（税込み\300って、以前より安くなってない…？）

大航海時代Onlineやってた身としては（ちなみに酒宴スキルR15なキャラも居るぞ）、グラッパは気になるお酒なのです。復活したのなら、機会を作って飲まねば…

サイゼリヤ、グラッパ復活したの？だったら行くしかないか…

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

となると、観測された（テキストを単に形態素解析した）生データだけで出現率を計算してもダメで、言語モデルに落とし込んだうえで.arpa作らないとそりゃあ処理する側も困るってことになるか。

2-gram, 3-gramに出てくる単語は1-gramに依存するという作り方をするなら、1-gramの結果から単語一覧を構築ってことになるんだろうかね。（なので2-gramでしか出てこない単語とかやられちゃうとsortlm.pyがコケるとかそういう話になるんだろうか）

無償で配布されるオープンソースソフトウェアの日本語かな漢字変換エンジンで用いる変換辞書の構築、という目的は果たして「営利」なのか「学術」なのか「一般」なのか…やっぱ一般なんだろうな。

まあ学術利用のお値段よりも安くできないよね、無償のオープンソースで利用するからと言って。

https://chunagon.ninjal.ac.jp/offlinedataappl?target=BCCWJ

中納言の一般利用\200k、まだGoogleコーパスの\44kの方が安いけど…そんなお金払う余裕は無いですからね。

1-gramのカウント数と、単語の出現頻度は同一になるのかどうかが分からない。
totalはそのコーパス内でのトークン数だってことはまあ分かったけどさ。
https://catalog.ldc.upenn.edu/docs/LDC2006T13/readme.txt

（重要なドキュメントを他ドメインの鯖に置くと信用されないよ、ってマックで女子高生が言ってなかったっけ…？）

何故日本糖尿病学会 http://www.jds.or.jp/ のPDFが杏林舎 https://www.kyorin.co.jp/ に置いてある…？（学会関連の支援と会社概要にはあるようだからそういうことなのかな）

オゼンピック皮下注 SD の出荷調整および出荷停止に対して
2 型糖尿病患者への安定供給確保のための要望書 (2022/2/23) http://www.fa.kyorin.co.jp/jds/uploads/ozempic_mhlw_2022-02-23.pdf

去年の時点で、こう。

保険診療においては厚生大臣が承認した（＝添付文書の）効能・効果に従うことが前提ではあるんだけど…美容整形は保険の対象外、自由診療なのでその辺の縛りは緩いんじゃないかなあ多分。

とある糖尿病治療薬の品薄が続いていて、必要以上の処方はするなとか糖尿病治療以外の目的で処方するなといったお手紙を見たことがあるんだけど…現実問題としてさ、製薬メーカーだって商売なんだから国が定めた薬価よりもお金積まれたらそっちに卸すってもんじゃないのかなって思うんだけど。実際、「違う目的」の方が羽振りが良いみたいだし（それに伴って薬価も上がるんじゃないかなあ、今後）。

（ちょっとこっちで書く）
3日で救援の手をって…首都直下で大地震起きてそれが実現できるかはかなり疑問なのと（その地域で消費するリソースがあまりにも多すぎる）、首都周辺地域に関してもおそらく救援リソースを首都に搾り取られるので周辺地域の救援は進まないどころか見捨てられる可能性すらあるんじゃないのと感じたのが3.11。

だからといって、対策をするわけでもなくのんべんだらりと過ごしているダメダメな人なんですけど＞自分

telnet BBS…LAPM-Vみたいにさ、モデム側で圧縮したかのような…速度の揺らぎとかを久々に見てみたいよねとか老害的発言をしてみるｗ

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

そもそも、libkkc-dataの作り方について、明確なドキュメントが無い（こんな感じのデータ使って作りましたって話だけで、生成手法が示されていない）っていうのは地味に問題だと思ってる…辞書の強化ができる訳でもなく、同じデータを再現できるわけでもなく、何かから作られたらしい辞書がぽんって置いてあって、風化していくだけ。

あと、libkkcってかな漢字変換APIと仮想端末API（名称は適当につけてます）が分かれているようなんだけど、SKK辞書による補完が効くのは仮想端末APIを通した場合だけで、かな漢字変換APIIからはdata.arpaによる辞書しか使えないのは結構ツラい。

…という話が書ける程度には、なんとなく触ってたりする。Vala(+GNOME)さえ動けば載るって意味では素性が良さそうなだけにlibkkcはもっと頑張ってほしいんですよ。今となってはちょっと古いのかもですが。

元のdata.arpa、2-gramsから-0.737709 <s> </s> -0.636446を取っ払っただけでもsortlm.pyがエラーを出すってことは、これが要るんだろうか（でも変換元の日本語ウェブコーパス2010にこんなのあったか…？）。もしくは、1-gram/2-gram/3-gramのデータが全て関連付いていないといけないとか。

今の時代なら、ヘンに悩むよりかは日本語ウェブコーパスにある作成用のテキストデータを使って、テキストマイニングしてdata.arpa作る方が確実なのかも。読み仮名の追加もkakasiじゃなく、形態素解析に使うmecabで揃えられるし。

とはいえ、それをやるだけのストレージが無い…（だから作成済のN-gramで足掻こうとしてる）

やっぱでっち上げたデータの正当性チェックかな…2-gramのパースで死んでるので、2-gramのデータに何か問題があるんだろうなあ…

Cで書いたコードを（C++が必要になったので）C++化した際に引っかかったんだけど…あんましgotoでエラー処理しちゃうのも良くないのね。C++っぽい、使う場所の近くで変数を宣言する…という記述ができなくなるとは。

C++のgotoにはまった(2009/05/17) https://dai5891.hatenadiary.org/entry/20090517
C++のswitch文で「crosses initialization of～」というエラーの対処 (2017/2/23) https://www.koikikukan.com/archives/2017/02/23-000300.php

「n-gram言語モデルのような古いモデル」
N-gramは古いのか…

2018年の言語モデル概要(2019/02/08) https://engineering.linecorp.com/ja/blog/overview-2018-language-models

ANYKS LM(ALM) https://github.com/anyks/alm https://anyks.com/ どうなんだろうこれは…

libkkc-dataのdata.arpaとの挿げ替えも試してはいるのですが、tools/sortlm.pyが
File "/usr/ports/pobj/libkkc-data-0.2.7/libkkc-data-0.2.7/data/models/../../tools/sortlm.py", line 147, in <listcomp>
items = [(struct.pack("=LL", ids[1], unigram_offsets[ids[0]]), ids) for ids in keys]
IndexError: tuple index out of range
というエラーを吐いて機嫌が悪くなります。

お休みだったので朝からN-gram (.arpa)ファイルっぽいものを作るようなのと格闘してたんですが…でっちあげた（出来上がったとは口が裂けても言えない）物がどの程度正当な物かを評価する手段ってなんかありますかね…？
N-gram(.arpa)を使う適当なアプリケーションがあれば良いのですが。

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

？？？ 手本となる看護実習記録の「情報収集」から「アセスメント」への展開における短単位n-gram と対数尤度比を用いた特徴的な表現の分析 (金城学院大学論集. 人文科学編 18 (2), 236-243, 2022-03-31) https://cir.nii.ac.jp/crid/1050855809822254720

data.arpaには<unk>無いんですよね…

ん、でも待てよ？（自分の理解足らんかも）

smoothingは<unk>に対してどう出現率を割り当てるかって話、backoffは<unk>出現時に(N-1)-gramの候補を精度よく選び出すためのヒント、そういう話で良いのかな。

どんなsmoothing使ってるかは分からないけど、単語数が少なければ計算結果が大きく変わるのは当然か。

n-gram probability count in ARPA file https://stackoverflow.com/questions/29151773/n-gram-probability-count-in-arpa-file (2016/7/16) 自分と同じ疑問だ。1-gramは分かるけど2-gram以降の計算って、ってやつ。

smoothingが効いてるから思った通りとは違うよん、って回答があるな。

https://cmusphinx.github.io/wiki/arpaformat/　1-gramの確率はなんとなくわかるけど、2-gramの確率は分かんない…

SI485i : NLP Set 4 Smoothing Language Models https://www.usna.edu/Users/cs/nchamber/courses/nlp/f13/slides/set4-smoothing.pdf ８ページ目からのLaplace smoothingの説明がまだわかりやすいのかな。

とりあえず今使えそうなものでそれっぽいものを仕立てて、それを食わせたらどうなるか…まずはそこから始めないことには。

あと、kakasiで強引に読みを付けてしまうのだけど…読み順にソートし直さないといけないのがちょい面倒。kakasiの限界もあるだろう（chasen/mecab/jumanなどを使った場合にどうなるかというのも課題になるか）。

3-gramの有効なエントリ数は4251526、出現数の総和は3342176718、3-gramについてはこれで出現率は出せる（1-gram/2-gramについても同じ方法で出せるんだろうが）。

問題はバックオフだよなあ…

(page28)「コーパスのサイズが大きくなるとスムージングの性能差がなくなる」、コーパスのサイズが大きくなるとスムージング（バックオフ）の有無の差がなくなる、ではないんだよなあ…？

言語モデル入門 （第二版）(2014/10/19) https://www.slideshare.net/yoshinarifujinuma/ss-40451841

data.arpaを見るに、1-gram, 2-gramはbackoff値あり、3-gramは無し。1-gramについては</s>はbackoff値無し、<s>は-99かつbackoff値あり。

このbackoff値をどう求めるか、というのは難しそう…sortlm.pyでもしっかり参照してるし。

ゆれたねえ

どうやら問題を見誤ってたみたい。日本語ウェブコーパス2010、N-gram化は済んでいて頻度の値が出ている以上、ここから出現率（とバックオフ値）を計算して.arpaに落とし込むという作業をしないとダメなんだろう。srilmに食わせるんじゃなく。

スマホで十分撮れるのにスマホじゃない物をわざわざ持ち歩いてどうすんの、しかも重いし金かかるしという…価値観の違いなんじゃないかなあ。日本のデジタル一眼離れ。

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

https://nostryfied.online/ とりあえず自分のデータとやらを落としてみましょうか…

形態素解析辞書の使用感まとめ(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の項みたいに。

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

uaa@framboise:/usr/include$ echo ○１ |nkf -e |kakasi -KH -JH | nkf -w
○１
uaa@framboise:/usr/include$

変換できないものは素通しか。

https://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/JIS0208.TXT 自体はUnicode Term of Useに従うとして、派生物もそれを継承するって理解で良いんだろうか？
いちいち書くのが面倒なのでSPDX-License-Identifier: Unicode-TOUと書くけど。 https://spdx.org/licenses/Unicode-TOU.html

https://github.com/loretoparisi/kakasi/blob/master/kakasidict

kakasiはUTF-8に対応するものの、kakasidictはEUCで書かれているが故にEUCの範囲でしか漢字→かな変換はできない。【】などの記号類や全角英数字に対する読みも未定義。

…ってことは、UTF-8をそのまま食わせても良いんだけど、処理可能な文字が含まれているかどうかのチェック＋EUC化みたいなフィルタを入れた方が安全なのかもしれないな。

ASCII(0x00-0xFF)の範囲は蹴るようにしていたけど、JISのひらがな・カタカナ・漢字以外の部分（記号とかアルファベットとか）も蹴った方が良いのかもしれない。

OpenBSDにおいては、wchar_tはintと定義されてるみたい。負のキャラクタコードもアリなのか…（無いよね？）

ああ、思考を垂れ流しにしていますが実行するかどうかは別問題ですのでー

でもdata.arpaを見るに、
-2.131363 おたく/オタク ？/？ -0.072304
みたいに変換できなかったものも平然と？で出てくるので、あまり厳しいことをしても意味は無いのかもしれない。

とりあえず何が削られたか、という一覧も要確認か。

obsoleteだが…ここに定義されている文字が含まれていない（UTF-8→JISへの変換ができない）エントリは無条件で除外、ただし<S></S>の類は除く、みたいな処理にするか？変換テーブルは https://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/JIS0208.TXT を使えば良いかな…

libkkc-data（のdata.arpa）が如何にして作られたか、という作り方がどこかに書かれていれば、その作り方で適当なコーパスを食わせて…ということができるんだろうけど、無い以上は模索するしかない。作者に聞けばすぐに答えが出てくる問題という気もするけど。

uaa@DESKTOP-251U0UF:/mnt/e/corpus/nwc2010-ngrams/word/over999/3gms$ echo "かな 漢字 ヘンカン" | nkf -e | kakasi -KH -JH| nkf -w
かな かんじ へんかん
uaa@DESKTOP-251U0UF:/mnt/e/corpus/nwc2010-ngrams/word/over999/3gms$

kakasiでまとめて処理、で良さそうだけど…UTF-8非対応って辺りがまた難易度高いな。kakasiで処理が難しそうなデータも、事前に切っておく必要があるんだろうね。

でもsrilmの出力は<s></s>化されているので、ここは気にしなくて良いかな…？

多分問われないとは思うんだけど、日本語webコーパスは</S>、libkkc-dataのdata.arpaは</s>なのでこの辺も似せておく必要がありそうな気がする。

ngram-format http://www.speech.sri.com/projects/srilm/manpages/ngram-format.5.html を見るに、ngram 1=n1のn1はエントリ数になるから、後加工でも大丈夫そう。あと、多分半角英数とか記号だけといったデータは元データから省いた方が良さそうな気がする。

なんだろうこれ…
鼻 で 息 4389
という元データを、
はな/鼻 で/で いき/息 4389
みたいな形に加工してから食わせるのか、あるいは出力された3gram.txtの結果を処理するのか（でもARPAヘッダの存在を考えると元データ側に手を入れてそうな気がする）

出現頻度1000以上の形態素N-gram(3-gram)をsrilmで処理するのにかかった時間は3分くらい。出力された3gram.txtはARPA形式なので、冒頭が
\data\
ngram 1=236180
ngram 2=5654587
ngram 3=1355192

\1-grams:
-4.257625 " -0.3292079
-7.02774 "" -0.2590316
となってる。一方、libkkc-dataのdata.arpaは
\data\
ngram 1=118333
ngram 2=775414
ngram 3=1777469

\1-grams:
-2.105448 </s>
-99 <s> -0.203198
-4.499434 ’/’ -0.277539
-5.607917 ’’/’’ -0.262133
-5.793264 ’・/’・ -0.118066

…コーパスをそのまま食わせるのでは多分ダメ。

…ノウハウの確立にそこまでデカい（取り回しの悪い）データ使う必要、無いんじゃないのかなあ自分。
日本語ウェブコーパス2010の、頻度100以上を使っているけど…1000以上で始めた方が…？＞自分

xzcat *.xz > 3gm
~/srilm/bin/i686-m64/ngram-count -order 3 -text 3gm -lm 3gram.txt
一体何が出てくるのやら

実は"abc"[1]の代わりに1["abc"]なんて記法ができるなんて、今の今まで知らなかったです…知ったところで使いようがないんですけど。

難読化の話（超！？入門編） (2018/07/26) https://netagent.co.jp/study/blog/hard/20180726.html で紹介されていたUnderstanding Misunderstandings in Source Code https://atomsofconfusion.com/papers/understanding-misunderstandings-fse-2017.pdf 、Table1の「べからず例」は結構やってしまっている箇所があるな…まあstyle(9)で{}の括り方が規定されている以上、これについては言ってくれるなというのがあるけども。

if (4 % 2)みたいな0→falseを前提としているとか、三項演算子は結構好んで使ってたりする。

表に出ないソースコードは難読化なんてしないけど、web領域だと見えちゃうことを避けられないみたいだし…開発時は普通に、webサーバ上に上げる時は難読化するとかそういうことくらいはしていてもおかしくない気が。

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

SystemGear製の抗菌磁気カードリーダー(PDC-30) https://www.systemgear.com/prd/magneticcard/pdc30/pdc30.html に見えますね…面白そう。

SXGAからFullHDへ移ってはみたけど…確かに最近、手狭になってきたような気がする。80×30字のコンソールを6つも開けるようになったのは確かに広いっちゃ広いんだが…それだけ開いてる訳でもないし。

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

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

デバイス系よりweb系の方が、ソフトウェアによるソフトウェアのって部分があるので色々介入しやすそうですね…最悪の場合、ブラウザに手を入れて動きを見るなんてこともできそうですし。

んー…
https://js.gsspcln.jp/t/399/201/a1399201.js はかるーく難読化かけてるみたいだけど
https://works.gsspcln.jp/w/ad_format/gnScrollCatch_multi.js ってそういう小細工してないですよね。
こういう手合いについては詳しくないんですけど、この前マクドナルドで飯食ってた時に「素性を抜かれないようにあれこれ細工するのが基本」って女子高生が言ってた気がします。
自分みたいなシロートにどこどこの企業か…なんて突き止められるのって、その基本ができてないってことなんですよね？

gssprt.jpに関しても、同様に http://geniee.co.jp/ が窓口になってますねえ…

悪名高きスクロール妨害広告を解析する (2023/8/25) https://qiita.com/reika727/items/5a3cbdd211f79f82fdd5
Javascript中に出てくるgsspcln.jp、whoisすると http://geniee.co.jp/ が連絡窓口って出ますね…

悪名高きスワイプ広告を解析する(2023/8/10) https://qiita.com/huzisuke/items/cdc63b4bf9d2ded5b5ca

このスワイプ広告は本当にウザくって、作った人間ごと滅ぼそうぜって日々思うんだけど…どうせ滅ぼしたところでもっとタチの悪いのが出てくるんだろうなとも思う。

自分の端末だと、これが表示されると記事をスクロールできなくなる（スワイプ広告を上下にスワイプしてもどかすことができない）ので本当に邪魔なんだよね。広告の脇に少しでもマージンがあればまだマシなんだけどそんなのは当然無いし。

それにしても、GNU/non-GNUの文脈で語られてしまうというのはちょっとどうなのって気はする。

コンパイラだっていつまでも提供され続ける訳じゃないのだから、違うコンパイラでも動かせるようにするという試みって、思想（ライセンス）の問題よりもはるかに重要だと思うんだけど。

Chimera Linux https://chimera-linux.org/ がそれっぽいな
非 GNU な Linux ディストリビューション (2023/2/15) https://linux.srad.jp/story/23/02/14/190237/
A Non-GNU Linux Distribution Built With LLVM & BSD Software Aims For Alpha Next Month (2023/2/6) https://www.phoronix.com/news/BSD-LLVM-Linux-Alpha-Coming

GNUあってのLinuxなのでデフォルトのコンパイラはgccを使い続けるんだと思うけど…カーネルからユーザランドまですべてclangで構築したLinux distroってあるんだろうか。

LPCNet、ベンチマーク取り直して後はぶん投げる（SSE4.1をデフォルトにするか、今まで通りAVX主体でいくかを決めるのはこっちじゃないし…Pentium G4600持ちな身としてはSSE4.1がデフォでいーじゃんとは思うけど）。

https://github.com/drowe67/LPCNet/issues/62

uaa@slackware-vm:~/LPCNet.drowe67/build.sse/src$ time cat test.out | ./lpcnet_dec -s > /dev/null
direct split VQ
dec: 3 pred: 0.00 num_stages: 4 mbest: 5 bits_per_frame: 52 frame: 30 ms bit_rate: 1733.33 bits/s
64 1 1 16 128 1152 160 160 160 160
ftest cols = 2002

real 0m10.858s
user 0m10.753s
sys 0m0.085s
uaa@slackware-vm:~/LPCNet.drowe67/build.sse/src$

slackware付属のgcc-11.2じゃなくclang-13でビルドしたら、i686でもなかなか実用的なパフォーマンスが出ますね…

※どういうお仕事をしているかはなんとなくバレていると思っているし、web日記のどこかにきちんと書いてあるからいちいち書かなくても大丈夫ですよね…？（なので尋ねられても言葉を濁します）

ま、お客様なら敬語で遇されて当然、な意識の染みつきまくってるネイティブ日本人にこの考えは到底受け入れられないだろうとは、思う。

接客業なお仕事をしている身としては、高齢者とかちょっと認知症入っちゃったような人だとやさしい日本語レベルまで情報量減らさないと伝わらないという現実があるし、そういう人達が増えてるならもうデフォルトがそのラインで良くね？って気がするんだよね。

労働者が少ない、その割には客が多い（なんかまた増えてるらしいじゃん色々と）となると、減らせる労力は減らして提供すべきサービスをきちんと提供できる体制にしないと滅んでしまうんですよね、みんなが。

「⑩ 相手の日本語の力が高い場合は「やさしい日本語」を辞める」どうなんだろうこれ、相手の日本語力が高ければ「それは『やさしい日本語』」と解釈してくれる以上問題無いのでは…？と考えてしまうんだけど。

どっちかっつーと、「やさしい日本語」を基準にして、相手に応じて言葉を盛っていくというスタイルが標準、の方が良い気がする。日本語苦手そうだからやさしい日本語on、ネイティブ日本人だからoffというのは、自分の感覚ではなんか違うなーと感じてしまう。

やさしい日本語（医療×｢やさしい日本語｣研究会 ）(2021-05-24?) https://easy-japanese.info/about-easy-japanese

「〇〇が好きなやつには申し訳ねえが、俺は〇〇が大っ嫌いなんだ、誰が何と言おうとな。だがまあ〇〇が好きなやつが〇〇が好きだということに対して否定する気も無いし、俺が好きになれない〇〇を好きでいられるというのは正直羨ましいぜ。」って辺りで、どーよ。

お気持ち→感情論じゃねえか（本文中にもそう書いてある）

なるほど、腑に落ちた。「お気持ち表明には善悪を持ち込まないことを徹底してください。｢こんなの正しくないよ｣ではなく｢こんなの嫌いだ｣です。（中略）私は好き嫌いの話しかしていないけど正しいのは私だぞの気持ちでいれば大丈夫です。」
今日から始めるお気持ち学 (2022/3/12) https://note.com/noty_ice/n/n4b3e28f465bb

実は「やさしい日本語」程度の情報量で足りるのかもしれない。敬語が使えないから人間失格！死ね！殺せ！とかならないで済むわけだし。

積極的に意思疎通プロトコルの破壊を目論んでいる輩も多そうに見えますねえ…（空気を読め、というのも一種の意思疎通プロトコルの破壊に思えていて、言語*外*という具体的な定義の無いものに意思疎通を大きく委ねてしまっていることを正当化するのは非常に危険だと自分は考えてしまう）

まいじゃー推進委員会の全盛期が懐かしいのぅ

個人的にはとらドラよりも田村くんだなあ…

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

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