Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

イベント / EVENT

平成22年度 第3回 Q&A

第3回 2010年8月5日(木)

積み木のようにソフトウエアを作るには?
プログラミングの科学

胡 振江(国立情報学研究所 アーキテクチャ科学研究系 教授/主幹)

講演当日に頂いたご質問への回答(全18件)

※回答が可能な質問のみ掲載しています。

プログラムを効率化するためのコストと効率化によって得られるメリットのバランスをどう考えるか?最適解は?

問題によりますね。計算機が自動的に効率化をするには限界がありますので、効率のよいプログラムの設計が重要だと思います。

作成したプログラムを効率的にテストするには、どのように行えばよいのでしょうか。

本講演のトピックではありませんが、ソフトウエアのテストは重要な研究課題で、多くの手法が提案されています。

基礎計算パターンの中味、実際設計して作るのは、誰でしょうか。

基礎計算パターンの実現と設計を行うのは言語の設計者やライブラリの開発者になります。

プログラミングの勉強には、どのような言語を勉強すればよいのでしょうか。(BASICやC++などの)

プログラミング言語は多種多様で、それぞれの言語に特徴があります。初めての言語として勉強するなら、私は関数型言語HaskellやMLのような宣言的な言語をお薦めします。

「googleの計算はMapReduceで表現できる」という点について、画像処理や検索など、具体例を挙げて補足説明をしてください。

mapReduceの応用例は沢山あります。次の本をご参照頂ければと思います。
 - Hadoop, Tom White (著), 玉川 竜司 (翻訳), 兼田 聖士 (翻訳) , オライリージャパン, 2010.

HYLOの融合運算器の代表的なボタンの内容について説明してください。

HYLOの融合運算器のボタンは運算ルールと対応しています。例えば、ボタン「Fuse」が融合ルールと、「Tuple」が組化リールと対応しています。

最大部分列和問題について、リストの要素がすべて0以下の値であった場合は今回の解法が使えないと思いますが、入力値が不明である場合はどのように解くのでしょうか。

いい質問ですね。この場合は0を返します。空リストも部分リスト(segement)の一つだからです。

mapは写像だと思います。日本語では。

スケルトンmapはある関数を入力リストのそれぞれの要素に適用する操作で、写像の意味ではありません。日本語で「マップ」といいます。

Yahoo! Pipesを使ったことがありますが、本日のお話と思想がよく似ているように思えます。(計算はしていませんが...)
この印象は正しいのでしょうか?
※Yahoo! PipesはXMLデータの加工ツールです。

合成的な観点から、両方は似ています。

世の中では、積み木のようにプログラムを組むために、"オブジェクト指向"などの方法も使われていますが、これと今日のお話は何か関係があるのでしょうか?

今日の話は"関数指向"の方法で、"オブジェクト指向"の方法とは違います。ただし、今日紹介したリストとその上の4つのスケルトンを一つのclassと見ることができますね。

「積み木のように...」という意味は、オブジェクト指向とは異なる何かオブジェクト指向を超えたものがあるのでしょうか?

我々の基本ブロックは「関数」で、「オブジェクト」ではありません。それぞれに特徴と長所があります。

積み木のように作るというのは、単なる結合、つなぎあわせと異なるのですか?(単なる結合では、効率がよいとは思えませんが)

プログラマーは単なる結合、つなぎあわせでプログラムを作ればいいのですが、このようなプログラムを効率的に実行するためには、融合運算、組化運算等を行いう必要があります。

正しい(計算可能)は示せるでしょうが、効率が最適ある証明はできるのでしょうか。

スケルトンプログラムの効率の見積りは容易にできますが、「効率が最適である」ことを保証するのは難しいです。

運算理論による変換をしてもBestなプログラムができるとは限らない。どこまで、Bestに近いものができているのか、検証できるような一般的な方法はあるのか?

これは運算ルールの能力によりますが、多くの能力の高い運算ルールを開発すれば、よりBestに近いものに変換することができると思います。

今日の話はリストという列を計算するのが基本の話しでした。
世の中的には、列がないものを計算する必要がある、そういう時4つの積み木だと難しかったりするか?

今日はリストを対象にして、4つのスケルトンを紹介しましたが、実際にはこの理論は、ツリーに自然に拡張できます。ツリー上のmapは、リスト上のmapとちょっと違います。リスト上のmapはすべての要素に対して同じ操作をし、リストをそのまま返します。ツリー上のmapでは、ツリーの中の全ての要素に関して、リーフに関して、あるいは中間ノードに関して同じ操作をし、全体はそのままシェイプを変えず返す、と実に自然に拡張することができます。

運算によるプログラミングで解法が難しい適用分野は何でしょうか。また、それに対して現在どのような研究が行われていますか?

運算によるプログラミング手法は様々な分野の問題に適用され、そのための運算ルールが開発されています。Bird&de Moorの「Algebra of Programming」の本には多くの問題が取り上げられています。

スライド26の「リスト上の計算パターン」で4つが取り上げられていますが、再帰的(recursion)なものはないのでしょうか。

そうです。それらの計算パターンはリスト上の再帰的な関数として形式的に定義できます。

正しいプログラムか否かを検証するプログラムは作れるでしょうか?

定理証明器を使って色々とプログラムを検証することができますが、全自動で任意のプログラムを検証するのは難しいです。

shimin 2010-qa_3 page2567

注目コンテンツ / SPECIAL