0717議事録
2008/07/17議事録
○今後の予定
・来週23日の会議はA&Aで12:00～13:00
・25日にＳＦＣで池田研ゼミ
・30にＳＦＣで池田先生と最終打ち合わせ
○確認事項・変更事項
・現在朝山先生に連絡が取れていないので、前回の人数と、win/macの内訳の件を早急に確認する
・インターネット上のフローティングライセンスのような形になる。それをダウンロードするために
新しいサーバーが必要となる。電機大学内のＬＡＮはどうなっているかについて確認。
・マシンが用意できるか、ネット環境はどうかについても確認。
・ＩＰアドレスを書くくらいでダウンロード可能。
・授業終了後にパソコンのサーバーの電源を落とせば使えないので、いちいち回収せずによくなる
・ゼミの間に打った朝山先生へのメールが返ってきてから
○シラバス
変更点
・いきなり課題から入るのは難しいので、授業編と課題編にわけ、まず授業編を作る。
・コンピュータを使ったアルゴリズミックデザインがないといけない
・ワークショップの説明の前に、なぜ学生が学ぶかの理由をいれる
・最初に、大前提が必要。(池田先生が書いてくれる)
・ルールを書き変えたらまっさらな状態で。
・コンピュータデザインが何か分かった上で、その実際を体験して、デザインにアルゴリズムを生かすことを理解していく。
・主旨を、全く知らない人にもわかりやすいように文章をきちんと書きかえる。
・課題条件に高さも入れてやる。現在設定しているものとはスケール的に違うものでもいい。例えば団地の棟の配置や図書館の本棚のレイアウト、窓の開き方など。
・それがどんな意味をもつのか。何を目的に作ったのかが大切だが、まず最初の二時間くらいはわけもわからず使ってみる。やってるとそのうちそれが何かに見えてくる。後付けして、アルゴリズムが見えてくる→目的的にアルゴリズムを作る
というサイクルを繰り返すのがよい。
・解説として
「コンピュータを使ってデザインすることは、一般的にはＣＡＤみたいなものを使って線が引きやすい→三次元ができやすい→曲面ができる。だが、本質はツールとしてデザインをどのように支援するかである。よって、ここではその先のシステム構築としてのアルゴリズミックデザインの構築を目指している。
コンピュータとアルゴリズミックデザインの関係があって、アルゴリズミックデザインの現実的な意味。デザインをする上で、基本要求条件に対して何らかの空間的な解法を求める、変化の激しい、あるいは多様性の激しいことに対して均等均質ではない方法でダイナミックに答えを求める。」と入れる。
流れ
大きな目的→アルゴリズミックデザインが一体何をするのか→デジタルエスキースツールを使うとアルゴリズミックデザインがやりやすくなる。
日程
・八月四日、五日には思い切りソフトを使えるようになっていないといけない。
・ツールによる試行錯誤→テーマ探し→アルゴリズム作り→モデリング結果の二次的処理→レンダリング→パワポづくり
・一応レンダリングぐらいまでは授業のうちにどうにかなるように組まないとだめ
・ベクターでどんなことができるか、どのくらいを求めてるかは明確に提示しなくてはならない。
・インストールを一日目に前倒し
アルゴリズムとは何か
・何らかの人間の活動の変化や多様性みたいなものに対して空間をある程度自己組織的に、自律的に対応させるようなもの
・コンピュータを使ってそれに対する最適な状態を求める。ある単純な手順にしたがって部分部分にある単純な手順を適用していく。
・アルゴリズムは手順を書き出したものだから、我々は非線形なものとして扱わなくては意味がない。
・一定のルール、手順に従って計算を行う部分部分に対してのアルゴリズムを繰り返して全体に適用していく
・アルゴリズミックデザインとは部分から全体に展開していくような自己組織的なものになる
○プログラム
・グローバルなルールとローカルなルールの差を明確に区別しなくてはならない
・グローバルなルールがアルゴリズミックデザインをやってくれるわけではない。
・全体のことがわかる時点でおかしい。自分の視野範囲のことがわかるのは正しい。
枠からはみ出さないとかは、式で書くことじゃない。
それは環境条件であって、ここで作ろうとしているルールではない。
・サンプルとして示すのは、こっちのパラメータこうでこっちのパラメータこうだったら増えますといったものにするかどうか
・環境条件を決めるところからスタートし、それに合わせるシステムをつくる。環境条件を条件設定しなくてはいけない。
敷地範囲にはみ出さないようにするというのは環境条件・適応条件
・まず各エージェントの働きを決めなきゃいけない。視野の話が次に出てくる。どの範囲を選ぶかが重要。外的条件は途中で変わってもよくて、完全にトップダウンでもよい。
・遺伝子を消すということも全体のシステムに影響しているが、消すというのはフィードバックとしては弱い
・環境に対してどんな反応をするのかというのはきめとかないといけない。
・状況に気づいて反応させないといけない。敷地範囲からある程度以上離れていると死んじゃうといったような。
・あいまいさや逆フィードバックができないとだめで、逆のベクトルを持つルールを組み込んでおかないとだめ。
・目標値を決める→それに対してどのくらい離れているかというので評価を決める。その時１００点満点にならないとだめで、 優等生を決めるだけではだめ。ある側面からみれば劣等生でないとだめ。
・別の評価を入れればいい？マイナス評価を入れる？目標から離れていくと評価が高くなる。(１－距離分の一)その時、大きさが十に近づくと評価が高くなるというのと同時に11に近づくと評価が下がるといった一見矛盾するルールを入れる。
・目標値を決める。→目標値ポジティブor目標値ネガティブかを決める→評価値が決まる→それをどのように足し合わせるかを決める
・窓の中で、できるだけ2対１のプロポーションがいい、くっつきすぎないでほしい、できるだけ窓は多いほうがいいといった複数の要求をかなえる。ブレンドの数字を最後いじって調整する
・評価関数は基本的には点数つけ方式でやっていく。0から1に置き換えなければ何もできない。式を書いて目標値幾つと書くと自動的に評価値になる。式に置き換えてうまくいくかどうかがアルゴリズム作りのうまい下手。試行錯誤するしかない
血だらけ修正。
