listen to my digital heartbeat.

　『マンガでわかる人工知能』
　三宅　陽一郎（監修）
　備前　やすのり（マンガ）
　2018年
　池田書店
　★★★☆☆

　一切の事前知識を前提としない「マンガでわからせる人工知能入門」。小学校の高学年から年配の読者まで広く対象とした一般向けの本。

　全6章構成。（人工）知能の定義、人工知能研究の歴史、機械学習、ディープラーニング、人工知能がもたらす社会の変化、人工知能とともに生きる未来、といった内容。全体の分量は200ページ程度で、マンガ部分が70ページ程度、イラストが70ページ程度、文章だけのページは残りの60ページ程度。マンガで描かれた内容を改めて文章で解説していくスタイルなので、イザ！となればマンガだけ読んでも内容を理解できるようになっている。

　「はじめに」に「人間の知的作業は『人工知能に解かせる問題領域をはっきりと決めて、人工知能に作業を任せる』という仕事に重点が移ることになります。」「まずは本書を『人工知能に何をさせたらいいのかな？』という軽い気持ちで読んでください。」とある。まさにそういう内容の本で、「人工知能に仕事を奪われる！」というような不安に駆られている読者の不安解消を意図しているようだ。

　人工知能の技術的側面については人工知能研究の歴史に沿って説明されており、第1次ブーム、第2次ブーム、（現在の）第3次ブームの流れもつかめるようになっている。人工知能の技術が社会の隅々にまで組み込まれていく将来像については…、正直「良いこと」ばかり書いている、という印象。工学系の人って基本的に「技術の進歩＝善」という発想だし、「問題が起きたらその時に対処すればよい」って感じだからなぁ。工学系の人に「社会」を語らせると大抵こうなる（笑）。

　最後の方を読んでいて考えていたことは、「これからは、人のすることは相談や交渉、広い意味での『政治』になっていくのかな…？」といったこと。僕は「不合理な決め事を取り決めていく」ということが「政治」だと思っているところがあるんだけど、そういうことに人が専念することになるのか。もっともそれも（人工知能による）「代理エージェント」に仲介・サポートして貰うかたちになるんだろうか？

　奥付けに「執筆協力：三津村直貴」とある。実際の文章はこの人が書いたということなのだろうか。監修者が三宅氏であることもあり、コンピューターゲーム中での人工知能の活用のような、ゲームクリエイター寄りの視点から語られている箇所もところどころにあり面白い。

　ところで、「リケ女」のイメージって、やっぱりメガネと（自宅でも）白衣着てることなんですね…（表紙のイラストでは着てませんが）。そもそも人工知能の研究者は白衣着ないんじゃないかと思うけど…？

　本文200ページ程度。



→　Kota's Book Review

　茶色陥落後、命カラガラ緑復帰を果たしたAtCoderだが、「ARC139」のB問題がマグレで解け（笑）、レーティングが141もジャンプアップしていた。

　レーティング推移を図示したグラフを見ると…、まるでツクシのような（笑）。


　しかしこれ、本当は「解けていなかった」のだ。ループを終了すべき条件がわからず、ダメモトで100回、1000回、10000回と増やしていったら、たまたま全てのテストケースでACできてしまっただけに過ぎない。要するに、それでWAとなるテストケースがたまたま出題されていなかっただけなのだ。それはそれで悔しいので、その後1日半悩んで何とか終了条件を見つけ出したが…。

　結局「マグレ」なのだ。2月頭に「レーティング上昇の兆し（？）」が見えたような気がした時も、その直前の「ARC133」のC問題、「ABC237」のE問題がマグレで解けてレーティングが上がっただけで、その後順当に（？）下降していた。要するに、僕の真の実力はレーティング800前後、ということなのだろう。

　と言うワケで、今夜の「ABC250」でまた急下降するのだろうと思います（涙）。

　AOJ(Aizu Online Judge)にもオンラインコードエディター・プログラム実行環境が用意されたようだ。

　古い方のサイトに「Coding Editor for AOJ」というリンクが張られていることに今気付いた。


　「ICE」っていうのかな？　なかなかお洒落な感じだ。

　ただし、利用するにはAOJのアカウントが必要な模様。

　RubyのIntegerクラスに「最大公約数（Greatest Common Divisor）」と「最小公倍数（Least (Lowestとも) Common Multiple）」を求めるメソッドがあった。それ、知らんかっとんてんちんとんしゃん…。

　その名も「gcd」、「lcm」、「gcdlcm」。MathクラスにもPrimeクラスにもこれ系のメソッドはなかったので、テッキリRubyの標準ライブラリには存在しないのだと思い込み、毎回自分で書いていた（競技プログラミングでは、時々「最大公約数」を求めたい時がある）。

　Integerクラスなので、整数オブジェクトそのものにドット記法でメソッド名と引数を記述する。例えば、12と18の最大公約数と最小公倍数を求めたいなら、

p 12.gcdlcm(18)
# => [6, 36]

みたいな感じになる。

　新しいバージョンで追加されたワケではなく、かなり昔のバージョンから存在していたようだ。

　先ほど終わったバカリの「ABC248」、A、B、D問題は解けたが、C問題が解けず、レーティングがまた下がる…、とガッカリしていたが、何と緑に復帰していた！

　803、だけど…（笑）。


　その後、終了時刻を20分ほどオーバーしてE問題も解けた。C問題をスッパリ諦めていたら、時間内に解けていたかも…。この辺り、問題の見極めもなかなか難しい。

　来週はどうなるかな…。

　2月頭に「再上昇の兆し！？」が見えていた（ように思えた）AtCoderのレーティングだが、その後放物線を描くように再び下降してしまっていた。

　何とか土俵際でギリギリ踏ん張っていたが、ついに堪え切れず、先週末の「ARC138」で緑色から茶色に陥落！してしまった…（涙）。


　最も易しいA問題も解けず（その後、何時間もかけて何とか解いたが）、一気に48もレーティングが落ちてしまったのが大きい。翌日の「ABC247」ではA〜D問題まで解けたが、レーティングは僅か5しか上がらず、緑色復帰に失敗…。

　（アマゾンのレビューワーランキングと同様に）このままズルズル下がっていくのかなぁ…。

　昨夜のAtCoder Beginner Contest 244のC問題はちょっと面白くて、通常の、処理すべきデータを標準入力から一気に全部読み込んで結果のデータを標準出力に全て書き出すタイプの問題ではなく、「インタラクティブ」な形式の問題だった。

　ターン制のゲームのように、1つのケース中に何回も入力と出力を繰り返すのだ。その際、こちらの書き出したデータに応じて入力内容も変わるのである。

※「この問題はインタラクティブな問題（あなたの作成したプログラムとジャッジプログラムが入出力を介して対話を行う形式の問題）です。」と問題文に記載されていた。

　このタイプの問題を解くのは僕は初めてだったのだが、注意事項として「出力を行うたびに標準出力をflushしてください。そうしなかった場合、ジャッジ結果がTLEとなる可能性があります。」とも記されていた。「TLE」とは「Time Limit Error」の略で、プログラム処理時間の制限時間内に処理が終わらなかったことを意味する「不正解」の一種。この問題の場合だと制限時間は2秒に設定されている。

　僕はRubyで解いたのだが、普通に

puts x

とした（xは整数型の変数）だけでは、注意されていた通りにTLEになってしまった。調べてみるとRubyでは、グローバル変数$stdoutか組み込み定数STDOUTを用いて

$stdout.flush

あるいは、

STDOUT.flush

とすることによって、バッファ中の未書き出しのデータの書き出しを行うことができるようだ（「puts x」の次の行に「STDOUT.flush」を1行追加したところ、TLEにはならずに無事ACできた）。

また、事前に、

$stdout.sync = true

あるいは、

STDOUT.sync = true

としておけば、毎回のputsの度にflushが呼ばれるようになるらしいこともわかった。

　本番終了後にGo言語で解き直してみたところ、Goでは単に

fmt.Println(x)

とするだけでもTLEにはならなかった。ただ、せっかくなので調べてみると、Flushメソッドをもつbufio.Writerが見つかった。

w := bufio.NewWriter(os.Stdout)
w.WriteString(fmt.Sprintln(x))
w.Flush()

　2行目の部分は、

fmt.Fprintln(w, x)

とするのでも良いようだ。

　Gopher修行のためにAtCoderの先週末の問題（AtCoder Beginner Contest 243）をGo言語で書き直していてまたハマった！　（本番ではRubyで比較的簡単に解けた）C問題がRuntime ErrorでACできないのだ。

　数時間悩んで、（競技プログラミングではよくある）最大20万字のアルファベットからなる文字列を1行読み込もうとしている箇所で読み込めていないことがバグの原因と判明。逆に言うと、入力例の3ケース（だけ）が正常に処理できていたのは、入力サイズが2、3、10字と小さかったからだ。

　単に、

sc := bufio.NewScanner(os.Stdin)
sc.Split(bufio.ScanWords)
sc.Scan()
str := sc.Text()

こんな具合に読み込もうとしていたのだが、どうやらScannerで1度に読み込める（デフォルトの）最大バイト数は意外と小さいようだ（bufio.MaxScanTokenSize = 64 * 1024）。

　幸いScannerにはバッファを指定するメソッドがあるので、sc.Scan()の前に

buf := make([]byte, 200001)
sc.Buffer(buf, len(buf))

とすることで20万字読み込めるようになった。

　ちなみに、

buf := make([]byte, 200000)

ではダメだった。行末の改行文字の分が足りないのだろうと思う。

　Gopher修行のためにGoの公式サイトにあるドキュメント（の有志による日本語訳（笑））を読んでいて、「型変換」の原理を用いて、「文字列（string）」を「文字のスライス（[]rune（= []int32）あるいは[]byte（= []uint））」にしたり、逆に「文字のスライス」を「文字列」に変換できることを知った。

　例えば、こんな風に。

※以下のコードは、HTML上でインデントを表現するために全角スペースを用いているので、このままコピー＆ペーストしてもエラーになります。

package main

import "fmt"

func main() {
　str := "abcdef"
　fmt.Println(str)
　//abcdef

　arr := []rune(str)
　for i, _ := range arr {
　　arr[i] -= 32
　}
　fmt.Println(string(arr))
　//ABCDEF

　fmt.Println(string([]byte{0x30, 0x31, 0x32, 51, 52, 53}))
　//012345
}

　→　Go Playgroundで確認

　目から鱗、って言うか、結構衝撃だったね〜。

　こないだから比較的新しいプログラミング言語のGo言語の勉強を始めてるんですが、Goは「スライス（Slice）」と「インターフェース（Interface）」が難しい。ちょっとした制御構造の書き方の（他言語との）違いなんかよりも、むしろヤッカイなのはこっちだな、という印象。

　そんな中、公式サイトにある「Go Slices: usage and internals」という解説を見つけました。簡単そうな英語だったので頑張って読んでみて、スライスに関してはかなりスッキリしました。そもそもGo言語における「配列（Array）」と「スライス（Slice）」の関係がよくわかっていなかったので、読んで良かったと思います。

　Go言語は、クラス（Class）ではなく構造体（Struct）中心で考えるところだとか、多少ポインタを意識しないとならないところがあるところだとか、やっぱりC直系だな〜、という感じがしますね。発想が微妙に微妙にC言語寄りなんだよな。僕はC言語の経験はそれほどないんですが、「オブジェクト指向」がずっとわからなかった人間なので、Goとは相性良さそうな気がします（笑）。面白いです。