いいじまです。

> > 新城案では、「結果的に組合せ爆発するような依存関係の記述」になった
> > 場合に、その爆発を押さえ込むことができません。
> 
> 私は楽観的です。人間の思考がもともとその程度なので、そもそも
> 複雑な議案の組み合わせは最初から提出されないと思っています。

ここまでは同意です。

> 今の例で複雑になっているのは、飯島さんが、自説の補強材料とし
> て、複雑な例、しかも、新城案ではもともと禁止されているような
> 例を出しているからです。元々の新城案の範囲内では、複雑にはな
> りません。

う〜ん、新城案では何が禁止されていて何が可能なのかが、今の今まで明確で
なかったんですよ。

「依存」という言葉の定義すら私には理解できていませんでしたから。

<余談>
これは「依存」という言葉（新城さんの研究分野では割と一般的な言葉だとは予
想していますが）を使わずに「連鎖廃案」とかいう説明的な用語のほうがいいよ
うに思います。「対立」の語にしてもしかりで、この用語は対立関係にある２案
が対称な印象を与えますが、実際の新城案では非対称な「対立」もあるわれです
よね？

ま、用語が複雑なのは久野案にしてもそうで、「議案群」という言葉だけは何と
かしたほうがいいと思いますけど。
</余談>

で、私がいろいろ出している例は、新城案で扱えるかどうかをいったん脇に置い
てから、「参加者から自然に出てくるであろう要望」ということを念頭に置いて
出しています。そういう、自然に出てくるであろう要望を新城案で扱えるかどう
かを検討し、それは扱えないと示したのがいままでの例示です。

そして、そういう例を「扱えない（ルールにない）」として切り捨てるつもりな
らば、自然に出てくるものを、並列化という（私としては拘泥すべきとは考えら
れない）目的のためだけに安易に切り捨てるというのは問題である、と、ここで
主張します。

> > とすると、「具体例を頭の中に描」くためには、考え得る結論の数が、組合せ爆
> > 発しない程度の少数におさまっている必要があります。7 個程度までにおさめる
> > のが理想ですが、12 個くらいまでなら何とかなるでしょう。それ以上だとちょ
> > っと投票参加者の手に負えません。
> 
> 一度に認識できるのは、６か７ですが、チャンクを作ればもっとい
> けるという話は、聞いたことがあります。７色の虹とか、ＯＳＩの
> ７層モデルとか。

はい。その通りです。だいたい 7 で、チャンクがうまく作れた場合はそのチャ
ンクを全体で 1 個と数えて、それで 7 個です。この説の初出の論文のタイトル
は「魔法の数字 7±2」ですけど、プラス側に振って、もう少し頑張れば、単純
なものなら 10 個くらいはいけます（笑）

でも、うまく 7 チャンクにおさめられますか？ ほぼ独立な議案ならいくつあっ
ても外部記憶（人間の頭の外の紙なりエディタ画面なり）に全部書き出して逐次
処理すればいいんですけど、ちょっとでも依存関係が出てくるとお手上げです。

> 私の提案は、全体像を見渡すことが難しい時には、個々の議案（作
> 成、削除、状態変更）に対して、局所的に賛成、反対を求めるだけ
> にするといいのではないかということです。

いや、私はそうは思わないです。局所的な賛成／反対のパラメータが大局に影響
しないことの保証があるかというと、新城案では NGMP レベルではその保証は与
えられず、そのつど管理人が記述する依存関係にバグがないことによって影響が
ないことを確保するわけです。で、その記述を単純化するために、たとえば「fj.
os.solaris が否決されて fj.os.sunos が成立したなら fj.os.sunos.intel に
賛成」といった、そのルールでは記述できない（けど人間の発想としては自然な）
意見を切り捨てるわけです。

> 認知心理学的にも、よい方法と言えませんか。

う〜ん、認知心理学というよりはこういう意志決定理論は（認知系の）社会心理
学の範疇だし、私は認知心理学の中ではメンタルモデルとか教科教育への応用と
かに焦点を当てて勉強してた人間だから、このへんの分野はほとんどわかんない
のですが…

たしかに、大局が複雑な場合に「大局から影響を受けない局所」を切り捨てて単
純化するのは、数理的・論理的な問題解決の場面では理にかなった判断で、算数・
数学の問題を解く場合の定石のひとつです。しかし逆に「大局から影響を受ける
局所」は切り離すわけにはいきませんし、ましてや「大局“に”影響を与える局
所」は、下手にパラメータを与えるとカオスの様相を呈します。

私が出している「fj.os.sunos.intel」の事例は、「大局から影響を受けない」
という保証が崩れてしまっている事例です。その前に出した「fj.net.watch.2ch
が可決された」という可能性は、「大局に影響を与える」という事例です。

> 小さい関数をバグがないよう書くというこ
> とを繰り返すことで、大局的に自然にバグがないプログラムが完成
> させようという試みとも言えます。

それはわかります。

でもそれには、前提１：「小さい関数が大きい関数に影響を与えない」を満たす
ように慎重に設計をする必要があります。実際にそうなっていない例は数知れず
……GNU Getopt なんてのは悪しき例の典型。

もうひとつ、前提２：「ぜんぶできあがったプログラムだけを渡されて、どうい
う依存関係があるのかをきちんと把握できる必要がある」のですが、現実のプロ
グラミングでそうなっていない例も数知れず。

それに、この例だと各エレメント間の関係として、ツリー状のもの（もしくは、
ツリーにせいぜい隣の親からも枝が伸びている程度）を仮定していませんか？
そうすると、CFD に出てくる各議案はもっと複雑な関係図（グラフ）を描くと
思うのですが。

> > > ですから、「否決されたら」のような扱えない条件
> >
> > を扱いたいという提案者が出てきたらどうするの、ということです。
> > fj.os.solaris の成否を待って、別 CFD にするしかないですよね。
> 
> いいえ。同じ CFD で扱ってもいいです。同じ CFD なんだれども、
> 「否決されたら」ということなので、否決されるのを待ってから、
> 投票すればいいんです。その案が否決されるまで、
> CFA/CVV/CVS/CFR などの承認手続きを遅らせればいいんです。

ここは了解です。とすると、結局は逐次化するということですよね。
でもそうすると、並列化を目指した今回の改訂は無意味ということになりませんか？

> CFD を、「fj.os.solaris 関連」くらいで１つのチャンクにしてし
> まえば、人間、けっこう扱えます。

ええ。うまくチャンク化できれば。
でも、チャンク化に失敗すると、そこに待っているのは指数爆発です。

> 以前、comp 分野の管理人をしていた時には、チャンクとしては、
> 成立したものだけで、次のものを扱いました。
> 
> fj.lang.ruby
> fj.comp.lang
> fj.comp.input-method.*
> fj.comp.statistics
> fj.comp.applications.*
> fj.comp.dev.pc-card
> fj.os.ms-windows
> fj.os.ms-windows.misc
> fj.os.beos

ええ。この中で依存関係のある複数の議案が出ているものは…過去の記録を調べ
ずに書いていますが、
        ・ruby と comp.lang の競合
        ・ms-windows の分割
        ・input-method が倒れたらそのサブカテゴリをどうするか
        ・application.* がぜんぶ不成立になったら applications.misc を
        　どうするか
あたりですか。

このくらいなら、それぞれ独立な部分を切り出して分割採決、あるいは逐次化処
理をすれば、チャンクにしなくてもいいと思います。

で、その程度で済むのであれば、いまの新城案には「牛刀を以て鶏を捌く」とい
う印象を受けます。

                                ☆

> > ここからもわかるように、参加者が問題にするのは、「最終的にどういう組合
> > せのグループができあがるか」であって、必ずしも無矛盾性ではありません。
> 
> 矛盾ができないというのは、たとえば、改名の時に、「fj.sys.sun
> の削除」と「fj.os.solaris の作成」の片方だけ成立しては困ると
> いう意味で、矛盾がないと言っています。改名の時には、明らかに、
> この意味での矛盾が起きないことが望まれています。
> 
> 無矛盾性というのは、そういう意味であって、自分の都合のいいよ
> うに拡大解釈をして、批判するのはやめていただきたい。「キャン
> セル」の拡大解釈もひどかったけけど。

それは……無矛盾とか、キャンセルとか、そういう言葉の定義が新城さんから明
示されなかったから、自分が合理的と考える解釈に基づいて話をしたまでのこと
です。

改名のときに「改名元の削除」だけが通って「改名先の新設」が通らない、そう
いうタイプの矛盾は困る、それは同意です。

でも、「同じ目的のものが重複する」というタイプの矛盾（これは新城さんが矛
盾という言葉で示す範囲からは外れているかもしれませんが）は、かまわないと
思っています。fj.mail.friends のときは、fj.personal-ads.penpals が同じ目
的のまま残ってもかまわなかったと思っています。

いま投票結果を出して異議待ちの fj.os.ms-windows.server2003 に関して言う
なら、対案として否決される見込みの fj.os.ms-windows.server が同時に成立
してもそんなに問題ではないわけです（まあ、そうすると今の fj の状況では
.server2003 のほうの流量が期待できないという事情になるわけですが、かつて
fj に活況があったころなら、それでも通ったでしょう）。

＃fj.os.ms-windows に関しては次の手を考えています。これの原稿はいったん
＃書き上げてありますが、投票結果が確定してから文面を再度推敲して、それか
＃ら最終的に出します。

========================================================================
飯嶋 浩光 / でるもんた・いいじま   http://www.ht.sakura.ne.jp/~delmonta/
IIJIMA Hiromitsu, aka Delmonta           mailto:delmonta@ht.sakura.ne.jp

───【宣伝/ADVERTISEMENT】──────────────────────
fj.os.ms-windows.server2003 または fj.os.ms-windows.server の新設の可否
を問う投票の暫定開票結果を fj.news.group.comp で発表しました。
投票されたかたは再度、正しく集計されているかどうかご確認ください。
異議の受付は9/3(水)いっぱいを予定しています。
────────────────────────────────────