日時：2005年11月17日(木) 18:30 から
場所：慶應大学理工学部（矢上キャンパス） 14棟201教室（セミナールーム1）
■アクセス情報
●矢上キャンパス内の案内
【14棟-201教室（セミナールーム１）】
キャンパス内地図
http://www.keio.ac.jp/access/yagami.html
で，入り口からスロープを上がって警備室の手前の階段を
上ると地図で(3)と付番された創想館という（一部ガラス張りの）
建物のピロティです．14棟というのは，この創想館の別名です．
ピロティ内左手にある外階段で２階にお上がりください．
入り口を入るとベンチを挟んで14-201〜14-204という教室が
あります．そのうちの14棟201教室が会場です．
セミナールーム１というのもこの部屋の別名です．
（警備室に寄る必要はありません．直接，当該教室まで
お越しください）
●矢上キャンパスまでの案内
【慶應義塾大学理工学部（矢上キャンパス）】
・東急東横線日吉駅より徒歩15分程度．
綱島街道を渋谷方向に進み，２つめの信号（仲の谷交差点）
で右折．細い道に入って直進してください．しばらく行くと，
矢上キャンパス入口の緩い坂道（スロープ）があります．
地図は下記にあります．
http://www.st.keio.ac.jp/access/
・もしくは，JR横須賀線，新川崎駅よりタクシーで7分程度．
◆発表その1
話者：
大駒誠一（無所属）
話題：
プログラム記憶方式コンピュータの最初のプログラム
概要：
最初のプログラム記憶方式のコンピュータは１９４９年９月 に完成した英国ケンブリッジ大学のEDSACと信じられているが、 実はその一年前に英国マンチェスター大学のSSEM （Small-Scale Experimental Machine,小規模実験機、 通称 Baby)が完成していた。SSEMはその名前が示す通り、 ブラウン管がメモリとして使えるかどうかの実験機であり、 記憶容量はわずか３２語で、命令の種類は７個しかなかった。 このSSEMで、１９４８年６月２１日与えられた整数の最大の 約数を求める２７語のプログラムが初めて答をだし、 世界最初のプログラム記憶方式のコンピュータで動いた 最初のプログラムとなった。このプログラムの紹介である。
◆発表その2
話者：
川島英之（慶應義塾大学理工学部情報工学科）
話題：
センサデータベースシステムの開発
概要：
本発表ではセンサデータベースシステムKRAFTについて述べる． KRAFTは様々なセンサデータを管理すると共に以下の3つの機能 を提供する．(1)データの永続性と鮮度，(2)センサデータを 管理する抽象型，(3)連続的にセンサデータを監視する機能． (1)の機能を提供するためにKRAFTはローカルディスクの代わりに リモートメモリを用いる．各ログレコードはリモートログサーバ へTCPを用いて並行的に送られる．リカバリ時にはリモートログ サーバの全ログレコードが時間順に集められ，冪等にデータベース サーバへと送り戻される．(2)の機能を提供するためにKRAFTは 関係データモデルを拡張し，類似シーケンスを検索できる センサ型を提供する．類似性の距離尺度としてはユークリッド 距離とダイナミックタイムワーピング距離を提供する． (3)の機能を提供するために，KRAFTはデータベースサーバ内部で 連続的にクエリを実行できるモニタを提供する．
出席者：22名
飯島 正，篠沢佳久，寺中晶郁，深津康行，森 崇志，森田武史，山口新平，
山口高平（慶應義塾大），滝田 裕，多田好克，寺田 実，丸山一貴（電気通信大），
伊知地 宏（ラムダ数教研），石畑 清（明治大），並木美太郎（東京農工大）
山口文彦（東京理科大），繁富利恵，副田俊介，田中哲朗，筧 一彦（東京大），
上坂明未（フェリス女学院大），酒井香代子
【ある島での鳥の挙動を監視するプロジェクト(?)に関して】 Q：センサに関して, 電源等はどうするのか. 省電力も大切ではないか. A：省電力を考慮したクエリ最適化が熱心に研究されている。 Q：センサはどの程度の能力があり, どういった情報を入手することができるのか. A：光、加速度、温度、磁場など。 【「全ての家庭にロボットを!」】 Q：ロボット内ではそれほど処理をしていないのか. A：単純なアクションについてはロボット内部で処理をするが、 WEBコンテンツ解析などはバックエンドのサーバで処理する。 Q：ロボットはシナリオベースでしか動けないのか A：そうだ。ロボットがコンテキストを管理することで認識精度を高める。 Q：人間との受け答えをさせようとする場合, 対象とするドメインを区切ることで ロボット側をパッシブに動かすことはできないか. A：上手に区切れば可能かもしれないが、問題とドメインに依存すると考える。 Q：示された実験のデータから, 「人間はロボットに触れようとする傾向がある」 といえそうか. A：今までの実験結果からは、「興味がある人間は、ロボットに触れようとする傾 向がある」と言える。 【DBMS】 Q：I/Oを使う場合, KRAFTの実装方法とI/Oのスケジューリングとが衝突してしまう ことはないか. A： それはありうるが、詳細な実験をしないとわからず、 今後の課題にさせて頂きたい。 Q：モデルはどうなっているのか A：センサデータ用のセンサオブジェクト型を新規に考案 Q：SQLに新しい型に相当するものを導入しているのか. A： 導入している。効率的にデータを保持し、データマイニング演算を実行できる 「センサ型」を導入し、SQLを拡張している。 Q：デッドラインミスに対する対策は. A：現在のところ、デッドラインミスに対して適応的なシステムが振舞う設計は実 現していない。応用によってはインプリサイス処理を導入すべきかもしれない。 Q：バッファI/Oが発生してもスレッドのリアルタイム処理は実現可能か？ A：そのデータ取得は今後の課題 Q：リモートメモリにログデータを置くのは、データがいらないからか？ A：違う。ログデータはトランザクション一貫性保証のために必要であるから 重要である。リモートメモリを用いるのは性能改善のため。 Q：リモートメモリは信用できない, というスタンスに立っているのか. A：単一では信用できないが、複数台なら信用してもよかろう、というスタンスに 立っている。 Q：オンメモリDBやクラスターの場合はどうか. A：オンメモリDBは、サイズが固定であるから、センサデータ格納には向かないと 考えられ、川島のターゲットには向かないと考えられる。 クラスターの場合には、巨大DBを構築可能であるし、リモートWALとの親和性 が高いと考えられるが、効率的な実現には不明点がまだ多い。 Q：センサからのデータを収集するという立場から, 別のアプローチを考え ることはできそうにないか. A：「センサデータは補完可能である」という立場からすれば、データをある程度 間引いて格納し、確率により補完してもよいと考えられる。それゆえ「データ がたいして重要ではない」というアプリに対しては、そのような設計方式が適 切であろう。 しかしながら、「どのデータが重要なのかよくわからないから、とにかく全部 蓄えておいて欲しい」という種類のアプリにとっては、全てのデータを収集す る本研究の設計方式がふさわしい。 自分としてはこの方針に興味を覚えている。