LostMemories

やっぱりこの研究室は時間があればプログラムを書かないといけないのかな？と今さらのように気づく今日この頃。きっと起きてる時間の半分はプログラム組んでると思う。

クラブから帰ってきて、研究室のPCのアップデートをしながらプログラム。やっつけでプログラムを書くと、確かに単純に書けると言えば書けるんですが、その代償としてすごく見にくくなる！最低限の拡張性を持たせつつ記述するのは、普段のスタイルではないのですごく違和感があります。でも、即結果が求められるとなれば仕方なさそう。

そんなわけで、やっつけにやっつけが重なって、ものすごく遅いプログラムを作ってしまいました。一応３時間程度で計算が終わりますが、これも頑張ったら絶対半分くらいの時間になるのにな。某書籍に「最適化はするな！」という格言が書かれていますが、可読性をよくするのは最適化ではありませんよね・・・。だぶんですが。
とりあえず、１つだけ走らせて帰宅。

家に帰ってきてからは、研究のプログラムを速くするために真面目に書いてたりします。一回でいいからこまごましたやつより、大きめのプログラムを組んでみたいと思う今日この頃。

僕の研究の関係で、毎日虫取りばかりやってます。虫と言っても本当に生きてるわけではなくて、プログラムの中で意図しない動作を引き起こす原因・・・、つまりバグのことです。デバッグを和訳すると虫取りってことで。

コンピュータ関係の言葉は、比較的生き物の名前が多く出てきます。一番よく耳にするのが「ウイルス」とか「ワーム」とか。別にコンピュータに取り憑いて風邪にしたりするわけではなく、挙動をおかしくしたり、情報を流出させたりする場合が大半です。他にも、ハードの方では「ウォッチドッグ」（=番犬）とか。ホスト名（=コンピュータの名前）にも動物とか、楽器とかの名前が使われやすいです。

さて、今日はクラブが終わってから研究室に行ってデバッグしてました。CDTWを同一のデータ列同士で計算させても０にならない問題を検討してました。１時間粘ってバグを発見！２行書き換えて終了です。今回のバグは、正確に言えばバグとは言えないものだったかもしれません。というのも、プログラムの内容はContinuousじゃないDTWだったので。しかも当初組んでた自分自身も、それを勘違いしてCDTWだと思って書いてたので。まさに理解不足。論文はしっかり読むべきだと痛感しました。

そんなわけで、10月に企業の方に提出したデータはかなり大間違いだった可能性があります。そりゃ値がおおぶれしますわな。

今日は大学でミーティングがありました。半分予想していた結果とはいえ、そろそろ真面目に成果を出さないとやばくなってきました。自作にこだわる必要はないですが、あきらかにツールとして提供されているものを活用できないのは、作業量に差が出てきます。

データマイニングでこれだけExcelが必要になるとは思ってませんでした。以前話したAwkしかり。僕に今必要なのは、Javaを使いこなす力ではなくてもっとTryAndErrorに向くようなスクリプト言語を使えるようになること。残念ながら、僕自身はbashもよく分かってないし、Awkも使えないし、Perlも？？？ってな感じ。PHPは書けるけど、用途が違うからなぁ・・・。

今から勉強するには少し勇気がいりますが、かといって今のまま突き進んでも時間が足りなさそう。時間がない分は頭で稼ぐしかなさそうなんですが、いい方法が思い浮かびません。さて、どうしたらいいものやら。

今日は工学部の他の先生方が研究室に来られるということで、自分の研究の発表を紹介する機会がありました。普段プレゼンをすることがないだけに、こういうときはかなり緊張します。

１つの部屋で、研究室のメンバーが先生方にそれぞれ説明していきます。持ち時間は５分。１回目はやや丁寧に説明しすぎて、ものすごいキリが悪いところで終了。２回目以降は、早口で言い過ぎたせいがあまり理解してもらえなかった模様。この辺のバランスが難しい。１回目に集中しすぎたせいか、２回目以降は気合いが入らず、やや手厳しいツッコミももらいました。人に理解してもらうのはかくも難しいものなんですね。

それでも少しうれしかったのは、１回目に説明した先生に「君はM（修士課程）?D(博士課程)?」って聞かれたこと。短時間だけど理解してもらえたのは、それなりに収穫です。きっと外から見てみると、慌て具合が丸わかりだったはずなんですが、寛大に見てもらえたということなんでしょうか。ただ、その返事で「B4です」って答えたときの表情の曇り具合にはへこみましたが。

一応ひとりで説明するんですが、困った時に先生に助けてもらえるのはありがたいです。「故障っていうのはその瞬間に起こるものだから（予測は無理なんじゃない？）」っていう質問に対して「それを予測するんです。」ってごり押しをしてしまった自分が恥ずかしい。後から考えれば、そんな受け答えは議論の発展にもつながらないし、ありえない回答なんですが。集中力が切れると何をするか分かりません。

兎にも角にも、休憩ほぼなしで同じ説明を５回するのはしんどいです。落ち着いて説明できるようになりたいです。

とりあえず、夜研究室に来ると食料がなくて困るのと、毎回自販機に買いに行くのが面倒くさいという単純な理由で、研究室にカップラーメンの買いだめ場を作りました。

とりあえず安く仕入れてきて適当な値段で売れば、みんな普段より安く手に入るしいいんではないか？という偽善的な目的のもと買出しに。探せば生協より安く売ってる店が意外とあるものです。そんなわけでジャパンとかコープとかの安売りで買いだめ。当分は自腹なんですが、原価に対する売価がコンビニ並なんで、1日1個としても1ヶ月強で元が取れるという感じです。うまく回転するといいなぁ。

ま、ついでに簿記の勉強もしようというたくらみでもあるんですが。習うよりも慣れろ。理論よりも実践です。

関係ない話ですが、上の研究室でアタックがかけられてサーバが陥落したらしいです。パスワードを突破されないように気をつける必要がありますね・・・。

今日の昼に、企業の方とのミーティングがありました。いろいろな集計をした結果をここで発表するってことなのですが、実質僕がやったのは半分くらい。残りは助手の先生がいろいろとやってくださいました。ありがとうございます。

そんなわけで発表です。僕は勝負弱いので、あんな感じで自分が試されるシーンは本当に緊張します。他人に結果を要求されると、いつも以上に緊張するので、ミスも増えたり、間違いも増えたり。困ったものです。ただ逆もしかりで、自分自身で意味を見出せるならそれなりに頑張れると（今までの経験で）思うので、できるだけ今やっていることにどんな意味があるのかをはっきりさせたいところです。

なんだかいろいろしゃべったんですが、自分のやったところは説明できるのに、それ以外が勘違いが多くてへこみます。一応、それなりに事前にどんな感じで進めてってことはイメージしてたんですが、もう少し疑問な点を詰めておけばよかったと反省する点も多かったです。そのかわり、向こうの方の説明がかなり分かりやすかったのと、先生方の質問のおかげでデータの詳細が分かったのは大きかったです。

ここで、よい研究者というのを考えてみると、さまざまな現象に対していかにして問題を見つけて定義するか、という力が優れている人のように思われます。問題自体はすでに存在しているものや、まだ水面下にあるような隠れた問題などさまざまですが、それをどのような切り口で捉えるか。捉え方次第では、難しい問題でも案外単純な問題に帰結できたり、解決に対する糸口がはっきりしたりします。このような力はどうやってつけるかは知りませんが、例外的な状態を考えることで疑問点を発見することができると聞いたことがあります。

たとえば、「太陽電池は光とケイ素さえあればクリーンなエネルギーを作ることができる」という現象があったとしましょう。これに対して問題点があるなら「光がないときはエネルギーを作れない無用の長物なのか？」とか「ケイ素は硬いけど、曲げて使うことはできないのか？」とか「そもそも、エネルギーを作るというより省エネのための研究のほうが効率がいいんじゃないの？」とか。これに対するソリューションとして、「光がないときはバッテリーにエネルギーをためておけばいい」とか「有機太陽電池を使えばいい」ってことになるわけです。

今回の問題でも、1つの切り口からでなくて、いろいろな見方をするといろいろなソリューションが見えるのではないかと。現象を説明されて、はいそうですか、で終わってしまっては解決方法も何もあったものではありません。時間をかけていろいろと試してみて、最適だと思える方法を発見したときに「自分もまだまだだな」と思えるような一種の充実感を味わえるほどになりたいです。まずはいろいろと試せるほどの知識を持つところからです。

今日は研究用に使うデータの基礎的な統計を取ってました。ある時系列データの頻度分布を集計するんですが、そこで思ってもみない値が。

（エアコンみたいなものを想定してください。）その実温度と設定温度があるんですが、その温度差が181℃！なんだそりゃ！見た瞬間びっくりです。で、よく元のデータを調べてみると、データの小数点が落ちてただけでした・・・。17℃→170℃。えらい違いです。まさか、小数点が落ちてるなんて思ってもみなかったんで、発見したときはちょっと気が抜けました。

他のデータも眺めてみたところ、おかしかったのはそこだけ。なんでそこだけ間違ってるのか不思議です。

続きを読む

昨日、いろんなデータをひたすら紙に印刷して眺めてみたんですが、（自分にとっては）予想外なデータが！てか、こんなことが初めから言えるなら、もう少し気づこうよって思えてしまうような結果。これもデータを眺めてなかった自分の責任でもあるんですが、わりと端的な結果に愕然。

しかし、自分の研究はどんなふうにまとまるのかがまだ分かりません。とりあえずは、このデータから何が言えるのかをまとめれば向こうの会社の方には説明がつきます。ですが、卒論としてまとめる際にどの点を強調して、どの点が新しいのかを言えないなら、研究をしたと言えないんじゃないでしょうか。

確かに、勉強にはなるんですけどね。

今日も、大学に行ってプログラムを速くしてました。なぜ速くしないといけないかというと、１通りの結果を出すのに１回１日かかってしまうから。できれば数時間程度で終わってくれれば、大学にいる最中に走らせながらいろいろ試せるのに。

ということで、今日は欠損値を示すクラスをとっぱらって、ひたすらdouble型で表現して計算するようにしてみました。あと、連続DPの計算途中のデータを捨ててたので、捨てないようにして次の計算の時も再利用してみました。

そしたらかなりすごいことに。1時間かかってた処理が5分程度で終了！約10倍の速さに！以前は50個のテンプレートを比較するのに4秒程度かかってたのが、今では0.4秒。違いすぎ。しかも、テンプレートの処理する順番と、履歴を利用する計算方法のおかげで尻上がりにスピードが上がっていくのが見てて面白かったです。やっぱりインスタンスを生成する処理は重たかったんですね。

ここまで来たら最適化する意味はなくて、ひたすら生成されたデータの整理です。グラフにするのにもいろいろと面倒なことをしないといけないので、そのあたりを地道にやっていけば良いかと思います。今後の方針として、他のデータとの照合と、Unnormal Detectionってやつを手がけます。あと１週間くらいで、何か結果が出るんでしょうか。

今日は、最近思いついた最適化の方法を試してみようと思って、ガリガリプログラムを書いてました。結論を先に言ってしまえば、見事に失敗・・・。

Javaではインスタンスを作成するのは、やや重たい処理に含まれます。インスタンスを作成するためにメモリから領域を切り出してきて、フィールドやメソッドがどんなんかを書き出して・・・、などとC言語ではわりと面倒なことを「new ClassName()」と書くだけでできてしまいます。オブジェクト指向万歳！

裏で、こういう作業をしてるので、できればインスタンスを作成しないようにするために、再利用できるものはしてみようと考えました。HashMapを使って、今まで生成した分をためておいて、使えるやつは使うって感じです。比較的単純な実装だったんで、もしかするとうまくいくかな〜と思ったんですが・・・。

結果的には２倍ほど遅くなりました＾＾；原因を考えてみると、実は再利用できるインスタンスと新たに作らないといけないインスタンスの比が相当悪かったみたいです。ほとんどのインスタンスは１度使うだけって感じで、貯めてるだけ効率が悪くなったってことでした。

今回の教訓は、最適化するなら相手をよく知ってから。扱うデータの内容がだいたい分かっていれば、それに適したデータ構造やアルゴリズムも必然的に決定できます。今回は、思いつきだけでやってしまったのがダメだったってことですね。