内容のあることを書きたいからです。最初は大文字、ピリオドはなし、ということになっているようですので、(最近は)それを守っています。あとぼくは基本的に英語で書きますが、日本人だけしかいないなら日本語でもいいと思います。したいのなら、日本人としては残念ですが英語が標準語になってしまっているので、英語で書いてください。まともな高卒ぐらいの英語力があれば伝わるものは書けると思います。2行目2行目は空行です。ツール類に1行目をタイトルだと認識してもらうため、必ず空行です。3行目以降ここからが本番です。このパッチが解こうとしている問題が何なのかを述べるようにします。このパッチがなかったら、どういうまずいことが起こるのかをレビュー者に伝えます。このパッチに対応するチケットに問題が詳細に書いてあっても、「このパッチで」解こうとしている問題を述べるようにします。レビュー者がチケットを丁寧に読んでくれると思ってはいけません。チケットに書かれている問題は少し複雑で、いくつかのパッチを積み重ねて解決できるものもあるでしょう。レビュー者には、その問題のどこを解こうとしているのかは(コードを読まなければ)わかりません。コミットメッセージはコードを読む前に読んでもらうもの、という前提なので、コードを読まないと理解できないようなことは原則的には書きません。文字以内で改行することが良いことになっています。(how)」解こうとしているのかを述べます。最後に、チケットへのリンクやバグ番号を入れておきます。(what)」やっているかは詳細には書かなくていいです。それは1行目に完結にまとめてください。1行目に書く必要が無いような情報なら、書かなくていいです。コードを読む助けにはなりません。パッチを見ればわかります。「何をやっているか」はパッチを読めばわかりますが、「なぜやっているか」はパッチを見てもわかりません。「なぜ」を書いてください。何事にも例外はつきものです。1行メッセージで済ませることもあります。2017-01-15OpenBLASが速かったちょっと行列演算をしたかったので適当にコードを書き散らしていたのですが、速度が必要な演算であるために既成のライブラリを使うこととしました。今回は行列乗算ができれば良いのでBLASを生で使ってもそんなに問題ありません。BLASの中でも高速な実装であるOpenBLASを使い、適当に書いたコードと速度の比較をしてみます。結論から言うと、OpenBLASの速さを舐めてました。50倍の速度差がでるとは。インストールMacの場合はbrewで。LinuxでもOpenBLASのパッケージはたいていのディストリビューションにはあると思います。1024の大きさの実正方行列の掛け算をします。1024;適当にMatrixクラスを定義します。精度はそこそこで良いので今回はfloatを使います。j)でアクセスできるようにしておきます。ABを計算するものとします。cを用いて次のように表すとします。N);ナイーブに掛け算をした場合ナイーブに実装すると次のようになるでしょう。j)の部分がメモリを飛び飛びにアクセスすることになるので速度はでません。-O3で試すと、おおよそ6〜7秒程度の時間がかかります。jの順でアクセスするとメモリアクセスが飛び飛びにならないのでいくらか速度が稼げます。j)は0で初期化しておく必要があります。}}これでおよそ1.1〜1.2秒ぐらいです。演算回数としては10243なので1G回の演算があるわけですが、2.4GHzのCPUで1.2秒となると、まあちょっと遅いですねという気持ちになります。関数cblas_sgemmを使います。計算結果はCに格納されます。掛け算ABを計算したければ、βを0とすれば良いでしょう。cblas_sgemmの引数はちょっと見ただけではわかりづらいです。行列の要素はメモリ上では行ごとに並んでいるので、CblasRowMajorを指定する必要があります。FORTRANなどではメモリ上は列ごとにならべるのが普通ですがC/C++では行ごとにならべるのが普通です。cblas_sgemmでは転置してから行列を掛け算することもできます。今回は転置などせずに掛け算するので、CblasNoTransを指定します。N);これの計算時間はわずか0.03秒でした。ちなみにEigenでも同じような計算をしてみたのですが、こちらは0.11秒程度でした。AI実機で動作するぷよぷよAIというものをしばらく有志で作っておりました。プロジェクトはgithub.com/puyoaiで公開しています。これに関連するイベントを今までいくつか開いています。人類打倒に向けてというタイトルで発表しました。アップロードしてあります。王様達のヴァイキングの監修についてなぜこんな仕事を?簡単に言うと、深見先生に頼まれたから、です。競技プログラミングのマンガを描こうという話が2005年ぐらいからありました。私が描いたのではありません)。競技プログラミングマンガと深見先生は直接は関係ありません)。深見先生に王様達のヴァイキングの話がきたときに、せっかくだから我々とやりたいということで話が回ってきたものです。今がそうでないとは言いませんが、最初の頃はもっと起業ものっぽい雰囲気を醸し出していたでしょう?深見先生が協力として入ることになった後に、旧知の仲である我々にも回ってきました。そのときはちょっと画像を提供するぐらいの話でしたし、そのつもりでいました。具体的には、YUHAのメンバーと、Gokuriのメンバー、などです。そんなに負担にならないと考えました。徐々に監修は人を減らしていきました。これはそこまで仕事がなくなったというのが大きいのと、あまり多人数いても意見だけが出てまとまらないためです。人が減ったとはいえ、あまり負担は変わっていません。マンガを読んで育ってきたので、一作関われるというのも良い機会だな、と思って楽しんで協力しています。何をやっているのか?技術的詳細を考えることです。基本的に、話はさだやす先生が作ります。それを受けて、事件などを深見先生が作ります。そこには技術的な詳細は書かれていません。そこで、例えば「ハッキングをする」と書かれてある部分の技術的な詳細を考え、仮のセリフをいくつか挟む形にまで落とし、その詳細を平易な日本語でさだやす先生、深見先生、および担当の山内さんに説明します。話も読者に分かりやすい展開になるように僕は心がけています。テクニカルには別の手段を使ったほうが良い技術でも、今後の展開および、マンガとしての要請のために別の技術を敢えて用いることもあります。これは詳しい人からはツッコまれますが、それは覚悟の上です。マンガの上では詳細はかけません。かいても難しすぎるだけだからです。ハッキングの技術的難易度を調整するのは難しいのですが、私が見ている分に関しては、最低でも「理論的にはできる」話にしてあります。ほとんどの場合、それを実際にやったことがある人を聞いたことがあるものを採用しています。バイナリパッチを作った話なんかは、実際にそういう人がいるという話を聞いたので、じゃあいいだろうということで通してあります。過去に似たようなハッキング事例があれば、それを参考に技術的詳細を詰めたりします。大体5割ぐらいの技術的詳細は僕が決めていると思いますが、週に数時間程度の時間でだいたいなんとかなっています。