会議の質疑応答です．
整理していなくてすみません．


タイトル：分子コンピューティングのエネルギー
発表者：西川さん
議論：
Q:「スライドの図の意味は？」
A:「熱力学の基本的な議論を表す図．分子を性質などによって分離しようとするとするのにエネルギーが必要である，ということを示している．」
Q:「Aって何？」
A:「アボガドロ定数．」
竹内: 萩谷さんは情報に着目し，物理現象に注目してない？
巡回セールスマン問題などで有利ということか？

西川: このモデルがある程度いいということを示せることが
Q:竹内「情報のみに注目している．エネルギーの消費が多い，という結論を導けるのか？」
A:「(萩谷は)追加でエネルギーが必要，ではないということを主張したい．(西川は)実際には無理だろうと思っている」
竹内: 萩谷さんのモデルが単純すぎると言うことか？

西川: 実験やの印象としてはこのモデルで理想のモデルというのは難しいのではないか？
萩谷さんのモデルは簡単すぎる？
ANS：実験やさんにもっていくと不平が・・・萩谷さんはよくいっていると思っているのでは

C:竹内「萩谷もそろそろやばいんじゃないかなぁ」
C:禿江「実際の実験のエネルギーの話をしようとしているとは思えない．」
A:「(萩谷は)省エネであると主張している．」
A:「(萩谷も)実験とは相当違うことに気付いている．」
中島: 萩谷さんが何をしたいのかの推測の行きにしかならないか？
実際問題として遙かに大きなエネルギーを使わないといけないので，
彼が実験のエネルギーを推し量ろうとしてるわけではなく理論的な話だけなのでは？

西川: ある面では有利であるという話をしているので〜〜

西川: 実感とだいぶ違うと言うことは萩谷さんも認識している．
萩谷さんの主張は萩谷さん単独の文書の方に書いてある．
＊＊：萩谷さんが何したいかの推測・計算に必要な最小のエネルギーを求めるのに使えるので。実際は
もっとエネルギーが必要

ANS:そうかもしれない。DNAの計算はエネルギー的には効率的だといっているのに、
モデル化してそうなっていないのはどうなんでしょう？
15分の議論で、萩谷さんにモデルがあっていないことは伝わったようです。

竹内: やっている人のエネルギーと比例している？

上田: これはエネルギーがいると言うことか？
〜ゲートという可能性もあるのかな？とおもった．
西川: 本職では分子デバイスでほんととはどのくらいなのか？という検証をしている．
ナノレベルでやっているとデバイスとして成立するかどうか？人生をかけてやっているひとたちがいる．

議長：これはエネルギーがいるっていう話？
ゲートの計算やさんはこれについて考えている。
ゲートで必ず発生する熱をさらに計算に使用できないか？

ANS:普段、阪大の応用物理科にいっている。現実的にどうなのか検証されている

竹内さん：計算されている人はいるのか？
名のレベルで厳密に人生をかけて計算している人もいる

C:竹内「やっている人のエネルギーに比例しているじゃん」
C:「出る熱と使う熱を上手にバランスさせるための方法を考えているのでは？」
C:和田「この類い全く興味がない．ヘンリーベーカーのGC の熱力学という話もあるらしい．」
和田: ヘンリーベイカーがガーベージコレクションの熱力学というのを送ってきた．
和田さん：こういう話には興味がないけど
ガーベージコレクションの熱力学についての論文を送ってきて、そういう研究をしている人もいるようね
C:竹内「雑な近似である，ということだけは確かだ．」

タイトル：制約によって生じる調和−謎の生命体ナミーバの組織化−
発表者：NTT 佐藤
s/プログラミングシンポジウム/プログラミングコンテスト/
Q:和田「何故クネクネするのか？」
A:「生き物っぽいでしょ．」
 ナミーバの実物に関するコメントでした
和田さん：何でゆれるの？
Ans：生き物らしくしたいので

L:「どうにかして1/fを出してやろう」に対して

651はの根拠は？
Q:いちまる「乱数を使っているのに，最初に与える数にノウハウがあるのは何故か？」
 乱数による変動はある物の増えやすいという数字は存在する
A:「それなりに面白そうな結果が出る．」
「ライフゲームは環境が存在して，底の中でどのような答えを出すのかと言うことだが，なみーばはナミーバ自体が環境」
A:「全部死んだ」
いちまる「別のやり方で1/fを実現する方法として，階層化ではなく，結婚などという方法もあるのではないか？」
「ナミーバに合わせた環境を考えていくうちに行き詰まって，階層化になった」
「ナミーバは元々木構造だったのに，それに階層化を加えたのでフラクタル的になった」
C:寺田「2階層である必要はないですよね？」
A:「ないです」
てらだ「なにも２階層でなくてももいいのでは？」
「かまわない」
階層構造とミクロ・マクロというのは少し違いますよね。
ANS：ライフゲームでは、ライフゲームの環境があっってその環境を考える
ナミーバはナミーバがどのように階層化されるのかを環境として考えた

竹内「長さは前のよりも長いのでは？」
「長い」
C:竹内「死が突然だ，老衰死みたいなやつが良い」
竹内「突然死が多いかも？」
「リーダーが死ぬとバッタリ」
「分岐ファクター」
中島「〜数でしたっけ？」
竹内「細胞数ではまだやってない」
竹内「細胞数ではまだやってない？」
「まだやってない」
Q:中島「階層化ではなく，ルールの変更でも実現できるのでは？」
「階層化して．少し多いとこからのボーナスで1/fになるのは理解できるが，階層化しなくても1/fに近づくならば，階層化することで生物化するという話はすべて崩れるのでは？」
 A:「方法がいくつかある，という話です」
中島「1/fを実現したいと言うことではなくて，生物のようにしたいということはでは？」
なかしま「最初のルールを複雑化しないでも，パラメータを変えることでも1/fが実現すれば，複雑化しなくても済むのでは？」
なかしま「ひとつできました！ということではよくないのでは」
C:中島「目的は 1/f ではなく，生物っぽくすることでは？パラメータの違いだけでも 1/f が示せるかも．階層化が生物に近づくことにはならない」
たけうち「3n+1を使う限りではしょうがないのでは？」
C:竹内「3n+1 を換えちゃうと話が全然変わっちゃうよね」
C:竹内「5n+1 等々では全然おもしろくないんです」
なかしま「3.x n +1で1/fが実現されるなら，面白くもない」
階層化することで1/fが得られたのは分かりましたが、
別の方法でもし1/fが得られたら、階層化の考え方は全部崩れてしまいますよね
目的として、生物にしたいのだが、複雑化として階層化を導入したのだが、

Ans：まさしく、1個できましたというところ。おっしゃる通りですが。

3ん+1は1/fではないですよね
3n+1はそうではない

もし、3.1+1のようにパラメータを変えるだけで実現でたら？

＊＊5n+1など試したことがあるけど、おもしろい結果は得られなかった

伊地知「単に単純にやってでいた物が，意味がないということに名ならないと思う」
C:伊地知「違う構造が出現することで，既におもしろい」
A:「階層が有効である，と思ったら，やっぱりそうであった，と言いたいところ．」
「ナミーバを生き物らしくする方法は他にもあるといわれれはそうだ」
伊地知：別に構造が違って、生物らしくなったのは、何か生物らしくなる要因があって、
それには意味があるように思います

Ans：気持ちとしては、中島さん伊地知さんの半々
いちまる「ナミーバはそもそも階層構造を持っているのでは？ それに委譲するというシステムを加えるのは自然じゃないと思う」
いちまる「3n+1とボーナスの間が，いまいちきれいにつながらないと思う」
Q:いちまる「値を上位構造に委譲する，というのは自然じゃないと思う．」
「本人としてはそこそこ自然に拡張できたかな？と思っているのだが，難しい」
市丸：ナミーバはそもそも階層を持つもの。それに対してさらに階層化するのは自然に思えない
Ans:自然に思ったのだが
市丸：自然に思えないのは、階層化で値をただ渡すだけで、3n+1やボーナスのルールから離れている
Ans:難しいですね。悩んでつくった本人としては、自然にできたとおもうのですが
市丸：もともと生物らしいというのはあまりよく分からない言葉だから

上位層がナミーバを制圧していて、上位層が値を取り出している・・・ようなものか
上位層と下位層の分け方が自然かどうかはわからないが、そのままルールを適用できるか分からない

竹内「上位そうが，リーダーの収穫をむさぼり食うというモデル」
C:竹内「上位層が下位層から搾取する，というモデルということだろう．」
たなかじろう「Fとgはドッチが支配的？」
「上位の制約をきつくするとよくない」
「ドッチか片方だけで1/fを実現するということはないのか？」
 C:竹内「全てトリビアルである」
田中：上位と下位の制約についてはどちらが強いか？
どちらかだけで1/fを得られないか？
Ans：もともと、両方指数関数でやっていたが、最終的に上位を線形にした
竹内さん：上位をなしに、下位をきつくすることで同じような結果が得られるかもしれない

タイトル：大学１年生へのプログラミング教育の試み
発表者：伊知地 宏(ラムダ数学教育研究所)

Q:和田「単位が取り易い，ということはないの？ > プログラミングの授業」
「単位として楽ということはないのでは？」
A:「ある程度成績の配分は決められているので，不公平にはなりにくい」
A:「つまり簡単，難しいというのは少ないが，作業量を考えると楽ではないかな？」
C:「私は数学科のでコンピューターの講義は受けていない」
Q:伊地知「プログラミング教育は受けた方が多い？」
和田「僕も受けていない」
A:和田「私は受けていない」
学部までにコンピューターの教育を受けてない人（3-4割程度）￥
受けてない人の平均年齢は高い？
] How can I use apel? It's installed but ... I don't know.
(require poe)
(require emu)
電車が通る
ちがたたかも？
あぅ
ato,
あと1:03
] Oh, it's not for mule! just for emacs20!
Q:いちまる「クラスはどのように説明したのか？」
A:「(円のオブジェクトの説明では)円の絵を書いて，問いを投げると答えを返すもの，という説明をした」
C:いちまる「プログラミング言語ではなく，プログラミングを教える，ということか」
C:いちまる「S式っていうのがいけないのでは？」
A:「記号処理，っていう時点で駄目なのかも」
C:和田「記号処理の方が簡単なのに」
C:疋田「文系の学生が良いのは，目的意識のある学生しかいないからでは？」
「自分で考えなさいと言うと難しくなるようだ」
osym.jp] logged in @ 2002-09-18(Wed) 16:44:15 JST)
osym.jp] connection closed @ 2002-09-18(Wed) 16:44:15 JST)
A:伊地知「アルゴリズムとかの話や数学の話．」
Q:いちまる「学生が理解が少ないかったと思われる分野は？」
「数学的な課題の時に質問が多かった」
「高校で数学をやらなくなっているのかも？」
「アルゴリズムが非常に弱いと思う」
「グラフィックみたいにインターラクションがあるといいのだが，アルゴリズムが内部に入っているような場合に弱い」
Q「視覚的と〜のどっちが効果があるのか？」
A:「視覚的な課題にしたおかでで，学生のレベルが上がったと言えると思う．」
;/*〜の部分取りこぼし*/
はぅ，/**/でコメントになっちゃうのね？＞italk
Q:「他のプログラミング言語に関して応用できる実力か？」
A:「自分で調べることができるようになるなど，十分応用がきく実力が(学生に)身に付いたと思う．」
Q「担当者の負担は？」
Q:「リソース管理の面から，担当者の負担は？」
A「ゲームだけは大変，3件/h程度」
A:「課題5のあたりはきつかった」
「見込は30%十見ていたが，50%も北ので大変」
Q:「プログラムのコピー対策は？」
Q「プログラムのcopy率は？」
「ほぼ同じプログラムが十数個あった．」
「コピーしたので減点というのはあったが20/50程度がコピー」
A:「課題 5に関しては半分弱しかなかった，十分少ないと思う．」

仕様を聞いても分からないということ？
言語処理についてできない

クラスについてはどうやっておしえたのか？
黒板に絵を書いたりして、イメージを植え付けた

つまり、プログラムを教えたのであって、プログラミング言語を教えるのではない？
そのとおり

得点というのは1段階目の絶対得点？
そう。

最後の課題によって難しいが選ばれたのか？
いや、難しいのはグラフィックスだったよう
自分で考えなさいという問題の方が難しいらしい

レポートとしての1回としてアンケートを取ると、出席しないで単位をとろうとする学生の意見が含まれないのでは？
出席しないでも

何がわからなかったか？
教え方にもよるが、アルゴリズム(ソート)など難しいらしい。
グラフィカルに動きが見えれば組めるが、内部に含まれるアルゴリズムは分からない

泉：グラフィックスによって学生が興味を持てるからうまくいったのか？やりかたがよかったのか？
両方のファクターがある
視覚的に与えると興味をもってくれる

この教育のスキルを別の言語(VB)などにしても効果があるのか？
JavaのいいところはドキュメントやAPIなどが整備されていること
例などは授業中に示しているが、マニュアルを読めるようになってきている

リソース管理の面から言うと、先生の負担はどうでしたか？
特に、第5問は大変だった。3つくらい/1時間くらいしかよめない。崩壊しました。

コピー率は？
単位がほしくて、コピーしたとおもわれるものは20なかった。
へましたりしているのは減点したが。

20っていうのは少ないと思えるが。

疋田：ゲームの雑誌などからコピーしたという案は？
一応調べました
コピーするために調べたことに対する評価は？
本当に調べないと分からないようなものについては、コピーに対する減点の他に加点を与えた

タイトル：チームワーク試行の学生実験について
発表者：鈴木
鈴木：「全て学生任せで目標だけ提示するという方針でなく，
目標まで学生をぐいぐい引っ張っていくことを目標にした．
長い地上滑走路を使って離陸させるのではなく，航空母艦の
カタパルトで離陸させるような感じ．」
C:和田「飛び出したとたん海に落ちる？」

C:いちまる「学生に見せても恥ずかしくないが，理解もしてもらえないコードでは？」
和田
C:和田「Booth の乗算の理解が足りないぞ」
和田「ブースの乗算を理解してないのではないか？」
「自動的にsinビットの生成は出来ちゃうはず」
C:寺田「教官が楽しめない実験は学生も楽しめないのは真，だけど逆は真ならず」
いちまる「教官が楽しいのはいいかもしれないがハマリすぎるのはいかがな物か？」
C:和田「IP v6 に拡張しましょう」
A:「しています」
C:みとまん「どこがリソースこんしゃす？」
A:「私の精神や，命令の種類，言語のしばり，そして何よりも学生の実力がリソース」
A「命令の種類というのは私にとってははリソース」

和田先生：Boothの乗算は理解していないね。あれは下から計算すれば自動的にsignビットが補正される
Ans:ショートカットできませんよね
和田先生：それはやらない方がいい。

現実を知るものとして。教官が最後まで残っていてデバッグをしていて、部屋が閉められないなんてこともありましたが、負荷が多かったのでは？
それは去年限りだけでは。今年は準備ができているので大丈夫だと思う。

和田先生：それでは、今年は教官は楽しめない？

議長：これは、リソースコンシャスとどんな関連が？
命令の種類、言語の仕様、学生の能力のリソースが問題
カタパルトのように学生を発射させなければならない。

学生の実験を比較的オープンにしているが、
オープンにすると学生はなにをしていいのか分からない。
制限すると、おもしろくない

将来の目標として、OSを扱えるようにしたい
タイトル：
発表者：寺田
Q&A:じゃいあん「アロケーションの量のが...」
A:「ごみ集めから見た時間の流れとユーザから見た時間の流れ．」
C:竹内「ミューテータにアドバイスする GC」
C:じゃいあん「ミューテータがどれだけ速くなるかを考えないと？」
C:竹内「ルート問題だが，ルート問題によって発生する遅れを引けば良いのでは？」
A:「特別なルート，と明示的に覚えておけば良い」
「可変長オブジェクトが出てくるが，扱いが面倒では？」
Q:小出「可変長オブジェクトの扱いは面倒では？」
A:「可変長だと GC には影響を与えないかなぁ，と」
A「GC的にはあまりえいきょうしないのでは？」
「局所性については？」
C:いちまる・小出「局所性の問題は？」
「分別回収は？」
和田「スライドコンパクションをやろうとすると可変長は大変」
寺田「やらないとだめ?」
和田「だめ」
和田「どんなGCにも対応できるベンチマークするのは大変なのでは？」
C:じゃいあん「なにがなんだかわからなくなる」


和田：ミューテータによって代わるのでは？

新陳代謝が激しい,
アロケーションの量が時間の尺度

応答性の問題が発生するのでは？

リアルタイムGCの場合など

GCが動く環境として, 必要な性質を列挙して…
時間尺度として

竹内：超高機能GCだと, どこがゴミを出しているか教えたり, プログラムを直したり,
それはミューテータも高機能にならなければならないのでは？
竹内：GCに入る前にメッセージを出すとか

木をなめるのを, 幅優先か深さ優先でやるかによってミューテータが早くなるなど
シミュレータは同じようなデータをつくらないといけないのでは？

小出：可変長オブジェクトが出てくるが。
Ans:可変長オブジェクトは本質的なのかな？
EmacsなどのStringなどは可変長オブジェクトであるがローカリティでは本質的

竹内：分別回収との関連, 有料としてmutatorからとる

和田：コンパクションアルゴリズムとの関連をつくっておかなければならないね

竹内：実時間GCでは無理なのでは？
Ans:クライアントをシミュレーションすればいいのでしょうが

実時間GCではヒープをある程度がめておいて, 流量を調べるしかないのでは？
それでも, 寿命分布などを考えなければならないのでは？
実時間GCでは寿命分布を考えるとひっちゃかめっちゃかになっちゃう
単純なモデルに帰着させることになるのでは

非定常なシミュレーションがないと意味がない

和田：ナミーバみたいに
ナミーバの性質が分かったらそれも面白い

GCの所要時間を要素ごと、セル種ごとにオーバーヘッドを解析して, 線形結合させたら
結果が出たりしないか？

別の視点として, デバッグ支援としては同じセルを消費するのはいい。この場合,　再現性だけでなく,
付加的な情報をもたせるとよいのでは

タイトル：スタックフレームの情報を使った世代型ガーベージコレクション
発表者：林 芳樹

C:竹内「10%- 遅くするのも目的？」
GC ならば必ずリソコン，なのか
竹内「殿堂ループって有るよね？」
じゃいあん「上がり下がりをトレースしているのか？」
林「それが遅くなった原因」
C:「底値で買いたいわけね」
A:「変な所で GC すると挙動もおかしくなるかも」
負けるな > 林 < 電車
C:じゃいあん「コンパイラがあると，エスケープ解析ってやっている？」
じゃいあん「ループとか関数のエスケープ解析は？」
じゃいあん「Stackにはポインタなどのタグは入っているのか？」
C:じゃいあん「スタックマップは持っているの？ conservative ではない？」
はやし「Stackマップは持っている」
A:「持っている，conservative ではない．」
C:いちまる「平均と分散は？」
A:「差はない」
C:竹内「ミューテータを含む GC の時間」
じゃいあん「Stackはそれほど大きくないので，ずれたところまでを認識するのはどう？ 全部追うのはやめた方がいいと思う」
C:じゃいあん「スタックの追跡が多いなら，スタックの変化を真面目に追うのはやめたら」
竹内「早くする展望は？」
林「StackFrameをどう切るのかを素早く見つけられれば・・・」
林「オーバーヘッドは半分を調べるためにStackを3回なめているのが原因」
竹内「ちょうど半分にこだわらなければいいのでは？」
A:オーバーヘッドは減らせる
竹内「えいやっ！ じゃめなのか？」
林「Stackの先頭を調べないといけない」
竹内「３回も必要なのか？」
林「ホントは二回でいい」
C:竹内「1回で済ませられる，はずでは．」
C:いちまる「スタックが大きくなった時だけやるとか？」
いちまる「有る程度以上Stackが大きくなったら，動作を始めるようにしたら？」

竹内：
Ans:例外はあるだろうが、例外はあきらめる

スタックの上がり下がりをトレースしているのか？
上がりをトレースしていないが, 下がりをトレースしている

ループのエスケープ解析はやっているか？
最適化すればできるかもしれないが, 今回はベースだけ

最短の時間と平均と分散はどうか？
ざっとみただけだが, 1秒〜2秒くらいしか変わらなかった。

下川：スタックのトレースに時間がかかるのなら, スタックを全部コピーしておいてそれを比較すればよいのでは？
寺田：それでは, 同じ関数を何度も呼ぶ場合には使えないのでは？
下川：そうではなく, スタックの中身も調べれば。追っていくというのはつらいでしょう

竹内：早くする展望はないのか？
Ans:どこで切るかを判定して, オーバーヘッドを減らせれば。
半分の場合にはなぜ遅くなるのか？
スタックを3回もスキャンしているのが原因いしている。

竹内：「えいや」ではうまくいかないのか？

タイトル：アートプログラミング
発表者：美馬
C:ミマ「道楽系です」
Q:竹内「実行中断の指示とは？」
Q:竹内「実行中断の支持とは？」
A:「指示と支持の漢字の間違い．」
Q:竹内「* が 4つなら？」
C:いちまる「括弧等を使用した方が良いのでは？」
竹内「matis内部もこの言語で書かれているのか？」
美馬「複雑な部分はJavaで記述されている」
いちまる「コマンドを作る人と使うヒトはべつなのか？」
美馬「別になる」
C:原田「ビジュアルプログラミングとあわせてみたい，後からお話しましょう」

市丸：理解できない処理は無視するとのことだが、何か情報がでるのか？
Ans:NotProcessedというメッセージが表示される

空白行で制御を変えるのではなく, ブレースを使った方が楽なのでは？
ブレースを使うことはできる. また後で、壮大な計画があるのでとりあえず

mathithはこの言語ではかかれていない
Ans:より複雑でないとろをはJavaを使っている。

プログラミングができる人が側にいれば、使い勝手が大きく影響すると思う
目的は2つある。1つは教育用でその場合はコマンドはそれほど多くなくて良い。
デザイン用では, 拡張していくことで解

Visual Languageを使うことができればよいのでは
それは直交概念なのでは？
後で, 興味があるからデザインしましょうか？

タイトル：「置くだけ主義」による情報家電制御
発表者：増井

和田「マニュアルを書く人の脳のリソースの問題ではないのか？」
C:和田「マニュアルや機器を作る人の問題では？」
美馬「時刻を何で表すべきなのか？」
増井「抽象的な感覚」
水戸黄門の入浴シーン!!

多田：マニュアルを書く人の頭のリソースが足りないのでは？
Ans:いや、時刻を数字で表すことでさえも結構問題

疋田：分かりやすいが、メディアに少しとらわれすぎのような。CDのようなかさばるものよりMP3とか
Ans:コンピュータやさんはそういうが間違っているのでは？

PlayStandなんかは新しい著作権保護になりそう
Ans:ジャケットだけ売ればよいからいいかも

増井さんのコンテクストでは, ifもまずいのでは？
目覚まし時計ではifなのだが気にしていないですよね

recursive callについては？
いらない？

和田：今の話きいていると, せまい我が家にまたガラクタが増えるような・・・
Ans:今までたくさんあったリモコンが減るのでいいですよね？

置くってのは実体がある必要があるが, それも面倒になるのでは？
置くだけではなく取るという動作も必要になる？

テレビの例で, 座布団の上に猫がのって進むと困るね。
そうすると, 人や猫にもIDチップをうめるのかね？

電車も来たことですし・・・

タイトル：カーネルとシステムコールを利用しないプログラムのプログラミング技法
発表者：多田
和田「fprintfのフォーマットはソースを見れば，決まっているのでは？」
副田「sprintfを二回呼んでいるところは,」
副田「sprintfを二回呼んでいるところは,1回で出来るという話もある」
天海「callで呼んでいる lsは将来はどうなるのか？」
天海「将来はsystemは不要になる？」
Q:疋田「ハードウェア依存の部分は自分で書くのか？」
A:「それが趣味・目的．」
Q:「ディレクトリ構造はどうする？」
多田「今のUnixのファイルシステムとは違う，ルーズにマッチするシステムにしたい」
A:「属性を表す文字列」
Q:原田「エディタ？」
A:「あるけどねぇ...vi 使ってるし」
C:じゃいあん「C で書いてある部分をできるだけ lisp のレベルに上げる，とか」
和田：さっきのsprintfのフォーマットの件だけど, 動的に調べるだけ？静的にフォーマットを調べれば使っている場所を調べれば済むのでは？
Ans:

そこで"ls -l"を読んでいますが, 将来は？
Ans:OSがなくなれば, そもそもCallなんて必要ないはずなんですね。それなら以外に簡単かもしれませんね

最終的なハードウェアの部分のソースはどのようにして書くのか？
Ans:それが楽しいのですよ.マニュアルを手に入れて自分で書く.
趣味を研究に結びつける・・・

(ディレクトリ関連・・・)

和田：ツリー構造にしないの？
Ans:ツリー構造は見た目の問題で, Atomに入っている名前・キーワードがファイル名になれば
もし, Prosym, 02, genkouとあったときに, 2002年の原稿か, 2番目の原稿かがわからなくなりませんか？
Ans:あまり詳しく考えていないので、

エディタは？
Ans:私はViを使っている. どうしましょうか？

sprintfなんかもLispを使ってかけませんかね？

増井さん、私もHTMLで発表資料つくりましたが, いかがでしたか？
増井さん：まだまだです。
でも、私の方には右（インデックス）がついているよ〜

タイトル：非標準的な方法でTeXを利用するプログラミング
発表者：鈴木信吾
A:「今回のデモで表示しているものは手で加えたもの．当然，通常ならば自動的に入る．」
がぅ
Q:寺田「改行は自動的なもの？手で加えたもの？」
和田「いろいろ組み合わせるよりも，pictureのほうがいいいいのでは？」
いちまる「数詞指定の回数を減らせる」
いちまる「数値指定の回数を減らせる」
和田「電話番号は数字だし，氏名は漢字なのだから 一行の高さを変化させたい．感じは数値の1.5倍程度がいい」
いちまる「幅はいいが，高さを変えるのはむずかしい」
和田「連絡先に印があるのはおかしい」
いちまる「印がないと簡単すぎるので難しいモノにするために印を加えた」
和田「ならば申請者のとかの方がいいのでは？」
「XMLとかへの適用の見込みは？」
いちまる「いまの出力はS式を使うためにもこれになっている」
伊知地「縦書きは英語のをピッチを合わせて使っているだけなのか？日本語用のをきちんと調整して使っているのか？」
いちまる「pTeXを使っているが日本縦書き用の命令は使っていない」


伊地知：知識不足という話？
Ans:知識不足というよりも, 非標準的な方法で使ってはいけないなと
伊地知：組版システムを利用するなら組版システムにしたがって何かを行うべきだろう。組直しはしないの？
Ans:組直しは少しやっていますが

最終的に吐き出されるソースコードを見せてもらえませんか？

和田：そうやって組み合わせるよりもPicture環境をつかうほうが楽なのでは？
Ans：たいていは自動調節によってpicture環境を使うより数値指定しなくてよい

伊地知：アルファベットと日本語のベースラインが違うので, そこら辺をきちんと扱わないといけない

和田：連絡先に印はないよね。申請書などにしないといけない

もっと一般のXMLによって書くことで使いやすくなりますかね？

そういうことをやっているワークショップ・会議が

[連絡先]の[]については何を意味しているのですか？
1文字ずつ切って縦書きすることを表している

タイトル：スケーラブルスイッチDynateraのトラフィックセンサ
発表者：天海
Q:「いくらいくらい？」
A:「一つ前のモデル デ70,000,000円．」
「10Gbpsのポート一つのボードで7000万円」
Q:疋田「MPLS は駄目なのか？」
A:「その可能性は排除はしていない．安価なものを構築するための手段として最初に選んだのがこれ．」
Q:「スイッチの切り替えるのにかかる時間は」...だったのかなぁ
A:「良い数値はわかっていない」
「データの流れがどれだけ継続するのか？というのはどう判断しているの？ バーストが20ms位では悲しいじゃない？」
A「それはむずかしい，データの流れ方はアプリによって変わるのでなんともいえない」
Q:「今，GBps の程度の流量があるアプリケーションはあるのか？」
A:「あります．バーストになるものものもある．」
C:竹内「放送局とかも？」
C:和田「RSBP とかでリザーブする，という対処もあるのでは？」
Q:疋田「SNMP をバーストを検知する仕組があった方が良い．」
A:「そういったものがないが，評価システムをいじればそういうことができるかも．」
Q疋田「SNMPのTRAPを使うとかでスイッチ側で検知する仕組みはないの？」
Q:寺田「一般のスイッチのプログラム(ファームウェア)はどれくらいの規模？」
Q:寺田「全部書換えちゃうの？」
A:「書換えない．ハード(チップ)だけでレイヤ2スイッチとして機能する．ファームはレイヤ 3とかのあたりを担当，あまり苦労して書く必要はない」
A「プリミティブな機能はchipに内蔵されている」

疋田：ルータだと経路を選択してやるけど, ルータは排除したのか？
Ans:排除したわけではない, 安価なを目標に

経路の切り替えの時間は20mSecとのことだが, Complete Blocking？
光スイッチに切り替える間も定常系を使うことは可能
新しいアプリケーションがでてくると, トラフィックの様子が崩れてしまう
これについては未解決課題
大きいトラフィックがきた場合にはショートカットを通って, 定常系は非常系の扱い

竹内：今, 実際にGを使うようなアプリケーションというのはあるのか？
Ans:エッジの方のサーバなどでは結構ある

全部のポートがいつも最高速で動作しているなら高価なスイッチが必要
Ans:あいているポートがあって, 早く動いたり遅くなったりとするような場合には適用できるか。

最後のプログラマブルスイッチの場合で中身に含まれているプログラムの大きさはどのくらい？
Ans：ファームなしでもチップだけでもLayer2スイッチとして動作するようにはなっている。

タイトル：分散環境における記憶領域資源を考慮するタスクスケジューリング手法
発表者：小出

Q:中島「Grid 技術と Grid コンピューティング技術の言葉の意味の違い(使い分け)はある(している)のか？」
A:「同じ．」
副田「一番細いところが100Mbpsで，レイテンシが2.7ms程度のようだが，これによる影響は？」
小出「レイテンシ以外は特に考慮する必要はない」
小出「タスクの割り当てに1-2msかかっているので，特に考えなくてもいい」
小出「タスクの実行に 数十 ms かかっているので，なおさら問題ない．より粒度の小さい問題なら考える必要が出てくるかも．」
Q:寺田「一回のタスクはGCの起こらない大きさ，とあるがそれは現実的か？」
A:「4s 程度で終わるタスクで実験しているが，これが現実的とは限らないことは認める．」
Q「複数のCPUへの割り当てとグリッド環境の本質的な違いはなに？」
Q:竹内「普通の並列どどう違うの？」
A:「今はそんなに違わない」
Q:疋田「要素が動的に変化することは想定している？」
A:「している．」
Q:竹内「動的な変化に対応するには，予測に頼り過ぎているのでは？」
あれ?ベクトル計算向けとそうでないもののハイブリッドとかそういう話，以前pttで聞いたような…
A:「従来の研究で色々やっていた．」
いちまる「過去にpttで，vectorマシンとscalarマシンの混合の分散環境の話を聞いた気がするのだが・・・」
小出「たしかに昔やっていた．」

Grid環境とGridコンピューティング環境とはどう違うのか？
Ans：同じ

副田：一番細いところが100Mでping が2.7ミリ秒というのは実際に影響が出ていますか？
Ans:タスクの割り当てに数ミリ秒かかっているが, 今回の粒度では問題はなかった


寺田：Javaのクラスはずっと動作しているのだよね。で、ヒープの大きさを使っているけど, それはOKなのか？
Ans:返り値とともにヒープサイズを返しているので情報は得られている。
寺田：タスクというのはGCが1回も起きないという仮定は大丈夫なのか？


複数のプロセッサに処理を割り当てるのとGrid環境を利用するのは
Ans:私はスケジューリングの部分に焦点を当てている。ほかの研究結果は利用しようと考えている

竹内：Grid環境と一般の並列計算機との違いはあるのか？
Ans:今のところは同じようになっている
竹内：現在のところでは並列計算機とGridの違いをつかっていない
Ans：より一般化できるようにあまり制限をしない考えている


疋田：動的に計算機資源が変動する場合は大丈夫か？
Ans:現在の方法では途中で使えなくなってもOKなはず

竹内：たくさんの情報をつかってスケジューリングを求めているけど

市丸：数年前のPTTで並列計算機とGridを分けてやっていた話を聞いたような気がするが。
Ans:流体実験の構造実験をスカラー計算機を利用して解くという問題でした。

実装がすんでいないという意味でこれからということ？
Ans:もう一度作り直しているというところ
Javaの場合ではGC抜きには話ができないので, Java言語独自の問題について
今回考えてみたという感じ

タイトル：資源消費最大化戦略に基づく相互作用モデル：SLIT
発表者：和泉

疋田：このようなものの場合, 初心者と上級者がいる場合に, インターフェイスは初心者に併せているので
上級者がいらいらすることがあるけど
Ans:実際に人間の場合でもソフマップのおねぇちゃんみたいな例があるし

伊地知：デパートの店員がなぜいいか、というとユーザをみわけてうまく声をかけてくれる
Ans:いい店員がそこまで考えているかどうかもわからない。
挨拶戦略から応答があればとか、目が合うまで店員がまっているかもしれない
あれもこれもできますよねといって、何もできないのは避ける.

伊地知：受動的だけどうまくできるというのにはどうかんがえているか
Ans:あくまで主導権はシステムにあって, トリガーとしてユーザがアイドルのときに
声をかえようとする。というふうに考えている

竹内：3人がどのように違うのかわからない
Ans:

副田：このシステムの対話性というのはどこまで考えているのか？
Ans:通信する量は少なくてよく,それでも情報は伝わるように
カーナビで"これから行く目的地は…"などということはいらないはず
副田：相手からのコンテクストを受け取って, その差分を相手におくることで
コンテクストが近づいていくことがあるけど
Ans:これについては, 近づくのはユーザだけとする

タイトル：GHCからLMNtalへ
発表者：上田 和紀

いちまる「例外処理は絵ではどうなるの？」
上田「例外処理は幕だと思う．幕から外に出ている人に影響しないように，幕外に出ているリンクをケアするようにすればいい」
中島：さっきのグリッドつくるやつ。右下に書いてあるルール。sにつながっている灰○をコピーできるか？
Ans:一般にはできない。コピーを定義していればOK
原田：同じ数字をしたいとか
Ans：Integerみたいに要素が1つしかないようなものはコピーできるようにしたい. Consセルのように要素が3つあるような場合はコピーを定義してもらう

鈴木：例外処理を実現したいとすればどうやっておこなうか
Ans:膜は国境のようなもの, 膜の中でうまく処理を行い, 膜の外に悪影響を及ぼさないようにする。

タイトル：ビジュアル言語の空間問題
発表者：原田
Q:いちまる:連続シーケンスものの途中で別の仕事をしたとき，どうなるか
A:状態が残っているかどうかで変わる
Q:それは，状態管理を人間に任せているということか
A:少なくとも，システム側で面倒するような機構は実装していない
実際には，処理手順が残っていることをユーザに通知する系をちょっと書いてやれば良いだけなので，大した問題ではない
Q中島「線の立体交差という概念はあるのか？」
A「全然気にしてない」
Q:いちまる「文字の挿入とかは？」
A:「これでできると思う」
Q:いちまる:行末まで入力したら折り返す…というようなことをどう表現するのか想像できない
A:これで構築するのが困難であれば，別の言語でblack boxを作成して（アイコンとして?)取り込めばよい
Q「Officeってことは，漢字変換とかスペルチェックまで考えているの？」
A「部品として，Cで書いて呼び出すようにするようにする」
Q:結局ドメイン・スペシフィックなのでは?
A:汎用言語化するのは「大目標」

中島：線の立体交差などは考慮されているのか？たまたま線が交差している場合に端点として表されるか？
Ans:そのようなことは何もやっていない。
中島：ということはすべてが立体交差しているわけですね

鈴木：目標はMS-Officeとしていますが, グラフィックの書き換えはこれでできますが, これで文字の入力をやるのか, 別のアプリケーションを組み合わせるのか？
Ans:文字の入力については, このソフトでも可能ではある
ただ, 特定の要素に対しては, ほかの言語で書いて取り込むことも可能。アイコンになってそれから先は触れないが.

伊地知：またVispatchにもどってきているが, どのように考えているのか？
Ans:枠組みとして作り変えている

小出：大規模な応用としては何を考えているのか？
Ans:Office

中島：OfficeということはWordとか仮名漢字変換とかも考えている
Ans：そのようなものはCとかで書けばよい
スペルチェックはウインドウでやるのではなく, 外から与えるようにして
データは触れるようにしたい

タイトル：塗り壁パズル解答プログラミング--グラフプログラミングの一例
発表者：高橋
訂正事項@用語説明
ベキ集合->非順序対集合
Q「集合というのはグラフの集合？それとも値の集合？」
A「単なる数値の集合」
Q:「将棋等では複数のグラフを組み合わせる，といった手法を考えているのですか？」
A:「...」

A:「グラフはただのグラフです」
Q「解は一意的ではないのですか？」
A「一意的です」
Q「全解を探索するのか？それとも許容解一つでいいのか？」
A「全ての解を求める」
Q「このプログラムは自動的に解を求められるのか？」
A「いまは人が使うことを考えているので手動．ただし，自動化はやりたいと思っている」
Q「こういうのはEmacsとかで造れるのでは？」
A「Linuxとかで作るのは考えてない」
C:はらだ「Emacs を使うと楽だよん」
鈴木：Uniqueな解を求めるプログラムをみせてもらっているが, これでは8-queenのような問題は解けないのではないか？
Ans: これは塗り壁問題に特化したもので, 8-queenの問題ではほかの手法を利用して解いている.

原田：このような問題はLispなどを使った方がらくなのでは？友達にEmacs Lispを利用して解いた人がいる
伊地知：Prologなんかでも簡単に解けるような問題ですね.