int *q.e.d.=&(q.e.d.+n);

■卒論に対する反省と考察
4ヶ月という期間で、論文らしきものをなんとか書く過程は、なかなかしんどかったです。
自分で納得行く締めくくり方は結局出来なかったのですが、
これから卒論を書く人々、また自分の今後２年の思考の一助となるよう、今思っていることをまとめておこうかと思います。

今回の敗因をまとめるとするならば
- 学術的に取り組むテーマを決めることができなかったこと
- 論文を読まなかったこと
- 持てる力で単純に解決できそうな方法でしか選択しなかったこと
の３点に集約されるのであろうと思っています。


特に、僕はなかなかテーマを決めることができませんでした。

なんとなくソフトウェア開発を簡単にしたい、くらいのモチベーションで研究室を選んだ僕は、
特にやりたい研究や、面白そうな先輩の研究を見つけることもなく
「やりたいこと探し」に多くの時間を割いてしまいました。
また「研究としてやるべきこと」というものを正しく把握できていませんでした。
「べき」論としての研究というのは(特にコンピュータサイエンス分野)
今まで解けなかった/性能が出なかった/誰も解いていなかった問題に対し、
何らかの工夫でもっての解決策と結果を示し、その結果が有用であることを示すべきものなのだと思います。
そこでは例えば入力をおしゃれなWebインタフェースから行えるなんていうのは、瑣末な問題なのですが
僕は見た目上それっぽい何かを作ることを志向してはまってしまった気がしています。

例えば10年前の人が提唱していたある概念を使って、今ここにある問題がそのまま解決出来るということは一般によくあって、
それが愚直にできるのであれば、そもそもそのようなものを研究する価値はないと言えます。
上に書いたような事を頭では理解していながら、卒論という限られた時間でなんとかまとめるために
自分の実装力で解決出来る範囲でことを終わらせようとしてしまったことが、更に問題を根深いものにしました。

先輩方は口をそろえて「卒論は黒歴史」「卒論はしょぼいもの」ということをおっしゃいますが、
それは彼らの立場になったから言えることであって、卒論生が最初からしょぼいものしか作れないと思って取り組むと、
あまり良い結果を産まないような気がしています。
卒論の結果を踏まえて修士・博士ですばらしい研究へと昇華させる先輩もいますし、
卒論だからしょぼくて良いや、と低い山を数ヶ月で登ろうとすると、
それなりに労力がいる割にその後に生きず、コストパフォーマンスが悪い気がします。

もちろん全く新しい問題を全く新しい解き方で解くなんてことは、なかなか難しいように思いますし、
見た目は違うけど、こういう意味ではこれとあれは同じ、ということもありふれています。
そのため、今まで解かれているよく知られているものと、なんとなく新しそうなものの間で、差分をしっかり示し、
その差分が瑣末でないことを示し、きっちり解決するというのがひとつのあり方なのだと思います。
そしてその差分を見つけたり示したりするためには、やっぱり世で言われているように、論文は読まねばいけないなあと思ったのでした。

自分の卒業論文への取り組みを振り返ると、
卒論提出一ヶ月前あたりになって、やっぱりなんとなくまとめようとしているものに納得できず、
その時点から肉付け出来る範囲でなにか役に立つことはないか、と論文に目を通しまくった時期は、
まさに巨人の肩に乗る状態で、有用であったと思います。
一方で、卒論のテーマを決めることが出来ずよくわからないまま論文を読んでいた時期は
目の付け所がわからず読む対象も甚大だった上、読んでもその論文に意味を与えることができないので、
なにかしらのテーマを（天下りでも良いので）決められると強いのだろうなあと感じました。



これまでどうだったかではなく、これからどうするかが大切なのですが、
これからどうしていくかに関しても明確なアイディアはなく、
2年後に同じ轍を踏まないようにするという最低ラインの目標すら、
決して低い壁ではないのだと思って進んでいかないといけない気がしています。

自分の命令に必ず従う奴隷がいたとして、命令を下すのにその奴隷が話す言葉を理解しなければならないのはしょうがない、けどその奴隷に命令を伝えるのになぜか糸電話が必要で、なおかつその糸電話を自分で作らなければならないことに納得できない。

SkypeとApacheは両方共ポート80を使ってしまい、Apacheのほうは融通がきかないのでSkype切ってからApache起動してた人はSkypeの設定でポート80使わないようにすればいいと思うよ。

■wonderful summer

大学進学以来生活を共にしてきたwindowsマシンが最近不調であり、
バイト先から借りてたMacは仕事してなさすぎて返却を求められ、めきめき住環境が悪化しています。
学科PCにはSkypeを入れないという方針にしていて、Skype環境無いと高校来の友人と話す機会も減るもんだなあということに気づいてしまい、ちょっと良くないなあという感じです。


■大学院
第一志望の研究室で、卒論および修士課程を過ごすことが出来ることになりました。
わりと願書出す直前まで第一志望迷っていたし、
一度しかお会いしたことの無い先生や研究室の方ではありますが、
なんとなくこの先生やこの方々のいるところだと楽しくそれなりの成果を残せそうな気がする、という
ほぼ第六感的なところで決めたので、これからどうなるかはわかりません。
まだ卒論のテーマも決まってない配属が決まった段階で
先行研究なども全く知らないので、それなりに大変な後期になるのかな、という予感はありますが、
卒論としてそれなりの体をなしたものくらいは頑張って残したいなあと思います。


■インターン
2ヶ月ちょっと、インターンに行ってました。
4年の夏にインターンに行くというのはさほど一般的なことでないですし、
現状の能力など考慮してもまだ飛び込むべき時期ではないかなあなど不安もありましたが、
思い切って応募してみてよかったなあと思います。

とても楽しかったし、わくわくしたし、いろんな人と会うことができたし、
自分についても考えるきっかけとなりました。

せっかく意識を高めることが出来たので、なんとか高いままいきたいです。

本、主に小説、の評価をどうつけるか、というものは個々人の趣味にもとづくものであって、それが結果的にどの本が好きか、という問いの答えとして帰ってくるを踏まえると、本をひとつの作品と見たときに、作品は最後まで完成されている方が良くて、なおかつまとまっている方が良くって？、というのが自分のいわゆる基本的な基準で、もっと明確に言っていくと、物語の落とし所、ある状態から別の状態まで行くのに不自然でないか、終わりを明示的に書くか、暗黙の了解のように多少の想像を確率的に擁したまま終わるのはいいとしても、投槍に読者に終わりを投げるのはどうだろうか、が大きく一つと、他にもこれは比較的に誰にも当てはまるのかもしれないが、表現、話の書き方、でこれは甲乙つけれる基準は強いてあげるとしたら、読みやすさ、伝わりやすさ、ぐらいで、これでも客観的な方であまりにも主観的なところが大きくしめるので他人の好みになんとも言えないけれど、というのもひとつの大きな要因で、思うことがあるならば、不自然でないかどうかのことで、オチの予測の安易さは、今まで読んできた本の数に大きく依存しているのもあるし、書き方から来る作者の好み、キャラクターの設定、世界観の設定だけで、最後は数パターン程度に限られやすく、逆に言えばその数パターンに収束しない話、特に週刊誌の漫画とかで見切り発車気味に描かれるような、は破綻していることが多くて、そういったものは評価をよくできない。

高校の時、クイズをやったと思ったが、文化祭で問題を作ることになり、いくつか作ったはずで、そのときに靖国神社の階段の数は、という問題を作って、答えはジョークのように九段と、いう筈だったけども、そんな事わかる奴もいなくて、結局九段ということにしてしまったが、あの教室に少なくともいた20を数えるほどの高校生は、今はおとなになり、靖国神社の階段の数は九段であるという虚実を、はたして覚えてしまっているのか、それとも忘れてしまっているのか、おそらくは忘れてしまっているのが、ほとんどだとしても一人ぐらいは覚えてしまっているのかもしれない可能性を、一番賭けるに値するのは、あの時自分の隣にいたTさんだろうか、あの人真面目だからな、俺がいうほど。

だいぶ間があいてしまいました。

研究計画書なるものを大学院入試のために書く必要があるのですが
いよいよこのときがきてしまったな、という感じです。
専門家になるということは、他のいろいろな選択肢をある意味では捨てるということで、
少なくとも２年くらいは取り組む（名目となる）ことを決めるというのは容易ではないです。


先日の記事で述べた、興味のある研究室を１月づつ３カ所まわる、
というのが結構４年前期の自分の生活を支配していて、
まあそれなりに面白い経験を出来たので、まとめてみました。

具体的な演習の内容としては、各人の希望に基づき研究室を３箇所、３週間づつまわり、
その研究室の研究分野に関連する論文を読み、実装などをする、というものです。
３週間で論文を読み、その内容を理解咀嚼し、実装におとすというのはかなり難しく、満足の行く結果は残せなかった気がします。
（というのは言い訳で、友人のなかにはそれなりに面白いものを実装していたりする人もいるのですが）

だらだら書いてみたら結構な分量になったため、記事を三回分に分けておきます。
リンクタイトルはざっくりとした分野と主に読んだ論文名
1期 : UI for TabletPC, Occlusion Aware Viewer
2期 : communitacion on Infiniband, fast and Scalable MPI-Level Broadcast using Infiniband's hardware Multicast Support
3期 : Distance on Graph, Reachability and distance queries via 2-hop labels


ちょくちょく書き進めてはいたのですが、なかなか書きたまらず、気付けば夏休み目前になりました。
この夏は帰省しないかもしれません。かなり楽しそうなイベントが控えているのです。
このことについては、またかける範囲で書き留めておきたいと思っています。

演習３、３番目に訪れたのは計算幾何、計算代数、アルゴリズム、量子計算を専門にしているところでした。
演習３関連記事一覧
この研究室は最初志望するつもりはなかったのですが、
研究室紹介のときに熱弁してる先輩が楽しそうだったので選んでみたのでした。
結果的にその先輩の下でテーマを選ばせてもらい、けっこう面倒をみてもらえたので、三カ所のなかで一番楽しかった気がします。

「Reachability and distance queries via 2-hop labels」をまず読みました。
証明を読むのがだるかった記憶があります。「自明」とか「直感的に」とか振り回すのよくないと思います。

２点間の最短路やら到達可能性やらを調べるのに、多少前計算をしても良いからそれなりの速度で結果が出てほしいという需要があって、そのための手法のひとつらしいです。
ナイーブに全頂点間の距離やらを記憶するのは記憶量が多くなりすぎるので、
論文の提案では、2-hop coverというものを考えて、それを記憶したらいいよ、という感じ。
たとえばa->bのあるパスがcを経由するのであれば、aはa->cのパス情報、bはc->bのパス情報をそれぞれ覚えておけば、
a,bそれぞれが覚えている情報を見ていくことでa->bが復元できます。
元のパス集合に属する任意のパスu->vについて、こうした復元が出来るように全頂点にラベル付けを、なるべく効率よくしたい、
一方でサイズ最小のラベル付けを求めるのはNP-hardなので、うまいこと近似しましょう、という話。
実装の流れとしては、2-hop coverのインスタンスをset coverのインスタンスに変換するような操作をして、
そのset-cover自体はdensest subgraph問題の考え方を使うと解けて、densest subgraphは線形時間近似アルゴリズムで解けるよ！
みたいな感じでした。実装量はそれなりに多かったけど、まあやることははっきりしてて、とりくみやすかったです。

アルゴリズムならc/c++だろ、みたいな感じでc++で実装しました。
今年４月くらいからずっとc++を勉強したいと思いつつあまり時間がとれてなかったのですが、
一応独習C++を半分くらい手を動かしつつ読み進めていて、+1/4くらいは流し読みしていたので
cでヒープやらキューやら再発明するよりは低コストで実装出来たのではないかと思います。STL超便利ですね。

実装自体は２週目の時点であらかた終わっていたのですが、他の課題やらを処理していたせいで、
それ以上の改善というのをあまり図れなかったのが心残りと言えば心残りです。
最終発表のときは、こんな感じで元論文より良いことができました！というスタンスで発表しましたがw
正直マシンスペックの違い(十年前の論文なので）ってだけな気もしなくはないです。
この論文手法自体がO(N^2)の空間計算量を必要としていて、そもそもこうしたアルゴリズムに対する需要というのは巨大なグラフに対してであるのに、空間計算量上のこの制約はあまりいけてないよなあと思いました。

そのあたりの改善を模索して「On-line shortest Exact Distance Query Processing」という論文にも少し目を通してみました。
前半は、2-hop labelを求めるために、無閉路有効グラフなら簡単に考えることが出来そうなので、
まずグラフの強連結成分を抽出、そのなかの適当な点たちを用いてラベル付け、
どの未カバーな最短路にも出現しない頂点はグラフから除いてしまう、というのを繰り返して
閉路をなくしてしまおう、というような感じだったと思います。
この時点で、１週間で実装するのはきつそうだなあと思い後半はちゃんと読んでいませんが、
なんかそんなに効率的でもない方法に見えるのに、かなり少ないラベル数でパスをカバー出来てるような実験結果が論文で示されていたので興味がある方は読んでみると良いかもしれません。

演習３、２番目に訪れた研究室は、OSやら、分散並列やらその当たりを専門にしているところでした。
演習３関連記事一覧
なんとなく分散っぽいことがしたい、という程度のモチベーションで臨んだため、なかなか方向性が決まらず、
最終的にはInfiniband上で動く、ちょっとした通信関数を実装する、みたいなものになりました。

InfinibandというのはHPC分野ではけっこう普及している通信の規格で
(Ethernetとよく比較されるそうですが、いわゆるデータリンク層だけでなく、トランスポート層あたりまで含む通信規格だったと思います）
高バンド幅、低レイテンシ、RDMA通信の実現、ハードウェアレベルでのマルチキャストに対応、などいろいろ楽しげな感じです。

ネットワークの知識すら怪しいレベルからのスタートだったので、Infinibandとはなんぞや、というレベルでけっこう詰まった記憶があります。
Infiniband上で通信を行う低レイヤなライブラリとしてVerbsAPI（ネーミングセンスがいまいちな気がします）というのがあるのですが、これを用いたプログラミングを行いました。純粋なるCでした。

verbsAPIに関しては、使えそうな資料を探すのに苦労しました。
「Introduction to Infiniband for End Users」や「RDMA Aware Networks Programming User Manual」などがわりと参考になりました。
後者くらいしかリファレンス的なものを見つけられなかったので、これを主に参考にしていた気がします。

最終的には、verbsAPIを用いた一対一通信用関数（MPI_Isend, MPI_Irecvみたいなもの）の作成、
verbsAPIを用いたマルチキャスト関数の実装（但しバグあり）という感じでした。
マルチキャストの実装に最して
「fast and Scalable MPI-Level Broadcast using Infiniband's hardware Multicast Support」
という論文を読みました。
Infinibandはハードウェアレベルでマルチキャストをサポートしてるので、
それを用いてMPI_Bcastを高速化したいけど、
Infinibandのマルチキャストは非信頼性通信だったりMPI_Bcastの仕様とはギャップがあるので
その辺をどうしたらいいかという話。
1から全へマルチキャストして、送信者が全員からACK受けたりするのは通信が集中するし、スケーラブルじゃないので
ノードをいくつかのグループにわけ、それぞれのグループにco-rootというリーダ格をもうけ、
co-rootがちゃんと送信できたかの確認およびデータの再送を担う、というアイディアです。

cでかなり低レベルな通信プログラム（それこそsocketなんか目じゃない感じでしたw）
を書いたってのは、まあ良い経験になったのかなあとは思います。

一方で、よくわからないままgoogleとにらめっこして悪戦苦闘、の繰り返しでかなりの時間を過ごしてしまった気がするので、もう少しうまく上の方に頼るなりすればもう少し成果らしきものを残せたのかなあとも思います。
あと、ごりごりcでキューの管理したり例外処理しまくったりするのはやっぱり面倒でした。cは結構好きな言語で、低レベルな分だけそのコードがどういうことをしているかわかりやすい部分もあると思うのですが、高級なことをしようとすると途端にソース量が爆発しますね。

はじめまして、これから私も記事を受け持つことになりました。

takchaso　と申します。

簡単な自己紹介をしますと、現在名古屋市内の某大学に通っており、来年から（働き先が決まれば）社会人になります。
興味はIT、デザイン、音楽など。
このブログの管理団体とは高校時代からの友人で、現在もそれなりの交流があります。

取り扱う内容について。
一般的なニュースから、IT、デザイン、ライフハックもの、趣味の音楽や料理に渡って、それなりのクオリティを意識した記事をポストしていければと考えています。

しばらく読みにくい文章やしょうもない意見、はたまた二番煎じや三番煎じネタが投下されるかもしれませんが、どうか生温かい目で見守って頂ければと。




と言っても、すぐに書ける良質なネタを当方持ちあわせておらず…

ということで、昨日の私のちょっとしたライフハック（笑）




■フェデックスキンコーズで半委託自炊

2010年はiPadや第３世代Kindleのリリース、その他それを追う形でのタブレットPCやリーダーの販売に見られるように、電子書籍元年と巷では騒がれていました。

そこに乗っかるように始まった"自炊"ブーム。

一応説明しておきますと、"自炊"とは手持ちの本をバッサリ裁断し、スキャナで読み込ませて電子化することです。

詳しくははてなさんが説明してくれております。

ただ、興味本位で手持ちの書籍の電子化をしてみようと考えていても、自炊のために調理器具を揃えるのはちょっとコストが掛り過ぎる。

こんなのやら


こんなの


が必要になってくるわけです。



いやあ、話が少し逸れますが当方最近料理に凝ってまして。

気合を入れてレシピ本を買ったはいいですが、どうもレシピ本まるまるキッチンに持ち出して…っていうのがとてもやり辛い。

そこでばっさり裁断してしまって必要なページだけキッチンに持っていくのがスマートという考えに至ったのです。


で、どうにか手軽に裁断できないものかと色々調べた結果のこちらの記事。

キンコーズでばっさりやってくれるという。キンコーズは24時間営業のビジネス特化コンビニといいますか、スーパーコピー屋さんといいますか。


あーこれちょっと裁断しちゃった方が楽だなぁとか、電子化してやりたいなぁという書籍がある方にはかなりオススメ。

一冊あたり100円程度でやってくれます。自分は裁断+穴あけ（50円）を依頼。5分程度でぱぱっとやってもらいました。

こんな感じ。

かなり綺麗に仕上がってます。




ちなみにスキャンの料金はこちら。
グレースケールで一冊あたり30円、カラーで300円くらいで出来そうです。

店舗はまだまだ都心にしかないようですが、近くにある方は是非、自炊してみては。