PD2、NAL研週ゼミ、PostgreSQLリストア時のトラブル

今日はPD2とNAL研週ゼミで、合間に昨日のPostgreSQLリストア時のトラブルをチェックしてました。大凡の目処が立って良かった。

PD2の11回目は先週の続き。最終課題「情報工学科のCMを制作」に向けて各自のアイデアを考えて来てもらったのが先週の課題で、今週はそれを持ち寄り互いに披露し合って討論題材とし、目標像に落とし込むというのが目標でした。が、どこまでやれてるのかは謎か。実際問題として「一度決めたはずの目標像が進むにつれて*思ってたのと違う*」とか良くある話だし。それでも、決められた期間（時間）で収めることを前提に計画立てて行動し、躓いたならそれはどこか、何故そうなったのか、を経験して欲しいです。そのための実習形式課題なので。経験せずに済ませるなら適当にレポート書かせて終わりますが、それを求めている授業じゃないです。デザイン（設計）に関連した失敗を含む様々な経験をして欲しい。

PMで院生も来てたので河野研／長田研でのmercurial/gitlabの使い方を聞いてみたり。河野研は論文やソース等をmercurialで管理してて、論文ならそのリポジトリを先生に伝えてメール指導／直接pushで指導されたり、印刷して持ってくる場合には赤ペン先生したりとその時々でやりやすい形で指導してるらしい。こういう添削を一通りcommitログ化しておくと、添削システム作成用のデータセットにも使えそうではあるのだけど、明確な良し悪し以外のルール化は難しそう。長田研のこの間の勉強会話は、gitlab上でのコメントを使ってみ遊んだという話だったらしい。

週ゼミは久しぶりに全員集合。最近は「まず院生の進捗確認＆討論してから4年次に1回以上質問させる」という風にやってみてるのですが、院生にも予想外の質問が出て説明する練習になって良さげらしい。本当は自分からどしどし質問して欲しいのだけど、そうなる切っ掛け作りになるなら強制しても良いか。

NNでの深層学習のDropout周りのアンサンブル学習効果について検証使用としている玉城くんは、まずはDropout率を変更してみての精度チェック。Dropout率が高くなる＝稼働するユニット数が減ると「瞬間的な学習効果（1度の重み更新度合い）が高くなる」らしく、ユニット数が減った状態でBPしてるなら確かにそうかという話。当面はDropout自体に手を加えてみての検証をしてみる方向に。

トピックモデルLDA結果へ「分かり易いラベル」を付けようとしている慶留間くんは、HDP-LDAで得られるトピック数と、その際のトピックの中身自体に疑問があるとのことで、自身でチェックできる分かり易いデータセットを構築して再建してみることに。

小説読んだ際の感情を推定しようとしている平良くんは、認知評価を含めた（というか認知的評価を確認できる）アンケートを作成してみたので、検証できそうかを確認するため研究室メンバ内でもやってみてくれという報告。第一被験者になった人はありがとうございます（これからもお願いしますｗ）。

PostgreSQLのリストア問題は、

• (1) pg_dump 時に owner 関連を含まないように dump させても alter owner するような SQL を出力しやがること。
• (2) 古いPostgreSQLでのエンコーディング問題の逃げ方を参考に進めると、出力されるエラー行には何も問題が無いこと。（実際にはその前で別のエラーが出てたのだけど、それがなかなか再現しなかったために気付くのに時間がかかった）。
• (3) pg_restore が素のSQLに対応していない（何でだよ）ので tar でやってたのだけど、エラー箇所が「行（とエンコーディングで問題あるんじゃない？というヒント）」しか出さないこと。（該当行を探すのにいちいち展開＋関係しそうなファイル探し＋該当行チェック、という手順を踏む必要がある）

で、ようやく問題特定できたので、修正できるようになりました。どのぐらい修正箇所あるか分からないけど、素直に delete しまくった方が早い気がしなくもない。もともと綺麗なデータセットではないので多少データ件数減っても問題無いし。ま、続きは明日やろう。この辺りの問題は MySQL では一度も遭遇したことがないので、個人的にDB構築するなら二度と PostgreSQL は触りたくないな。と思えるぐらいには面倒くさい。。