原研究室

更新が滞っていますが、どうぞ 活動掲示板 を覗いてください。

まだテスト段階のドラフト原稿です。

当研究室では、ツールや手法の組み合わせの可能性を探索し、様々な周辺科学の新しい知見をもとに、未来の「ひと」の社会に有用だと考えられる新しいソフトウェア作りに意欲的に挑戦しています。これまでの学問的成果にとらわれず、絶えず流動的に進歩している多くのツールや周辺科学と連携し、いち早く未来感覚のある成果を創造するために日々努力しています。

とくに近年のコンピュータの進歩は目覚ましく、これまである意味で妥協の産物であった計算プログラムも、今では「ひと」の知性を十分に計算資源の中に投入できるようになりました。「人工知能」が1980年代には「人工知能・挫折の時代」に突入し、多くの研究者が人工的なニューラルネットワークによって知識や感情を作ることができるだろうと信じた「人工知能・夢の時代」は終わりを告げました。しかしながら、近年のコンピュータの進歩がやや異なるアプローチで「擬似的な人工知能」または経験的アルゴリズムをもった知能の開発によって息を吹き替えしているのです。それは、「ひと」を「脳科学」や「認知心理学」の観点から見つめ、または感情を触発する要因を追求し、それらの知見をソフトウェアの成果に投じていくことによって生まれてくる新たな地平線です。

キーワード
  1. ひと
  2. 非ノイマン型コンピュータ
  3. アンビエント・コンピューティング
  4. マルチセンシング
  5. 知能型計算
  6. データマイニング
  7. 生物模倣
  8. 関数型プログラミング
  9. 認知心理学
  10. 拡張現実
  11. 世界・ひとをプログラムする
  12. 人間性の計算可能性
  13. UNIX
  14. LISP

ニュース

2010-05-10 文藝春秋６月号(5/10発売)
小林君がp.165のコラムに登場しています。
2010-04-05 新年度始動
いよいよ平成22年度がスタートしました。
2010-03-12 引越し
3/12、67号館内216号室から104号室に移動します。引越し後は原の部屋は106号室、学生の研究室は104と105号室となります。
結局前倒しさせられ、3/10、第一歩として216号室から撤退、104号室に机と椅子を搬入しました。金曜日は104号室の整理と105/106 号室の交換をします。
2010-02-23 卒論発表終了
これから打ち上げ(第一彈)
2009-02-23 小林君、情報処理学会優秀学生賞
小林君が情報処理学会優秀学生賞を受賞
2010-01-07 新年ゼミ
恒例の新年ゼミ＠PLATZ
2009-12-18 忘年会@原宅
忘年会@原宅
その後徹夜で麻雀したっけ。
2009-12-12 樋口君、ラジオ出演
FM-N1ラジオに樋口君が出演します (12/12日(土) 午後1時〜)。
再放送 12/14(月) 午後10時〜)
2009-12-10 (株)モルフォ訪問
小林君、樋口君とともに(株)モルフォ（画像処理技術の研究開発および製品開発ならびにライセンシング）を訪問しました。
(株)モルフォ
東京大学ベンチャーキャピタル下の雄で、数多くの携帯電話・デジカメ製品に内蔵された組み込みソフトウェアを開発しています。夜中まで社長も含めて飲み屋で話を聞かせていただきありがとうございました。
大学院生のインターンシップなどで積極的に関わっていきたいと思っています。

活動掲示板

[memo]
2010/09/05 08:29:07| nk: tex slide
h6. itemize環境を使ったlisting

<source lang="latex">
\begin{itemize} \framesep=0pt %要素同士の間隔を0ptにする
\item[\ding{52}] foo %\itemのあとで[]を利用して要素の前に打つ点を変えられる
\item[] bar %点がいらない場合には[]と中身を空に
\end{itemize}
</source>

h6. list環境を使ったlisting

<source lang="plain">
\begin{list}{}{\leftmargin=1zw \itemsep=-4pt} %listは第3引数に設定を書ける。
  \item[\ding{51}] foo
  \item[] bar \\[5mm] %barとbooの間を5mm伸ばしたい際
  \item boo
\end{list}
</source>

h6. 文章を書く際のareaの作り方(\Sparbox)

<source lang="plain">
\rput[tl](.5,4){\FS{10}\Sparbox{3cm}{%
   ... contents }}
</source>
rput,FS,Sparboxの順で書く(FSの第2引数の{}がいらなくなる。)

h6. 不特定数の要素を載せる環境の作成(arraystretchの利用)

parbox内でarraystretch,arraycolsepを利用したtabular環境を作ると良い。

<source lang="plain">
\rput[tl](5.2,7){\psframebox{\FS{10}\parbox{5.5cm}{\MC% 明朝体にしている。
      \def\arraystretch{2.8}%　%%要素間の行間の拡大率の設定
      \arraycolsep=0pt% %%列間の幅の設定(横)
      \begin{tabular}{cp{.7cm}c}
      a & b & c \\
      x & y & z
\end{tabular}}}}
</source>
tabularのプリアンブルにはc,l,r(center,left,right)の他に
p(p{LEN}でLENの長さのparboxを作成)がある。長い説明文が含まれる場合などに用いると良い。

h6. 文字同士の横に詰める(\SB)

\FSが12以上のところで\SBを使っていた。
SBの実体はxmag,ymag方向にscaleboxするマクロ。

\Sparbox環境の中では\SBは使っていない。(SparboxのSはSBのS)

h6. memo環境の項目

<source lang="plain">
((peace o 44) (cross x 56) (pen p 48) (arrow a 220) (heartmark H 170) (exclamation E 162))
</source>
%{color:gray} ここは推測%
o,xでpeaceとcrossは正解／不正解のような対比の際に使う
p,aはpen,arrowの先頭文字、鉛筆と矢印から連想するものに使う
H,Eはハートと感嘆符。大文字なことから特別な用途に使う。(感情表現っぽいものを連想させる)

h6. 画像の挿入

<source lang="plain">
\def\leftp{\raisebox{-3mm}{\includegraphics[bb=0 0 200 200,clip,width=1cm]{#1}}}%
</source>
includegraphicsにbbを指定することでcliping(画像を切り出すこと)できる
画像位置を上下に上げ下げしたい場合には\raiseboxを使う。(正で上、負で下)

h6. 雑多な知識

* tex文章中での空白には\hfillを利用
* "…"は$ldots$
* \MCは日本語：明朝体、英語：ローマン体にする。
* pssetを利用する際には{}で包んで環境を作ってあげると、後で値を修正しなくてよい。(?)

[semi]
2010/09/05 05:10:53| RHa:
To: nk
やはり色の選択が悪いなぁ。
ちょっとnkのスライド直に修正させてもらいました。

To: all

あと、フォントの大きさですが、このスライドなら、デフォルトを14ptに設定していますが、10pt未満は絶対に
使わないでください。基本的には14ptと12pt、10ptですらもうギリギリの選択肢です。

みんなそうですが、文字幅、文字間隔、スライド上ではやや間伸びした感じになってしまいます。だから、
@\SB@ とか @\Sparbox@ を使ってください。徹底的に直しますよ。

それと、もう遅いかもしれないけど、rputばかりで配置すれば、気違いのように整形が大変です。スライドだろ
うが、これはLaTeXのシステムですよ。 @\parbox@ とか @tabular@ 環境 だとか、 @list@ 環境があるんですか
ら、そういうものを使うんですよ。

僕の見本からぜひ学んでください。
``"view source" method of programming enables the community to learn from each other''でしょ＞nk

まだみんなのスライドは、最終形ではありませんよ。細かい制御を入れても修正ばかりになりますよ。

[semi]
2010/09/05 03:42:02| RHa: (Re: 2010/09/05 01:13:28| nk)
本日最後寝る前に。

僕等には、日常仕様と学会仕様と論文仕様があります。日常仕様では、人格も能力も全てを認めているのですよ。
ただし、学会仕様は学会の流儀に準じてもらわないと困るのです。「具体性」、「資料の明確さ」などはそのご
く基本です。そして、僕等が論文を書くことができたときには、論文仕様になっているはずです。あらゆる反証、
反例の可能性を排除して、全ての主観を拭い捨て、根拠となる国内外の既出の知見を全て引用し、緻密な実験結
果を収集して客観性を貫かなければいけません。

論文仕様とまでは言わずとも、だからこそ学会は覚悟をしてもらわなければいけないのです。念のために言って
おきますが、僕は金沢工大基準とか北陸基準とかがあったとしてもそんなものは無視します。全国基準もしくは
国際基準しかもちません。さて、僕等が今持っていないもう一つの仕様があります。職業仕様です。経済活動に
対する報酬で生きていく仕様です。学会仕様0.2＋商業的能力0.8くらいが求められるのではないかと僕は思いま
す。

早く学会が終わればいいのにね。そうしたら日常仕様にひとまず戻りますよ。戻りたいですよ、僕だって。

[nonsense]
2010/09/05 03:14:39| RHa: (Re: 2010/09/05 01:25:49| ym)
この限りではありませんが、偉大な数学者・哲学者であるラッセルは、生涯最後は小学校の教育に尽力しました。
当時の貧しい教育環境を憂えて、世界各地でフリースクールが創立されていった時代です。

フリースクールの最も代表的なものはニールの創立したサマーヒル学校です。世界でもっとも自由な学校という
教育スローガンを掲げて作られたのです。授業出席を一切強制しない、生徒がみな教師と対等の一票の決定権を
もつ。すごい思想です。

それはともかくとして、ラッセルのような偉大な科学者がなぜ小学校の教育を。そりゃ、恵まれた学者生活を過
ごした人は貧しい教育を憂うのです。貧しい教育は貧しい国を作りますからね。

もちろん、そういうラッセルは小学生に科学を教えるのがすごくうまかったと言われています。そう、よい科学
者はどんな科学だって、小学生にすら教えることができるのです。

僕も学生時代、よく言われました。僕は発表がとても下手でしたから。目の前に小学生がいると考えて、説明し
てみろ！とよく怒鳴られたものです。

[semi]
2010/09/05 02:28:05| RHa:
To: nk
多分effectとaction、僕はこうであるべきだと思うんです。
raw image と active view との間に、effect filter のレイヤーが必要ではないかと。
ちょっと絵を描いてみました。

この絵にするんだったら、タイトルも変えないとね。修正。

ここまでスライド作り込んだら、ほんとにそのソフトウェアがあるように思えてきませんか？
具体化が進んだ証拠なんですよ。

ないものをあるように見せるために必死。必死にあるように見せかけると、なかったものがあるようになる、錯
覚。そして頭にこびりついて、作らないでいられなくなる。そうだといいですよね。必死になる値打ちあります
よね。そう思いませんか？

[semi]
2010/09/05 01:37:48| 高橋: (Re: 2010/09/05 01:29:39| nk)
オーケー。adhocな変数は理解した。後は、もしその言葉の説明するなら、今のやりとりの簡略版を言葉にする
なり、絵にすればいいんじゃないかと思う。なるほど、pslineの件はそこにかかってくるのか……

やっぱり説明って大変だな。今回はされる側だった訳だけれど。こうして互いに互いの意見を交わさたからいい
けれど、それが出来ない状況で具体的に説明するって、本当はどれだけ大変なことなんだろう。

[semi]
2010/09/05 01:29:39| nk: (Re: 2010/09/05 01:25:17| 高橋)
そうですそうです。
bq. %{color:green}adhocな変数% というのは、最も狭義には関数実行時のパラメータです。

[nonsense]
2010/09/05 01:25:49| ym: (2010/09/04 23:00:17| nk)
ちょっと的外れな話になってしまいそうなので、nonsenseで。

説明をするときに一番重要なのは、説明する対象がどのような人物か理解すること。
理解度であったり、持っている知識であったり、立場であったり。

例えば極端ですけれど、ある事がらを小学生に説明する時には
どうしたら説明したらよいだろうかと考えてみる。

まず、言葉を選ばなければならない。
小学生に分かりやすいような言葉で。
抽象的なことは理解できない。
だから必然的に具体的な例をださなければならない。
長い説明は飽きさせてしまう。
だから、簡潔に説明しなければならない。

教育者や科学者に求められる能力はそういったことかもしれない。

[semi]
2010/09/05 01:25:17| 高橋: (Re: 2010/09/05 01:07:20| nk)
ああ、やっとイメージが出来た。つまり、pslineにわたす座標の引数が、ここで言うadhocな変数なわけだ。

[semi]
2010/09/05 01:13:28| nk: (Re: 2010/09/05 00:42:28| RHa)
了解しました。RADのスライドも含めてslide.texにmergeします。

p{color:gray}. 今回の返答はとてもうれしかったです。
少しだけ認められたような気がしました。(*褒められる*と*認められる*
は大きく異なる。褒められるは単なるpositiveな反応が帰ってきただけのように
感じるけれど、認められるというのは*入りたい組織のような何かの*一員になれた
ようなうれしさがある。)

[semi]
2010/09/05 01:07:20| nk: (Re: 2010/09/05 00:59:52| 高橋)
なかなか人に伝えるは大変。

adhocな変数という言葉をもう一度(今度は短く)説明しようとすると、「ある特定の環境
でのみ機能すれば十分な処理に対して、その特定の環境でのみ正しく動作するよう調整
する変数」ということです。

nslineはnodeの移動に対して不変に意味が定義できます。一方pslineはnodeの移動に対して
可変になってしまいます。したがって、ある特定の環境(nodeA,nodeBの位置が定まっていて、
そこから動くことのない状態)の中で機能するpslineの記述というのが「adhocな変数の調整
が完了したpslineを利用した記述」というような意味です。

[semi]
2010/09/05 00:59:52| 高橋: (Re: 2010/09/05 00:04:48| nk)
偉そうなことを言っていきます。……怒んないでね。

結論から言うと、要するに『画像の編集ではなく、画像を編集する道具の微調整』がadhocな変数のチューニン
グの意味なのかな、という理解。(所詮、俺の理解力なので間違ってたらごめん)

まず、adhocの『意味』は分かった。言葉のイメージはつかめた。ただ、それが今回の発表とどう繋がるかまで
は最初はわからない。

次、pslineとnclineの例。2つの違いは分かりやすい説明。

その後の画像処理、家の話なんかはよくよく噛み砕いていかないと何が言いたいかが見えてこない。説明を理解
する上でヒントになったのは下から2段落目の『例えば、ここで"家のような"〜adhocな変数です』の部分。ただ
、これを一見しただけだとやっぱり分からない。少し考える時間を要して、やっと解釈した結論が上記のもの。

理解があっていないとまるで見当違いな話なんだけれど、下から2段落目を解釈するのに俺が色々付け加えた結果
どういう文章になるかと言うと、

たとえば、ここで"家のようなもの"を認識させるために、単に「ある大きさの四角形」を認識するメカニズムを
利用するとしたら、その状況に合わせて「ある大きさ」とは「どの程度の大きさの四角形であるのか」という設
定をする必要がメカニズムの摘要に必要になる。この画像編集のメカニズムの持つパラメータが画像処理におけ
るadhocな変数である。

こんな感じ。俺もいつもそうだけど、冗長なのが嫌。でもそれは言うまでもないことでもあるかもしれないし、
ほんとは分かってないから言えないだけかもしれない。でも、こうして冗長な説明をしないと何があれば具体的
な説明になるのかが、俺には分からない。それは、俺が説明対象の本質をほんとの意味では理解していないから
だと思う。

具体的なのは俺も苦手。だから、どうすればいいかを考えてみるけれど、とにかく冗長でない表現を最初から使
わないのが大事なんじゃないかと思う。書いてみて、それが冗長なら削る。RHa風に言うなら、無駄をたくさん
する。ってことになるんだろうか。

p{color:gray}. あれ?ものわかりの悪い相手に想定され……たわけではないよ、な……?多分……

[semi]
2010/09/05 00:42:28| RHa:
To: nk
今、nkのスライドを確認。
「実装:エディタと viewer の通信」
「実装:通信の例 (カーソル位置の色を取得)」
の連続的な感じ。これなら、とてもよく分かるじゃないですか。
nkは英語で書くときも動詞形なのですね。

その調子。

コメント

* REPLの内容の具体例のグレーの枠は色がさえないね。うるさくなく映える色を探してください。
* Bound hook *call* , -found- matched hook
* click!!の字が小さい。これはこのスライドでとても大きい意味をもっているはずです。

[semi]
2010/09/05 00:24:27| RHa:
To: nk
スライド一枚追加。PVとリビジョンシステムの関連付け。

p{color:gray}. 使っちゃった。setopacityalpha。ちょっとアクションとアクションチックなスライドの遷移が
あるので、一部スライドを移動しました。

[nonsense]
2010/09/05 00:13:16| RHa: (Re: 2010/09/04 23:00:17| nk)
一つ言えることは、nkの書くプログラムに対するみんなの反応を見る。
よい反応を見せる(例えば使ってみたよという反応)こともあれば、そうでないこともある。前者の場合にはnkが
使い方を説明しているからそうなる。そうでない場合には、使いすらしない、その結果、チャットの中にレスポ
ンスが返ってこない。他の人もそうかもしれないけれど、僕は何とかレスポンスしようとして、一応動かそうと
はしてみるけれど、...

さて、簡単です。常に仕様書を書くのです。

例えば、用意したオプションを並べると、
その時点で、コーディング時に気づかなかったけど文章にして気づく必要なオプションがあることがわかる。
他人も、それならば、こんなオプションも追加してよ。とリクエストをする。

些細なものであっても、人に使ってもらえるものを目標にコーディングをする。そして人が求めているのはnkの
書いたコードではなくて、その説明書であることを認識する。そんなのつまらない、そうなんです。でも、悲し
いけどそれしか他人には必要ないんです。

p{color:gray}. 他人に使ってもらおうとコーディングしているわけじゃない、と言うかもしれませんが、...、なら、...

[semi]
2010/09/05 00:12:57| 高橋: (Re: 2010/09/05 00:04:48| nk)
ちょい待ってて。その説明を、個人的に整理してみる。

[semi]
2010/09/05 00:04:48| nk: (Re: 2010/09/04 22:59:09| 高橋)
%{color:green}adhocな変数% の意味について説明してみる。

adhoc をまず「その場しのぎのもの、場当たり的なもの」という意味で用いました。
「その場しのぎ」のということはある特定の場面には効果的ではあるものの、
その特定の場面から少しでも異なる場面では上手くいかないということです。
この表現を利用した理由を考えてみるに、プログラムのバグに対する返信で「adhocな修正」
という言葉が使われていたことからです。

 %{color:green}adhocな変数% というのは、最も狭義には関数実行時のパラメータです。

pstricksのpslineとnclineを考えてみてください。
nodeAからnodeBに線を引くことを考えます。

nclineはnodeとnodeを連結して線を描く関数(マクロ)です。
したがって、「nodeAとnodeBを結ぶ線を引いてください」という命令に置き換えられます。
この時、nodeAあるいはnodeBの位置を移動することがあってもnclineは意図通り動作します。

一方、pslineについて考えてみましょう。
pslineは始点と終点の座標を指定して線を描く関数です。
したがって、「座標(x0,y0)から座標(x1,y1)まで線を引いてください」という命令に置き換えられます。
この時、直接nodeA,Bと意味が結びついていないので、nodeAの位置を移動した場合には、
もちろん、見当違いなところに線を引いてしまいます。nodeAとnodeBを正しく線で結ぶには、
pslineに渡す引数を修正しなくてはなりません。

このように、nclineは``node''という概念を利用することでノード間の接続を表せました。

一方で、画像処理は実際のところ生のバイト列を触っているに過ぎないため、概念ベースで命令を表す
ことができません。したがって、基本的には常にpslineと同様に実行時に数値を指定して利用することに
なります。ここで「行ないたい目的に対してのみ上手く動作するその場しのぎの処理」に対応する処理を
行なおうと、関数の引数を調整することを" %{color:green}adhocな変数のチューニング% "と表しました。多くのパラメータチューニング
もまた、 %{color:green}adhocな変数のチューニング% であることが多いのですが、単なるパラメータチューニングとの違いは、
特定の場面にのみ上手く動作する、その場しのぎのための処理の作成という意味合いを加味したかったのです。

また、概念ベースで命令を表すことできないというのは言い過ぎで、それをを可能にしようとする試みが
画像認識ということになります。

もし、仮に"家"という概念を機械が把握できるのだとしたら"家"同士を線で結ぶなども簡単に出来ます。
ところが、"家"という概念を正確に記述する術が見出せていないため"家のようなもの"を探すことになります。
"家のようなもの"を探す際には、状況によってその処理を簡素なものにすることができそうです。
例えば斜めから取ったアングルの絵が存在し無かったり、全て玄関を正面から写した写真だったとしたら、
それを解くための処理はとても簡単になりますね。

特に定点観察のような利用する範囲が限られたようなものであれば、全ての"家"に対応する完璧な認識メカニズム
を作成するのではなく、もっと単純な認識メカニズムで十分に機能しそうです。

ここで、画像処理のプロセスを想いだしてみてください。例えば、写真の中の"家"を真っ黒に塗りつぶす
という処理を考えて見ましょう。"家"という概念を用いることが出来れば、「"家"を黒で塗る」で充分ですが、
概念を用いて記述することができないわけですから、"家のようなもの"を認識する方法が必要になってきます。

例えば、ここで"家のようなもの"を単に「ある大きさの四角形」を認識するメカニズムを利用したとしたら、
「どの程度の大きさの四角形であるのか」設定する必要があります。これが画像処理に置ける %{color:green}adhocな変数% です。

さらに広義には、(というよりは個人的には)関数と値の違いがない世界に住んでいることを望むので、
"家のようなものを認識するメカニズム"それ自体も、画像処理においては変数であるように見えて仕方がありません。
その視点に立てば、「どの認識メカニズムを用いるか？最適なアルゴリズムを選択する」という行為自体も
パラメータチューニングに他なりません。このように、ある特定の利用環境においてのみ正しく動作する、その場限り
の場当たり的なアルゴリズムの決定自体も" %{color:green}adhocな変数の調整% "と呼んでいました。

[nonsense]
2010/09/04 23:00:17| nk:　具体的な事柄が苦手
以前も同様のことをnonsenseに書いていた。

p{color:gray}. こういうことを発見するとある投稿の近辺の発言を見たくなったりする

bq. 2010/04/23 18:05:30| nk:
    今日分かった自分に足りないものは特殊化(specialize)かもしれない。
  : 数学などの例を取れば不定積分ができたことで満足してしまっていたのかもしれない。
    だから、解のようなものが収束しきらない。(考えや行動が曖昧なまま)
  : まだCという不定定数があるというのに。

問題点を認識はしているのだけれど克服できていない。
考えが抽象的な状態(悪い意味)で満足してしまいその先を考えようとしていない。

例えば「ある点の移動」は通常ベクトルで表せて、正確な移動を表すには始点の座標も必要。
一方自分は、単に移動の方向を見出しただけで満足してしまう。
実際のところは、移動の始点とベクトル長さも知る必要があるにも関わらずその先を考えようとしない。

p{color:gray}. 自分の思考は、ある点の移動について考えるのではなく、考えていた対象に似た関係のものを探すことに向いて
しまう。 DFS(深さ優先探索)に対するBFS(幅優先探索)と言えば聞こえが良いが、実際のところは、途中で考える
ことを放棄してしまっているだけ。実際のところ、何かと何かに関連を見出したとしても、その関連を具体化し
なくては実際的な力は何も得られない。

じゃあ、始点とベクトルの向きとベクトルの大きさが分かったら、その「点の移動」を理解したかと言えばそんなことはない。
例えばどのように移動したかということについては何にも理解していない。
本当は、まだまだ深く考えることがあるはずなのに途中で考えることを放棄してしまう。

問題の認識と解決方法を見つけ出すことと解決は異なる。

[semi]
2010/09/04 22:59:09| 高橋: (Re: 2010/09/04 22:01:23| 高橋)
あまり有用でないかもしれないけれど。

そもそもこの話題は、講義の課題をするときに「こんなのあったら便利だね」なんて言ってたもの。その時点で
は、きっと具体的に「どういう使い方をしたい」、「どういう機能があれば実現できるか」というものがnkの中
にはあったかもしれない。

物事を具体的に、他人にわかりやすくというのは、どういうことなのかまだ良く分からない。ただ、説明して相
手が説明対象をイメージできなければ、それは具体性に欠けた説明と言って良いとは思っている。

「分かるよね?」や「分かりなさい」のスタンスでは得られない理解。「分かりますか?」が重要な領域。そんな
風に考えている。説明は相手の理解を確認する質問でもある。と言えばいいのか。

たとえば、ある電気店で客に店員がクーラーの説明をしたとする。

「このクーラーはxxというメーカーのxxxxという部品を使っていて、エネルギー消費がわずかです」
「このクーラーはエネルギー変換効率が良く、消費エネルギーは従来の60%です」

どちらも、クーラーの消費電力の低さを説明しているけれど、言葉の分かりやすさ、具体的な数値があって、こ
の例で言えば明らかに下が分かりやすい。部品のメーカーや名称は確かに具体的なんだけれど、前提知識がない
であろう客にとっては意味不明で何もイメージできない。細かいことが具体的であるとは限らない。

で。ここまでは先の話の続き。ここから、nkの話題。

実際には説明するのかも知れないし、それしかないのかもしれないし、揚げ足とりかもしれないけれど、言葉が
直感的には分からないものが多い。

たとえば、p.6の対話的環境なんて言葉。これくらいなら、学会の聴衆は理解してくれるかもしれない。ただ、
そういうイメージがすぐにつかみにくい言葉をどうするかという問題に関して思うところがあるので記載。

対話的環境って言えば、『何か操作したら、その結果が何かしらの形ですぐに分かるんだな』と俺は連想する。
でも、何と何が対話しているのかがあると、一目でわかりやすくなる気がする。

ついでに。

でも、この言葉を知らない人は?『対話』という言葉から『会話』を連想するかもしれない。じゃあ、『会話的
な環境』って何?ってことになる。それは『何か言えば答えが返ってくるように、何かすれば何か反応がある』
という説明につながる。ここまで言えば、そこそこ具体的かと思う。

ずっと悩んでいる『adhocな変数』という言葉。どうすることにしたかはわからないけれど、それを具体的に説
明しようとしてみよう。誰かものわかりの悪い相手を想定して、その人に説明する文章を書いてみよう。そこ
にはその名が表す体が出てくるはず。そこからわかりやすくまとめることが出来れば、使うのに説明が必要な不
便な言葉に悩まなくて済むんじゃないかと思う。

[semi]
2010/09/04 22:08:01| RHa:
具体的、という例で僕が引き合いに出したいものがあります。

（１） レオナルド・ダ・ビンチが15世紀に描いた現代でいうところのヘリコプターはじめ空飛ぶ機械類。
"Davinci studio":http://www.bbc.co.uk/science/leonardo/studio/
こういう絵を見ると感動しますよね。15世紀にこれだけの荒唐無稽の可能性を具体的に絵におこしたのですから。

（２） 19世紀、チャールズ・バベジが考案した計算機。スチーム、すなわち蒸気機関で動く計算機です。当時の
技術ではバベジの描いた「階差機械」を作り出すことはできませんでした。下は1826年の論文です。これが世界
で考案された初めてのコンピュータでしょう。有名ですよね。1830年代にはこれが「解析機械」へと発展してい
きました。
"on a model of expressing by signs the action of machinery":http://dlxs2.library.cornell.edu/k/kmoddl/toc_babbage1.html
"第２部 コンピューター開発史":http://www.wizforest.com/OldGood/engine/
虚しい具体化です。誰も作れないのですから。

そうでしょうか。バベジ生誕200年(1991年)を記念して、ロンドンの科学博物館がバベジ自身の設計図通りに階差
機関を作ることに成功したのです。もちろん記念事業としてですが、その総製作費は約2億円。発表から165年か
かったわけです。でもそれがとことん具体的だったので、後世の技術で、寸分違わずその物を作り出すことがで
きたのです。

具体・具象とは、それだけの力をもっているのです。

[semi]
2010/09/04 22:01:23| 高橋: (Re: 2010/09/04 21:28:44| RHa)
まだまだ理解が足りないかもしれませんが、その3点は肝に銘じておきます。

nkのスライドについては、何か意見があり次第かきこみます。

[semi]
2010/09/04 21:28:44| RHa:
%{color:red}高橋君と町田君へ、%

nkの発表内容は、nk自身の試行錯誤のプロセスがまだ熟していない、でもそれだけ難しいものであるということ
は分かるでしょう。

processingを引き合いにしたことはCommunityとか伝搬ではなく、すぐ下のPost:にもあるように、nkの作るもの
の特徴を際立たせたという点において、ラッキーでした。本人が自覚しているのかが心配ですが。

僕がnkに望むことは、以下の点です。

* 徹底的に *具体化する* 。具体化しなければ他人と協同できない。たとえ実装してもあやふやなものになって
  しまう。
* 徹底的に *抽象を排除する* 。抽象的なものは、具体的なものを分類したときに現れる抽象なら、分類学的な
  新たな視点を提供します。しかし、具体的なものがない中で論じている抽象は、単に「あいまい」、「ねれて
  いない」、「固まっていない」だけのもので、役に立ちません。
* 徹底的に *他人からの視点* を取り入れる。自分の論じていることは他人にどう理解されているのか、または
  されていないのか、いつでも考える。他人に理解されない考え、は天才的で素晴らしいもの、であるかもしれ
  ないけれど、裏を返せば、他人にとっては何の有益な考えも提供しないものでもあるわけです。それは他人に
  理解されようとする努力の怠りが原因かもしれません。科学者にはこれが一番きついのです。新しい発見はいつ
  でも、その発見に関しての専門家が既に以前から存在したはずがありませんよね。とすれば、新しい発見はい
  つでも発見者はその事象についての初心者に説明しているのです。徹底的に、曖昧な表現は一切せず、自分で
  導かないものは全て他人の導きに基づいて根拠とし、それを引用するわけです。自分の発見の主張はその上で、
  他人から確実に理解され、現在存在するあらゆる知見の中に一つも反証のないものを、自らが証明、説明して
  いかなければなりません。 *他人* の理解なくして「考え」は生きることすらおぼつかないのです。そもそも
  *他人* の理解なくして論文だって学会で出版もされませんから、そういう考えは結局世にも出てきませんが...

厳しいようだけど、世の中は、抽象を論じる前に具象を論じてほしい。他人に理解されなければ何にもならない。
ということを肝に銘じてほしいと思います。

いいですか。これをあえてstとymに投げます。みんなにもよく考えて欲しいことなのです。特に第三の点に関し
ては、いつかどこかで妥協してませんか？さて、二人には、
(Post: 2010/09/04 20:59:45| RHa)や(Post: 2010/09/04 12:55:02| nk)を読んでの意見を述べてください。そし
て、nkにアドバイスをしてください。みんながnkにとっての一番身近な *他人* なのです。もはや、僕は共同ス
ライド製作者としてnkと純粋に他人ではありません。助けてください。助けてあげてください。

というわけで、これをstとymに投げたのです。よろしく。

[semi]
2010/09/04 20:59:45| RHa: (Re: 2010/09/04 12:55:02| nk)
%{color:red}[重要]%
この発表は、画像処理の自分哲学を論じるものではありません。
現在のベースとなっている技術に何を加えたいのか。そしてその結果どういうものを作るのか。

<source lang="plain">
Algorithm Development System := Processing + NK system
NKsystem := IDE + ITS + PV + VC
Processing.member?(IDE) => false
Processing.member?(ITS) => false
Processing.member?(PV) => false   # これをじっくり考えてみてください。
Processing.member?(CV) => false
</source>

* 対話的環境がprocessingにありますか？だからREPLとITSの連携で、インタープリター環境でアクションのなす
  変化をつぶさに観察しながら作っていけるわけですよね。対話的、は大げさかもしれませんが、インタープリ
  タ処理系(REPL)には少なからず存在するコンセプトで、コンパイル言語には基本的にはありません。
* PVによって僕等はオブジェクトとオブジェクト語で対話ができるのではないでしょうか？そういう対話的なイ
  ンターフェースは積極的にprocessingにありますか？
* 比較検討のための、結果の蓄積。もちろんバックエンド用語で言えばリビジョン管理です。だけどそれが試行
  錯誤の支援になるわけです。これがprocessingにありますか？
* ITSを中心としたデバッギング環境。adhocな変数、特殊変数、内部変数、いろんな言い方が出てきて錯綜して
  いますが、それはどれにしたってデバッガーが扱うことのできる範疇です。でもそれがprocessingにありますか？

ちなみに、メモを見て僕の感想
>観察に当たるのがPV
... グラフィクスビューワーならなんでも観察を支援しているわけです。そんなの当たり前ですよ。
>行動にあたるのがeffect/action
... 行動は観察行動、デバッギング行動、プログラムの実行、何だって行動なんですよ。そこを明確にしなけれ
ばいけないのに、「行動」なんていう大きな言葉で何か狭い世界のことを言い当てていない。effect/actionなら、
それだって、それなりに全てのグラフィクスビューワーがもっているものでしょう。OpenGLの座標変換はeffect、
シェーディングもeffect、何らかの破壊的な処理はアクションなのですから。
>順化のプロセス...
メモ過ぎて何をメモっているのかすら分かりません。
>試行錯誤の繰り返しにあたるのがVC
そうですよね。processingにはないですよね。

processingは素晴らしい。その「メディアアート学習のソフトウェア」、「メディアアート制作のソフトウェア」
としての地位は簡単には揺るがないものでしょう。それだけの素晴らしいコンセプトを世に提供した。だからそ
のアイディアは「踏襲したい」、そして「アルゴリズム開発のソフトウェア」へ発展させたい。なら、
processingには「何が足りなくて、アルゴリズム開発に物足りないのか、を突き止めた。これだ、四つのモジュー
ルだ。だから、そのコンセプトを踏まえて作った。

これが僕の想定するストーリーです。僕には感動的です。

いいですか。processingをこれだけ引き合いに出して、ストーリーとして完結しますよ。とくにPVが観察だなん
て言わなければ。PVはオブジェクトとの対話をより一層可能なものにするモジュールなのですよ。

もう一つ。そういうストーリーが「聴衆が期待している」ストーリーなのですよ。

[semi]
2010/09/04 12:55:02| nk: 現状での各モジュールの認識
見当違いのことを考えている可能性があるので現在の各モジュールについての認識をメモしておく。

順化のプロセス[予想、行動、観察、(そして試行錯誤の繰り返し)]
行動にあたるのがeffect/action
観察にあたるのがPV
試行錯誤の繰り返しにあたるのがVC(ミソは前後の比較に止まらず、revisionとの比較に変わったところ)

p{color:gray}. 予想は頭の中(や紙)かな？

[semi]
2010/09/04 12:50:09| RHa:
そうすれば、こういうスライドも追加したくなる。
「RADへの挑戦」

まぁ、遊び心ですが...

[semi]
2010/09/04 12:45:43| nk: (Re: 2010/09/04 12:11:26| RHa)
「アルゴリズム開発支援とは」というスライドに力点を置いて全体を作成するということですね。
p{color:gray}. ITSとPVの仕様についてのスライドを作っています。

スライドの順番はsampleから取り込む際に順序を変えて並べていきます。
(一応slide.tex上の順番は昨日説明を受けた順序に並んでいて、 @inc/<number><filename>.inc@ という形で置いてあります)

[semi]
2010/09/04 12:11:26| RHa:
見えた！
このスライドがキーだ。
「アルゴリズム開発支援とは」
これが4つのモジュールじゃないか。

ちなみにsampleのスライドは順番はいい加減ですからね。

[memo]
2010/09/04 11:46:10| nk: pstricks pst-grad
fillstyleオプションにgradientを渡すには @\usepackage{pst-grad}@