ngMP v8

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

新城さんの記事が手元に流れて来ないのでよそから入手してフォロー
つけます。お盆の間は流通がダメかなあ。

新城さん:
: NG とか、out of order とか投機とか、好きなんだけど。

私も好きですけど、計算機屋でない人に読めないNGMPになりそうだから
そういうものを入れるのは我慢して欲しいです。再帰とかも。まずは
「平に」記述して、その改訂が通ったあとで「これを使えば同等だけど
規則がもっとシンプルになる」という形で説得してみてください。

: 重み付き CFA というアイディアは簡単なのに、なんで手続き的に書き
: にくいんでしょうね。CFS は、重み付き CFA と同じにすれば簡単なは
: ずで、全部これに統一できるはずなんです(fj大統一理論)。

Weighted Reference Countingとかも応用できそうですね。ですがお願
いですからここは我慢してください。でないと我々が何時間も費しても
何も成果を産まないと思います。

: 不活性は、管理人をする立場で考えると、ちょっと嫌かなあ。たと
: えば、よくあるパタンは、CFA かけたら、英文憲章でスペルミスが
: 見つかって、objection で undo するという話です。スペルミスの
: ものまでトラックするのは、大変かなあ。

「以下は不活性ね」と明記して並べておけばよいと思います。好みじゃ
ないことは分かりますが取り消すのは面倒なことになると思うのでまだ
不活性の方がよいと私は思います。

> CFD期間は標準で2か月とする。管理人は必要と認めた場合CFD期間を延
> 長することができる。期間内であってもCFXの成立によりCFDは終了する。

: １つの議案が不成立になつても、他にも議案が残っているかもしれ
: ないので、この時点で CFD 期間を終りにしてはいけません。

v6ではCFXは議案群の選択を行い、起きることは次のいずれかですよ。

・CFA→成立したらその議案群が成立、他の議案群が不成立決定→CFD終了
・CFR→成立したらすべての議案群が不成立決定→CFD終了
・CFV→成立したら1つの議案群が成立または全議案群が不成立決定→CFD終了
・CFS→CFVと同じ

議案群が成立したらその議案群に含まれるすべての議案が成立し、それ
以外の議案は不成立決定します。ですからv6の世界ではこれであってる
と思います。違っているとお考えならなぜ違っていると思うのか再度説
明してくださいね。

> 管理人は適当と認めた場合、CFDを分割/併合したり、議案を他のCFDに
> 移すことができる。その際、どの議案もそれが属するCFDの満了日が変
> 更以前より早くなってはならない。

: この辺り、下手に制約を付けると、３ヶ月の再提出期間などとの辛
: みで解が存在しないということになるかと思います。

分かりました、制約をやめときましょう。

: 議案群の概念を、まだ理解していません。議案と議案群とCFDの関
: 係が。

うーん、再度説明を改良しましょう。

> CFDに属する議案は最終的に成立/不成立のいずれかとなる。
: ^^^^ これは議案群？

議案群も議案も、です。議案群は最大1つ成立します。そのとき、成立
した議案群以外の議案群はすべて不成立となります。成立した議案群に
含まれる議案はすべて成立します。それ以外の議案はすべて不成立とな
ります。

> 1つのCFDには0個以上の議案群(Issue Group、IG)が所属する。議案群は
> 議案の(排他ではない)部分集合であり、提案者の意見を参考にしながら
> 管理人が決定/変更する。

: 議案がCFDに属しているので、あるCFDに属している議案の全体があっ
: て、その全体の集合の部分集合が議案群、というのはいいとして、

> 議案群は同時に成立する可能性のある議案の集合を表す。1つの議案群
> に互いに矛盾する(両立し得ない)議案が含まれてはならない。

: あ、分かった気がする。議案を atom すると、議案群は list みた
: いなものか。うまくやると、再帰的な定義ができそう。

新城案にあった議案どうしの「依存」関係による推移閉包のようなもの
だけど、推移閉包を計算させるかわりに集合の方を決めさせる。なぜそ
うしたいかというと、「依存」「対立」(だっけ?)両方あると推移閉包
とったら中に「対立」が含まれたりして矛盾し得るでしょ? それが嫌。

> 1つのCFDでは、議案群のうちたかだか1つだけがCFXにより成立し得る。
> 議案群が成立したとき、そこに含まれるすべての議案は成立し、それ以
> 外の議案は不成立となる。

: こういう議案群の使い方をしてもいいとは思いますが、そうなると
: 対案が出て争っている時は、どういう扱いになるのでしょうか。
: 議案群Ａと議案群Ｂと分かれたとして、

: 議案群Ａと議案群Ｂは、なるべく同時に投票に掛ける必要があると
: 思います。逐次化しない方がいいと思います。

賛成です! だから議案群AとBを同時に1つのCFXで扱うというつもりですが。

: このような場合をどう扱うかが、複数のCFDの扱いをどうするかが残さ
: れた問題ですかね。

CFDは1つ、CFXも1つ、その中で対立する議案群Aと議案群Bの決着をつけ
る。議案群は「議案の集合」ですからそういうことが自由にできるでしょ?

> 3.7 合意方式(CFX)
> CFXの開始日、期間、管理者/投票管理者はfjでの議論および提案者の意
> 見を尊重して管理人が決定し公告する。管理人がCFX管理者/投票管理者
> を兼ねることを妨げない。

: 投票開始時期を管理人が調整するのは、いいですね。
: 議論期間を前期と後期に分けることにしてみました。

v7を拝見しましたが、意見の相違として次のものがあります。

○議案群を提案者が出せる。これは複雑になるので管理人が決めるだけ
にしておきたいです。駄目?
○再帰的な定義については冒頭に述べたように避けたいところ。
○議案の取り下げは状態を複雑にするので避けたいところ。
○議案種別はやはり減らしたい。原子議案とか言うなら議案群でいい。
○前期後期でなく現行と同様CFXだけでよいと考える。
○議案空間? 使い慣れた「CFD」でいいと思うなあ。
○余計な制約はやめるようにしましたが、公告関係の規定、誰が管理と
いう規定はあった方がいいと思うなあ。

例によって直しましたが(後半は単に戻したといってよい :-)また新城
さんが戻すんだろうなあ。まあもうしばらく振動させましょうよ。取り
下げについては、どーしてもというなら「提案者は取り下げを表明でき
るが、管理人のみが実際に議案を削除できる」みたいなのならいいかも
と思っています。

対立する議案群の同時投票もこれで扱えているつもりですが…

久野

----

NGMP改定案(新城・久野版) v8
v6 2003/08/12 久野
v7 2003/08/16 新城
v8 2003/08/18 久野

1. 総則

2. 管理委員会

3. ニュースグループの管理手順

3.1 総則

NGの管理手順は提案(Proposal)、議案提出(CFI)、公告(CFD)、合意確認
(CFX == CFA、CFV、CFS、CFR)、管理行為の実施の各段階を含んでいる。

(中略)

3.2 状態遷移図

(旧 3.3 提案(Proposal) → 削除)

3.3 議案(Issue)

ニュースグループの一覧表に変更を加える提案を議案(Issue)と呼び、
議案の提出者を提案者と呼ぶ。

議案には、作成、削除の2種類がある。議案提出(CFI)にはそれぞれにつ
いて以下の情報および提案者が明示されている必要がある。提案者の情
報は到達可能なメールアドレスによる。これら以外の情報、理由づけな
どは要求しない。

a) NG作成: 対象NGの名称、憲章、1行英文、moderated/unmoderatedの別
b) NG削除: 対象NGの名称
c) NG変更: a)とb)の任意の組み合せ。

CFIはNG 管理グループに投稿されるとともに、委員会あてメールで通知
されなければならない。

管理人は通知を受けてから1週間以内に、提出された議案が属するCFD
(後述)を決定する。

管理人は必要と認めた時は自ら提案者となり議案を提出できる。

議案は提案者と内容によって識別される。同一内容の議案が複数人によっ
て個別に提出された場合は別個の議案として扱う。

議案の内容および提案者を変更することはできない。

議案を取り下げることはできないが、管理人は提案者の意思や不在など
の事情に基づき、議案を不活性と宣言しCFXの対象から外すこと、また
それを取り消し旧に復することができる。

[解説] 改名、分割、憲章変更、moderated状態の変更等はすべて既存NG
(必要なら複数)の削除と新規NG(必要なら複数)の作成によって行う。

[解説] 複数の提案者が同一内容の提案を提出できるのは、誰が提案者
になるかで争いがある場合を想定している。

[解説] 議案の内容や提案者を変更したい場合は新たな議案を提出し、
古い議案を不活性化する。ただし実際に不活性化するか否かは管理人が
判断する。

[解説] 1行英文はニュースリーダなどの参照機能に使用するためのもの
であり、60文字程度に収めることが望ましい。

3.4 CFD

類似した議案を一括して審議することをCFD(Call for Discussion) と
呼ぶ。CFDは管理人が管理するが、CFDに含まれる合意確認(CFX、後述)
は管理人または提案者が管理する。

1つのCFDには1つ以上の議案が所属する。

管理人は議案が提出された時に、所属するCFDを決定する。その時適当
なCFDがなければ、新たにCFDを開始する。

管理には新たに開始すべきCFDが進行中のCFDの結果に依存すると判断し
た場合、および先行する同主旨のCFDの開始から3か月を経過していない
場合は、当該CFDの開始を適切な時期まで遅れさせることができる。

CFD期間は標準で2か月とする。管理人は必要と認めた場合CFD期間を延
長することができる。期間内であってもCFXの成立によりCFDは終了する。

管理人はCFDの開始決定、開始、含まれる議案/議案群(後述)の変更、
CFX開始決定、CFD期間変更、CFDの終了に際して、そのことをNG管理グ
ループおよび議案によって影響を受けるグループに公告する。ただし影
響を受けるグループが多い場合にはその一部への公告を持って替えるこ
とができる。

CFDの公告にはCFDを一意に識別する名称、含まれる議案、議案群の情報
が含まれなければならない。

管理人は適当と認めた場合、CFDを分割/併合したり、議案を他のCFDに
移すことができる。

[解説] 旧NGMPと異なり、fj直下の変更については特別に扱うことはし
ないが、管理人はいつでもfj直下の変更を伴う議案に対して直下の変更
を伴わない代替の議案を追加提案できる。

[解説] 旧NGMPと異なり、公告は管理人が行い、公告先の判断も管理人
が行う。このため公告の範囲に関する規定は設けない。

3.5 議案群(IG)

CFDに属する議案は最終的に成立/不成立のいずれかとなる。議案が成立
するのは、その議案を含む議案群が成立した場合に限られる。

1つのCFDには0個以上の議案群(Issue Group、IG)が所属する。議案群は
議案の(排他ではない)部分集合であり、提案者の意見を参考にしながら
管理人が決定/変更する。

議案群は同時に成立する可能性のある議案の集合を表す。1つの議案群
に互いに矛盾する(両立し得ない)議案が含まれてはならない。

不活性であると見なされる議案はどの議案群にも含まれなくてよい。

1つのCFDでは、議案群のうちたかだか1つだけがCFXにより成立し得る。
議案群が成立したとき、そこに含まれるすべての議案は成立し、それ以
外の議案は不成立となる。

3.6 合意方式(CFX)

成立する議案群の決定はCFA、CFR、CFV、CFS、のいずれかのCFX(合意方
式)によって行う。

CFA(call for approval)では、議案群の1つを選択し、一定期間内に異
義が出なければその議案群が成立する。異義が出た場合はCFDは継続す
る。CFAは一人が管理者となり、広報および異義の受け付けを行う。

CFR(call for rejection)では、一定期間内に異義が出なければすべて
の議案群が不成立となる。異義が出た場合はCFDは継続する。CFRは一人
が管理者となり、広報および異義の受け付けを行う。

CFV(call for vote)では、一人が投票管理者となり、すべての議案群そ
れぞれ、およびすべての議案の不成立について、賛否を問う。結果が出
た時点でCFDは終了する。

CFS(call for signature)では、複数人が投票管理者となり、それぞれ
が個々の議案群、およびすべての議案の不成立について投票を管理する。
結果が出た時点でCFDは終了する。

CFXの期間は2週間以上とする。上限は設けない。

CFXの開始日、期間、管理者/投票管理者はfjでの議論および提案者の意
見を尊重して管理人が決定し公告する。管理人がCFX管理者/投票管理者
を兼ねることを妨げない。

1つのCFDについて複数のCFXを並行して行うことはできない。複数のCFX
の希望があった場合、管理人は原則としてCFR、CFA、CFV、CFSの順で後
のものほど優先順位が高いものとして実施するCFXを決定する。

CFXの開始を決定し公告した後でも、開始までは決定をやり直すことが
できる。開始以降はCFSの投票管理者追加のみが行える。

CFXの期間中は議案群の構成は変更できない。新たに追加された議案は
CFX期間が終るまで不活性と見なされる。

CFXに関連して管理者/投票管理者がNG管理グループおよび関連グループ
に公告を行う場合は、その投稿範囲は管理人がCFDの公告を行った範囲
と一致させることが望ましい。

CFXの期間中、管理者/投票管理者は自分が管理するCFXないし投票募集
について適切な広報を行うものとする。

[解説] 旧NGMPと異なり、CFXの公告は管理人が行う。このため、告知の
投稿範囲に関する規定を廃止している。ただしCFXに関する開始/終了/
広報の投稿はCFX管理者/投票管理者が行う。

3.7 沈黙による決定(CFA/CFR)

CFA/CFRは議論の結果合意が得られたと思われる場合に投票管理の手間
を省いて合意を確認する手段であり、期間内に異論が提出されなかった
場合に成立する。

CFA/CFR管理者は管理人が指名する。当該CFDに属する議案提案者の中か
ら指名することが望ましい。

CFA/CFR管理者は開始までに異議の形式について規定しNG管理グループ
および関連グループに公告しなければならない。異議を出すのが困難な
形式を指定してはならない。

[解説] 異議の形式として慣習的に「Subject: [Objection] (元
Subject)」というものが指定されることが多い。

[解説] CFRはどの議案群も成立させないのが適当であるという合意を確
認する手段、またはどの議案の提案者も不活性となったためCFDを早期
に終了させる手段として用いることが想定されている。

CFA/CFRに対する異議の提出者は、異議をCFA/CFR管理者と委員会に
E-Mail で通知するとともに、NG管理グループで公表しなければならな
い。異議の提出者が投稿を行えない場合は管理者または管理にが異議の
文面をNG 管理グループに公表する。

異議はどのCFA/CFRに対するものか明確でなくてはならない。異議に理
由づけは必要とされない。異議を取り下げることはできない。

期間内に委員会に届かない異議、および指定された形式に沿っていない
異議は無効とする。

CFA/CFRが異議により不成立となった場合、管理にはそのことをNG管理
グループに告示する。

[解説] 委員会と管理者の両方に異議が届くことになる。事故等により
届いたかどうか定かでない場合は委員会が最終的に判定する。

3.8 投票による決定(CFV/CFS)

3.8.1 投票に関する共通事項

投票はCFDに含まれる議案群、およびすべての議案を不成立とする案(以
下、これらを併せて選択肢と呼ぶ)について、YES/NOの二者択一投票を
行うものである。

投票は参加者のE-Mailによる記名投票で各選択肢について一人一票とす
る。条件付き投票は認めない。

[解説] From:に含まれるコメントをもって記名としてよい。

指定された形式に従っていない投票は無効票とし、集計から除外する。
ただし投票期間内であれば改めて指定された形式に従った投票を提出し
直すことはできる。有効な投票の内容を変更することはできない。

投票において理由づけは要求されない。投票内容を理由にして投票者の
今後の投稿にいかなる制限も加えることはできない。

投票管理者が自動集計システムや他サイトが提供する投票箱などの機能
を利用した場合でも、投票管理および結果公表の責任は提案者が負うも
のとする。

自動集計システムや投票箱などに付随した制約は、投票の告知に含めな
ければならない。そのような制約は、投票結果に不公平をもたらさない
ものに限り認められる。

選定方法は次のとおりとする。過半数の賛成を得た選択肢の中から賛成
/反対の比率の最も高い候補を採択する。比率の最も高い候補が複数あ
る場合には、その中から賛成票の多いものを採択する。賛成票の数と比
率がともに等しい候補が複数ある場合には、管理人が選択する。この選
択に関する異議は認めない。

過半数の賛成を得た選択肢がない場合は、すべての議案を不成立とする
選択肢が過半数かつ最多の票を得たものとして扱う。

投票の途中結果の公表を行うか否か、および行う場合の形式については
投票管理者に任される。ただし虚偽の公表、投票結果に偏りをもたらす
ことを意図した公表を行ってはならない。

投票結果は委員会にE-Mailで通知するとともにNG管理グループに公表し
なければならない。

公表には集計結果に加えて全投票者の投票内容が付随しなければならな
い。

[解説] 投票期間終了後、正式な公表に先立って投票内容を公開しチェッ
クをおこなう場合が多い。

3.8.2 投票(CFV)

CFVは一人の投票管理者がCFDに含まれるすべての選択肢についてまとめ
て投票管理するものである。

議案群が1つしかない場合に限り、YES/NOを1つだけ問い、YES/NOの数値
を入れ換えたものをすべての議案を不成立とする選択肢の投票結果とし
て扱ってよい。

投票結果が公表されない場合は、すべての議案を不成立とする選択肢が
過半数かつ最多票を集めたものとして扱う。

3.8.3 署名(CFS)

CFSはCFDに含まれる選択肢について、複数の投票管理者がそれぞれ投票
を管理するものである。

1人の投票管理者が複数の選択肢の投票管理を行うことができる。

1つの選択肢について複数の投票管理者が投票を募集してもよい。その
場合、最終集計時にそれらの投票をYES/NOそれぞれについて合算する。
同一人による重複した投票は一票と数える。同一人がYESとNOにともに
投票している場合はその投票者の投票をすべて除外する。

CFDに含まれる議案群のうち、投票管理者が現れない議案群については
投票を行わない。投票期間中にそのような議案群について投票管理者が
現れた場合はその時点から投票を行うが、投票期間自体は変更しない。

すべての議案を不成立とする選択肢については必ず投票を行う。この選
択肢の投票管理者が現れない場合は委員会が投票管理者となる。

投票結果が公表されない場合はその議案群の投票がなかったものとして
扱う。すべての議案群の投票結果が公表されない場合はすべての議案を
不成立とする選択肢が過半数かつ最多票を集めたものとして扱う。

3.9 CFD期間の満了 (Expiration) ←旧3.8

3.10 管理行為の実行 (Execution) ←旧3.9

(旧3.10 NG管理行為の再CFD → 削除)

(旧3.11 複数議題の扱い → 削除)

3.11 管理行為への異議と差し戻し

3.12 委員会による緊急の管理行為

---

[Yasushi Shinjo]

新城＠筑波大学情報です。こんにちは。

In article <bhll3s$u...@utogw.gssm.otsuka.tsukuba.ac.jp>
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> 久野です。
> 賛成です! だから議案群AとBを同時に1つのCFXで扱うというつもりですが。

ngMP v8 で、具体的に、次の問題をどう扱うのですか。

fj.net.watch
fj.news.from.misc
fj.news.from.2ch
fj.news.from.blog
fj.news.from.slashdot

同じCFDですか、違うCFDですか。v5 では、同じ CFD です。
現行NGMPでは、今回管理人は、同じ CFD という判断しています。

> CFDは1つ、CFXも1つ、その中で対立する議案群Aと議案群Bの決着をつけ
> る。議案群は「議案の集合」ですからそういうことが自由にできるでしょ?

CFDは1つだけど CFX は、最低２つ必要だと思います。v5 でもそう
です。というのも、現行NGMPでは、fj.net.watch の提案者が、
fj.news.from.{2ch,blog,slashdot} を同じCFX に入れることを拒
否しました。v5 では、これを同時に投票することを認めようとし
ています。

＼＼　新城　靖　（しんじょう　やすし）　＼＼
＼＼　筑波大学　電子・情報　　　　　　　＼＼

[IIJIMA Hiromitsu]

いいじまです。

> 私も好きですけど、計算機屋でない人に読めないNGMPになりそうだから
> そういうものを入れるのは我慢して欲しいです。

全く同感です。現行の NGMP でも法律・契約系の文章を読むセンスがないと運用
できないのに、計算機科学系の知識まで要求してしまうと、議案を提出できる＆
管理人を務められる人がごく限られてしまいます。

☆

あと、本質的でないところで文面のほうを。

> 1つのCFDには0個以上の議案群(Issue Group、IG)が所属する。議案群は
> 議案の(排他ではない)部分集合であり、提案者の意見を参考にしながら
> 管理人が決定/変更する。

「排他」「部分集合」というキーワードが、「自称文系」な人にはわかりにくい
ような。論理学とか集合論とかをそれなりに勉強していれば自明な単語なんです
が、悲しいかな、今の高校以下のレベルでは非常におざなりなところなので。

1つのCFDには0個以上の議案群(Issue Group、IG)が所属する。
それぞれの議案群は1個以上の議案から成り立つ。1つの議案が
複数の議案群に含まれていてもよい。議案群の構成は、提案者の
意見を参考にしながら管理人が決定/変更する。

こんな感じでどうでしょう。これに、テキストファイルで実現するのは難しいか
なと思いますけど、CFD－議案群－議案の包含関係を示すベン図を添付するとわか
りやすくなります。AA エディタの類を使って描いてみようかしら。

> CFA(call for approval)では、議案群の1つを選択し、一定期間内に異
> 義が出なければその議案群が成立する。異義が出た場合はCFDは継続す
> る。CFAは一人が管理者となり、広報および異義の受け付けを行う。
>
> CFR(call for rejection)では、一定期間内に異義が出なければすべて
> の議案群が不成立となる。異義が出た場合はCFDは継続する。CFRは一人
> が管理者となり、広報および異義の受け付けを行う。

s/異義/異議/g ですね。

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

───【宣伝/ADVERTISEMENT】──────────────────────
fj.os.ms-windows.server2003 または fj.os.ms-windows.server の新設の可否
を問う投票を実施中です。
fj.news.group.comp をご参照のうえ、ふるってご投票ください。
投票期限は 8/25(月)です。
────────────────────────────────────

[IIJIMA Hiromitsu]

いいじまです。

> ngMP v8 で、具体的に、次の問題をどう扱うのですか。
>
> fj.net.watch
> fj.news.from.misc
> fj.news.from.2ch
> fj.news.from.blog
> fj.news.from.slashdot
>
> 同じCFDですか、違うCFDですか。v5 では、同じ CFD です。
> 現行NGMPでは、今回管理人は、同じ CFD という判断しています。

管理人の裁量でどちらにもできると考えます。

まずは、単一の CFD に属するとすれば、次のような最大16個の議案群に分割で
きます。(watch) と 2^(misc+2ch+blog+slashdot)-φ の 16 件です。

watchのみ
miscのみ
misc+2ch
misc+blog
misc+slashdot
misc+2ch+blog
misc+2ch+slashdot
misc+blog+slashdot
misc+2ch+blog+slashdot
2chのみ
2ch+blog
2ch+shashdot
2ch+blog+slashdot
blogのみ
blog+slashdot
slashdotのみ

議案の数が増えると指数関数的に議案群の候補が増えるのが難点ですが、再帰の
ような「計算機屋の知識が必要な記述法」を避けることにすると、やむを得ない
でしょう。

あとは、

1.アンケートで絞ることができます。
2.提案者の意向で絞る（たとえば、misc と 2ch のどちらも含まない 3 群は新
　城さんの意志で除外）ことができます。
3.blog と slashdot を別 CFD に分割して misc/2ch の結果待ちにする（fj.net.
　watch が成立したら fj.net.watch.slashdot 等の新設提案に切り替える）

といった運用が可能です。

もしくは、別の CFD とした上で、後発の fj.news.from.* の CFD は先発の
fj.net.watch の結果に依存するから結論が出るまで延期、ともできます。
これは担当管理人の裁量です。

重要なのは、この裁量を下すのは管理人であって提案者にはその裁量権がなく、
必要があれば最初の提案者の意志に反して議案を追加させることができる（もち
ろん、同時に投票にかけさせることもできる）ということです。

必要ならばさらに、

管理人は必要と認めた時は自ら提案者となり議案を提出できる。

というところに、

管理人が提案者となった場合に、他に提案者があるときは、

案１：当該提案者との衡平を期するため、他の管理人に CFD を管理
　　　させるように努めるものとする。
案２：当該提案者は、委員会に対して、議案提案者でない者に CFD を
　　　管理させるよう請求できる。この請求に理由は要しない。

といった追加条項を加えればいいでしょう。

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

y...@is.tsukuba.ac.jpさん:

> ngMP v8 で、具体的に、次の問題をどう扱うのですか。

> 同じCFDですか、違うCFDですか。v5 では、同じ CFD です。

はい、管理人が同じと判断すれば同じCFDです。

> 現行NGMPでは、今回管理人は、同じ CFD という判断しています。

はい。ですから同じCFDですね。

> > CFDは1つ、CFXも1つ、その中で対立する議案群Aと議案群Bの決着をつけ
> > る。議案群は「議案の集合」ですからそういうことが自由にできるでしょ?

> CFDは1つだけど CFX は、最低２つ必要だと思います。v5 でもそう

下記参照。

> です。というのも、現行NGMPでは、fj.net.watch の提案者が、
> fj.news.from.{2ch,blog,slashdot} を同じCFX に入れることを拒
> 否しました。v5 では、これを同時に投票することを認めようとし
> ています。

はい、同時に投票したいですね。そのために我々が今努力してるんで
しょ。私がv6でこの件の管理をするのであれば、その議案を

{ fj.net.watch }
{ fj.news.from.misc, fj.news.from.2ch, fj.news.from.blog,
fj.news.from.slashdot }

という2つの議案群にまとめ、複数選択CFVかCFSとします。どちらかの
議案群が成立すればそのグループ(群)がまとめてできます。どっちも反
対という票が多数ならどちらもできません。

まさにそのために議案群というのを入れたのですが、新城さんにすら
読みとってもらえないのではかなり先行き暗そうです。

かといって「依存」「対立」は私がよくわからん。 久野

[Yasushi Shinjo]

新城です。

In article <bhqoj9$2v...@utogw.gssm.otsuka.tsukuba.ac.jp>
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> 久野です。

> はい、同時に投票したいですね。そのために我々が今努力してるんで
> しょ。私がv6でこの件の管理をするのであれば、その議案を
>
> { fj.net.watch }
> { fj.news.from.misc, fj.news.from.2ch, fj.news.from.blog,
> fj.news.from.slashdot }
>
> という2つの議案群にまとめ、複数選択CFVかCFSとします。どちらかの
> 議案群が成立すればそのグループ(群)がまとめてできます。どっちも反
> 対という票が多数ならどちらもできません。

同じ CFD にして同時に投票にかけられるは、私には読めませんで
した。議案群とCFDの関係で、CFXで CFD期間が終ってしまうので。

> かといって「依存」「対立」は私がよくわからん。 久野

依存は、簡単です。Makefile で、書くようなものです。

issue1: fj.net.watch or fj.news.from.misc
issue2: fj.news.from.2ch
issue3: fj.news.from.blog
issue4: fj.news.from.slashdot

私がやりたいのは、次の並列 make です。
make issue1 1issue2 issue3 issue4

issue2-4 を先に決まったとしても、issue1 でfj.news.from.misc
かこけたら、undo してこけさせます。

> かといって「依存」「対立」は私がよくわからん。

対立は、上の Makefile で or と書いてある所。排他的な案といっ
てもいいです。２つしかなければ、Exclusive OR。

こういうスケジューリングが、v8 でできるなら、ＯＫです。

商取引はこんな感じです。買うか買わないかは最後に決めます。途
中は値段とか数とか納期とかでいろいろネゴシエーションして、最
後にＯＫでもいいし、また今度でもいいし。

[IIJIMA Hiromitsu]

いいじま％自己流で断眠療法実行中、です。

流れが読めていないので間違っていたらごめんなさい、というのと、あと、
かなり長文なのもご容赦ください。

ポイントごとに番号振ります。

１．今までの流れ

まず今までの流れを整理すると、

○現行 NGMP では、単一の提案者が CFD を取り仕切ることになるので、その
　CFD を廃案に追い込んでからでなければ対案を出せない

　→これは、今後は管理人が仕切るということで合意をみたと考えます。
　　つまり、fj.net.watch の一件だと、当初案の提案者である久野さんが
　　新城さんの案の一部に難色を示しても、担当管理人・河野さんの裁量で
　　CFV の選択肢に含めさせることができたことになります。

○依存関係にある2つの議案（たとえば、fj.editor.*→fj.comp.editor.* の
　一括改名議案と、fj.(comp.)editor.hidemaru の新設議案）について、前者の
　結論が出なければ後者の前提条件が確定しない場合に、早い時期に後者だけ
　可決させたい場合の取り扱いをどうするか

　→これを久野さんは「CFD-議案群-議案」という 3 層構造の導入と「一括採決」
　　という方法で、新城さんは「依存」の概念の導入と「遡及決定」という方法
　　で、それぞれ解決しようとしている

　○相矛盾する議案が出たときの取り扱い

　→久野さんは「議案群を構成する際に同一の議案群に相矛盾する議案は入れな
　　いようにする」としており、一方で、新城さんは「相矛盾する案を両方とも
　　議上に載せたままにしておいて、一方が成立すれば他方は自動的に落ちる」
　　としている

これで間違いないでしょうか。

☆

２．私の意見

で、私の意見ですが、先述の通り、

久野さん:

> 計算機屋でない人に読めないNGMPになりそうだから
> そういうものを入れるのは我慢して欲しいです。再帰とかも。まずは
> 「平に」記述して、

という意見に全面的に同意します。Makefile のような文法を持ち出してこなけ
れば記述できない NGMP には反対です。

で、久野案には納得できましたから、それに賛成です。あとは細かい文言に注文
をつけたいところはありますけど、それは v9、v10 が出てからにします。

☆

３．make に喩えることには反対

> 依存は、簡単です。Makefile で、書くようなものです。

と、おっしゃいますが、make に喩えるのはおかしいのでは。make コマンドの
文法って、基本的に並列処理ではなく直列処理で、並列化できるのはそれぞれに
依存関係がない場合、と認識しています。たとえば、make build と make install
を並列化しようとしても、make install のほうは通常は make build の結果待ち
だし、仮に並列化できたとしても、make build が失敗したときのための make
uninstall はよほど丁寧に書かないと面倒なことになります。

依存関係があっても並列化できる make もあるのかもしれませんが、一般の UNIX
ユーザーにはなじみがありませんし、そもそも Makefile の読み書きをしない人
のほうが今や多くなった（UNIX 界でも、rpm しかインストールしないとか、
Makefile は読み書きするけど Ports collection のオブラートにくるまったもの
しか相手にしないとか、そういう人のほうが多い） fj の参加者に対して、Makefile
の文法を用いて解説しなければいけないのは間違っていると思います。

☆

４．fj.net.watch vs fj.news.from.misc での新城案の問題点

そして、例として挙げられた、

> issue1: fj.net.watch or fj.news.from.misc
> issue2: fj.news.from.2ch
> issue3: fj.news.from.blog
> issue4: fj.news.from.slashdot
>
> 私がやりたいのは、次の並列 make です。
> make issue1 1issue2 issue3 issue4
>
> issue2-4 を先に決まったとしても、issue1 でfj.news.from.misc
> かこけたら、undo してこけさせます。

という例は、そのままでは新城さんの方式では問題ありと考えます。これだと、
先に issues2-4 が fj.news.from.* という仮グループ名で一つでも可決されれば、
issue1 についても fj.news.from.misc に票が流れるでしょう。

あるいは、fj.net.watch.2ch や fj.net.watch.slashdot という名前がいい、
という意見が出て、CFD にその議案が追加されることもあるでしょう。とすると、

issue2: fj.news.from.2ch or fj.net.watch.2ch
issue3: fj.news.from.blog or fj.net.watch.blog
issue4: fj.news.from.slashdot or fj.net.watch.slashdot

となり、今度は、たとえば issue2 については

a)issue1 の結果に応じてどちらかの名前で必ず作る、issue1 が否決されたら
　別途名前を決める
b)issue1 の結果がどちらかを作ることになったらそれに応じた名前で作る、
　どちらも作らないことになったら作らない
c)issue1 の結果に関係なく、どちらも作らない

の 3 択になります。つまり、表面上は「どちらの名前にするかの 2 択＋廃案の
計 3 択」に見えて、表記上もそうなっているにも関わらず、実際には「名前は
実は a) 以外では関係なく、issue1 の結果をどう issue2 に反映させるのかに
よる 2 択＋無条件廃案の計 3 択」になるわけです。

こういう「熟慮に熟慮を重ねても見落としが出かねない論理構造」は好ましく
ないと考えます。そして往々にして、見落とし対策で全検索をすると組合せ爆発
します。

また、もし「どちらの名前にするかの 2 択＋廃案の計 3 択」で 3 つまとめて
投票をして矛盾する結果が出たら、その投票はすべて無駄で、結局は issue1
の投票に持ち込まれることになりますので、投票管理者にとって非常なコストに
なります。

そして、どうせ全検索で組合せ爆発するのであれば、久野案の「議案群」という
概念でそれを明示的に表現してしまって、場合によっては「じゃあ爆発するから
複数の CFD に分割しよう」としたほうがいいと思うのですよ。

５．可能性をすべて書き出してみると新城案の問題点がわかる

今回の場合、可能な組合せをぜんぶ書き出すと、

[略号 w=fj.net.watch、f=fj.news.from.*、m=misc、2=2ch、b=blog、s=slashdot]

[前提:両立しない組合せ]
w* と f* の任意の組合せ
w と wm の両方を作る案

[全廃案という議案群…1件]
φ

[1グループ作成という議案群…7件]
w
w2 ←こういう 6 案も選択肢に入ることに注意。
wb
ws
f2
fb
fs

※「wmだけ」「fmだけ」という議案群は候補から外れると考えます。
　他に何もないのに misc＝「その他」があるのはおかしい。

[2グループ作成という議案群…12件]
w+w2
w+wb
w+ws
wm+w2
wm+wb
wm+ws
fm+f2
fm+fb
fm+fs
f2+fb ←この最後の3つ注意
f2+fs
fb+fs

[3グループ作成という議案群…10件]
w+w2+wb
w+w2+ws
w+wb+ws
wm+w2+wb
wm+w2+ws
wm+wb+ws
fm+f2+fb
fm+f2+fs
fm+fb+fs
f2+fb+fs　←これ注意

[4グループ作成という議案群…3件]
w+w2+wb+ws
wm+w2+wb+ws
fm+f2+fb+fs

の33通りとなりますが、新城さんの方式では、議案の構成の仕方によって、最後
の最後になってみないと、その33通りのどれにでも転ぶ可能性があります。結果
として、議論参加者の望まない構成で CFD が成立してしまう可能性があります。

また、不用意に議事を進めると、人間の目を通さずに、自動的に特定の選択肢を
落としてしまう可能性があります。たとえば、新城さんの記述では、「fm なし
で f2、fb、fs の 1 個以上を作る。fm が相当な記事は fj.misc 等を用いる」
という選択肢は最初から落ちています。

つまり、「到達しうる選択肢の一覧」がどこにも明記されないまま議論が進むこ
とになります。

また、せっかく投票してもその結果が上位の投票で覆されて無駄になる事態があ
りうるのは、新城さんも当然に認めているところですが、投票は 1 回だけでも
投票管理者にとって大きな負担になります。

私自身、いま投票の最中ですが、はじめての投票なので、私の予想外の投票がい
ろいろと来て「この票を有効票と見なして受理して、開票後に無効とされたら申
し訳ない」「けれども、こちらで不備と見なして出し直しを指示し、あとでそれ
は不備ではないとされて出し直しは二重投票、したがって両方とも無効票、とさ
れたらそれも困る」ということで、非常に神経をすり減らしています。

６．久野案でのこの案件の取り扱い

久野さんの案では、この33通りの選択肢（これを久野さんは議案群と呼んでいる
わけですが、選択肢と言い換えてもいいかもしれない）を可能ならすべて書き出
して、あるいは、全部で何通りあるかわからない中から各提案者が思いつくもの
だけをリストアップし、その中から、賛成者のいない案、非合理的な案（たとえ
ば w+wm のような相矛盾する案）を除外して選択肢の数を絞り込んだ上で、複数
選択投票にかけます。

今回の案件では、33案の中からφ、w、fm+f2+fb+fs の 3 案に絞り込んで投票に
かける、と久野さんは明言しています。それに対して、私なら投票予告の時点で
w+w2 を選択肢に入れるように管理人さん（＝久野さん）に要望するでしょう。

７．では、前述の fj.editor.hidemaru の例ではどうなるか

この例では、久野さんの案では、
○何も変更しない
○fj.editor.hidemaru を作成する。
　fj.editor.* → fj.comp.editor.* の移動は行わない。
○fj.editor.* → fj.comp.editor.* の移動を行う。
　fj.comp.editor.hidemaru は作らない。
○fj.editor.* → fj.comp.editor.* の移動を行い、
　fj.comp.editor.hidemaru を作る。
の４択での一括投票になります。

新城さんの案は、fj.(comp.)editor.hidemaru を作るかどうかを先に決めて
fj.editor.* → fj.comp.editor.* の可否はあとで決めることを可能にしよう、
その手段として、まず最初は「fj.editor.hidemaru 新設」という議案を通して
おいて、fj.editor.* → fj.comp.editor.* が可決されたらその時点で遡って
fj.comp.editor.hidemaru 新設議案が通ったものと見なす、ということになり
ますよね。

…でも、議論が長引いたとすると、fj.editor.hidemaru 新設のコントロールメ
ッセージを流したあとに、fj.editor.hidemaru 廃止・fj.comp.editor.hidemaru
新設のコントロールメッセージを流す可能性が高くなります。昨今の、各プロバ
イダのニュースサーバーの管理状況が決してよくない状況の中で、それでよろし
いのでしょうか？＞＞新城さん

とすると、fj.(comp.)editor.hidemaru に関するコントロールメッセージは新設
一発で済ませたいところですので、その意味でも、「一括採決」を旨とする久野
さんの案が望ましいと考えます。

もっとも、このケースに限っていえば、この両者を別々の CFD として扱った上
で、「管理行為の実行」の節に「成立した CFD であっても、他の CFD の結果に
よってコントロールメッセージの出し直しが必要になる可能性があるときは、当
該 CFD が決着するまで管理行為の実施を延期できる」という規定を設けること
で解決できそうですが、それはそれでややこしくなりそう。

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

y...@is.tsukuba.ac.jpさん:

> > { fj.net.watch }
> > { fj.news.from.misc, fj.news.from.2ch, fj.news.from.blog,
> > fj.news.from.slashdot }
> >
> > という2つの議案群にまとめ、複数選択CFVかCFSとします。どちらかの
> > 議案群が成立すればそのグループ(群)がまとめてできます。どっちも反
> > 対という票が多数ならどちらもできません。

> 同じ CFD にして同時に投票にかけられるは、私には読めませんでし
> た。

まあその書き方は直すとして、そのようなもの(同じCFDで同時に投票
に掛けられる)であれば、新城さんとしては受け入れ可能かどうか、そ
こを伺わせてください。

> 議案群とCFDの関係で、CFXで CFD期間が終ってしまうので。

これも、同時に投票して同時に決着させる結果終る、というのは受け
入れられないですか?

> > かといって「依存」「対立」は私がよくわからん。 久野
>
> 依存は、簡単です。Makefile で、書くようなものです。

飯嶋さんもかかれていますがMakefileが例になるようなものはちょっ
となあと思います。またundoという概念が必要なのも。

このあたりもうすこし議論してからv9ですかね? 久野

> 対立は、上の Makefile で or と書いてある所。排他的な案といっ
> てもいいです。２つしかなければ、Exclusive OR。

P.S. 1つのCFDに含まれる複数の議案の間で依存と対立の関係に矛盾が
生じることはありますよね。AとBが依存、AとCが対立、BとCが依
存とか(複数の提案者が勝手に出すと当然起こり得ます)。その場
合はどうするのでしょう?

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

delm...@ht.sakura.ne.jpさん:

> 私自身、いま投票の最中ですが、はじめての投票なので、私の予想外の投票がい
> ろいろと来て「この票を有効票と見なして受理して、開票後に無効とされたら申
> し訳ない」「けれども、こちらで不備と見なして出し直しを指示し、あとでそれ
> は不備ではないとされて出し直しは二重投票、したがって両方とも無効票、とさ
> れたらそれも困る」ということで、非常に神経をすり減らしています。

この件は小改定として入れましょうか。不備があると考えて投票管理
者と投票者の間で出し直した場合は重複投票とはしないという感じの規
定。もっとも、飯嶋さんがこれこれの理由で不備と考えて再投票しても
らったものについて、管理人が異論をわざわざとなえることはなさそう
に思いますけどね。ご心配は分かりますよ。

> 久野さんの案では、この33通りの選択肢（これを久野さんは議案群と呼んでいる
> わけですが、選択肢と言い換えてもいいかもしれない）を可能ならすべて書き出
> して、あるいは、全部で何通りあるかわからない中から各提案者が思いつくもの
> だけをリストアップし、その中から、賛成者のいない案、非合理的な案（たとえ
> ば w+wm のような相矛盾する案）を除外して選択肢の数を絞り込んだ上で、複数
> 選択投票にかけます。
>
> 今回の案件では、33案の中からφ、w、fm+f2+fb+fs の 3 案に絞り込んで投票に
> かける、と久野さんは明言しています。それに対して、私なら投票予告の時点で
> w+w2 を選択肢に入れるように管理人さん（＝久野さん）に要望するでしょう。

当然、要望があれば入れるのにはやぶさかでないでしょうね。入れた
からといって手間が大変になるわけでもないですし。

つまり私の考えとしては、議案群(選択肢)を人間が検討して作る、足
りないなら人間が指摘して増やす、ということです。誰も指摘しない
(望まない)選択肢はできない、という性質は必要だと思います。

ようやく議論人数が3人になった… 久野

[IIJIMA Hiromitsu]

いいじま％仮眠完了、です。眠気覚ましの薬入れてまた頑張るか…

本質的ではないですが、見落としが :-)

> [2グループ作成という議案群…12件]
> w+w2
> w+wb
> w+ws
> wm+w2
> wm+wb
> wm+ws
> fm+f2
> fm+fb
> fm+fs
> f2+fb ←この最後の3つ注意
> f2+fs
> fb+fs

w2+wb
w2+ws
wb+ws
の3通りも選択肢に入ります。

> [3グループ作成という議案群…10件]
> w+w2+wb
> w+w2+ws
> w+wb+ws
> wm+w2+wb
> wm+w2+ws
> wm+wb+ws
> fm+f2+fb
> fm+f2+fs
> fm+fb+fs
> f2+fb+fs　←これ注意

これも w2+wb+ws が選択肢に入ります。

というわけで37通りでした。というわけで、投票のやり方とその結果によっては、
いま私が書き出すまでまでおそらく誰も予想しなかった

fj.net.watch.{2ch,blog,slashdot} を作るけど、
fj.net.watch ないし fj.net.watch.misc は作らない

という選択肢が成立することになるわけで、再掲になりますが、奇しくも

> 新城さんの方式では、議案の構成の仕方によって、最後
> の最後になってみないと、その33通りのどれにでも転ぶ可能性があります。結果
> として、議論参加者の望まない構成で CFD が成立してしまう可能性があります。

ということの実例を示してしまった形になります。（s/33/37/、以下同様）

> 今回の案件では、33案の中からφ、w、fm+f2+fb+fs の 3 案に絞り込んで投票に
> かける、と久野さんは明言しています。それに対して、私なら投票予告の時点で
> w+w2 を選択肢に入れるように管理人さん（＝久野さん）に要望するでしょう。

これもすこし忘れてました。fm+f2+fb+fs が大勢ならば、当然、「fj.new.from.*
方式でいいけど、blog と slashdot は要らない」として fm+f2 の追加も要望す
ることになるでしょう。

[IIJIMA Hiromitsu]

いいじまです。

> P.S. 1つのCFDに含まれる複数の議案の間で依存と対立の関係に矛盾が
> 生じることはありますよね。AとBが依存、AとCが対立、BとCが依
> 存とか(複数の提案者が勝手に出すと当然起こり得ます)。その場
> 合はどうするのでしょう?

うう、イメージがわかない…すいません久野さん（あるいは新城さんでも）、
具体例を出していただけませんか？
こういうふうに議案が出ると矛盾になる、という。

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

> 私:
> > うう、イメージがわかない…すいません久野さん（あるいは新城さん
> > でも）、具体例を出していただけませんか？こういうふうに議案が出
> > ると矛盾になる、という。

すいません、「私:」じゃなく「飯嶋さん:」でした～ 久野

[ku...@gssm.otsuka.tsukuba.ac.jp]

私:
> うう、イメージがわかない…すいません久野さん（あるいは新城さん
> でも）、具体例を出していただけませんか？こういうふうに議案が出
> ると矛盾になる、という。

たとえばAさんが「fj.net.watchを作る」という議案を出します。

そこでBさんが「fj.net.watchを作るのであれば、併せてそこにおけ
る議論のスタイルについて議論する場であるfj.net.styleを作るべきだ」
と考え、「fj.net.watchに依存する提案fj.net.style」の議案を出します。

ところがAさんは「watchはそもそもstyleに包含されるものだから両
方作るのは絶対におかしい」という強固な信念のもとに「fj.net.style
に対立する提案としてのfj.net.watch」を出し直します。

はいおめでとー、YはXに依存しXはYに対立します。 久野

[Yasushi Shinjo]

新城＠筑波大学情報です。こんにちは。

In article <bhrr6s$b...@utogw.gssm.otsuka.tsukuba.ac.jp>

ku...@gssm.otsuka.tsukuba.ac.jp writes:
> > 同じ CFD にして同時に投票にかけられるは、私には読めませんでし
> > た。
> まあその書き方は直すとして、そのようなもの(同じCFDで同時に投票
> に掛けられる)であれば、新城さんとしては受け入れ可能かどうか、そ
> こを伺わせてください。

ネットワーク・ニュースの議論なので、新城個人に聞かれても困り
ます。他の人の意見も聞いて下さい。

私の意見は、そういうスケジューリングが「可能」で、かつ、別の
スケジューリングも可能であるような柔軟性があるものならＯＫです。
「必ず同時」は、不可です。

> > 議案群とCFDの関係で、CFXで CFD期間が終ってしまうので。
> これも、同時に投票して同時に決着させる結果終る、というのは受け
> 入れられないですか?

これも、必ず同時は、不可です。同時も可能、別の順番でも可能と
いう柔軟性があるものならＯＫです。

> 飯嶋さんもかかれていますがMakefileが例になるようなものはちょっ
> となあと思います。またundoという概念が必要なのも。

undo ではなくて、「仮成立」でもいいです。v4 は、そうでした。
成功するか失敗するかわからないけれど、とにかく先に進めてそれ
なりの結論を出してみるというのが、楽観的／投機的なスケジュー
リングです。

> P.S. 1つのCFDに含まれる複数の議案の間で依存と対立の関係に矛盾が
> 生じることはありますよね。AとBが依存、AとCが対立、BとCが依
> 存とか(複数の提案者が勝手に出すと当然起こり得ます)。その場
> 合はどうするのでしょう?

はい。矛盾がおきないような結果を１つ選ぶために、どれかの議案
を不成立にします。v4 なら、投票にかけて、投票の yes 得票の多
いものを優先させて成立させます。そして、それに矛盾するものは、
不成立にして矛盾を防ぎます。

たとえば、A が yes 100 票 no 90 票、B が yes 50 票 no 40票、
C が yes 10 票、no 9 票だとします。全部の案が yes > no になっ
ています。この中では、A の得票が多いので、まず ず A を成立さ
せます。C は、A と対立していたので、不成立にします。B ですが、
B が C に依存していたら、これも不成立にします。逆に C が B
に依存していたら、B は成立させます。

簡単ですよね。

トランザクション処理なら、最終的に「逐次化可能(serializable)」
という厳しい制約のもので、複数の処理を並行して実施します。逐
次化可能は厳しすぎるので、ngMP ではそれは要求しなくてもいい
でしょう。

Makefile の例は、別に分かりやすい人もいるだろうということで
出したのであって、今の案は別に Makefile に依存しているわけで
もなんでもありません。Makefile が分からない人は、別の層の概
念で理解してもらえばいいので、大丈夫です。

make の例をもう少しすると、もともと make には、逐次的にやる
という意味はすくなくて、複数の処理を並列にやってもいい所もあ
ります。これを本当に並列にやるものが並列make。Sequent
Balance に入っていたのが最初だと思いますが、今は、GNU にもそ
の機能はあります。-j オプションのあるものです。

並列 make の次に出てきたものが、楽観的makeと投機的make。make
と言われる前に、別の世界で先に処理を進めて、make と言われた
ときには、即座にその結果を出すというものです。先に進めた処理
は、ユーザがファイルを修正したりした無駄になります。だけど成
功した時には速いし、そもそもＣＰＵが遊んでいたら無駄にはなり
ません。

投機的makeについては、次の論文を見てください。

根路銘, 當城, 新城, 溝淵, 喜屋武, 翁長: "世界のDAG を利用し
た投機的make の実現", 情報処理学会研究会報告95-OS-70-4,
Vol.95, No.70, pp.25-32 (1995年8月).

http://www.ipsj.or.jp/members/SIGNotes/Jpn/07/1995/070/article004.html

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

y...@is.tsukuba.ac.jpさん:

> ネットワーク・ニュースの議論なので、新城個人に聞かれても困り
> ます。他の人の意見も聞いて下さい。

もちろん聞きますとも。ただ新城さんと私で意見の隔たりが大きい
ことが多いので、我々で合意可能なら大体の人はその間に入るような
気もしてます。

> 私の意見は、そういうスケジューリングが「可能」で、かつ、別の
> スケジューリングも可能であるような柔軟性があるものならＯＫです。
> 「必ず同時」は、不可です。

そうですか、その「同時でない」場合はCFDを分けることによって
実現される、というのではダメですかね?

> > > 議案群とCFDの関係で、CFXで CFD期間が終ってしまうので。
> > これも、同時に投票して同時に決着させる結果終る、というのは受け
> > 入れられないですか?
>
> これも、必ず同時は、不可です。同時も可能、別の順番でも可能と
> いう柔軟性があるものならＯＫです。

この「同時でない」はCFDを分けることによって実現される、という
のはダメですかね?

もし上記2つともダメだとすると、今回の私の案(議案群の中から1つ
を選んで選択)は新城さんに受け入れて頂く余地がないものと判断され
ます。私としては「1つのCFD内では同時に(atomicに)決着」というのが
シンプルで分かりやすい、多少不自由だとしても計算機屋でない人まで
含めて受け入れてもらうにはこれくらいでないと無理だろう」と考えて
いました。大変残念です。

> > 飯嶋さんもかかれていますがMakefileが例になるようなものはちょっ
> > となあと思います。またundoという概念が必要なのも。

> undo ではなくて、「仮成立」でもいいです。v4 は、そうでした。
> 成功するか失敗するかわからないけれど、とにかく先に進めてそれ
> なりの結論を出してみるというのが、楽観的／投機的なスケジュー
> リングです。

じゃあ仮成立ということで考えて見ましょうか。仮成立が確定するた
めには「異義が出ず2週間」が必要なんでしたっけ。一番心配なのは仮
成立とその異義が続いていつまでも結果が出ないこととかですが、その
あたりはどうですか。

> > P.S. 1つのCFDに含まれる複数の議案の間で依存と対立の関係に矛盾が
> > 生じることはありますよね。AとBが依存、AとCが対立、BとCが依
> > 存とか(複数の提案者が勝手に出すと当然起こり得ます)。その場
> > 合はどうするのでしょう?

> はい。矛盾がおきないような結果を１つ選ぶために、どれかの議案
> を不成立にします。v4 なら、投票にかけて、投票の yes 得票の多
> いものを優先させて成立させます。そして、それに矛盾するものは、
> 不成立にして矛盾を防ぎます。

> たとえば、A が yes 100 票 no 90 票、B が yes 50 票 no 40票、
> C が yes 10 票、no 9 票だとします。全部の案が yes > no になっ
> ています。この中では、A の得票が多いので、まず ず A を成立さ
> せます。C は、A と対立していたので、不成立にします。B ですが、
> B が C に依存していたら、これも不成立にします。逆に C が B
> に依存していたら、B は成立させます。

> 簡単ですよね。

簡単じゃないと感じますがこればっかりは思う思わないなのでどうに
もしょうがないです。

> トランザクション処理なら、最終的に「逐次化可能(serializable)」
> という厳しい制約のもので、複数の処理を並行して実施します。逐
> 次化可能は厳しすぎるので、ngMP ではそれは要求しなくてもいい
> でしょう。

逐次化可能にしないと矛盾が生じることはないの。 久野

P.S. どっちにしても計算機屋の概念をはなれた一般に通用する例で喋っ
てください。お願いですから。

[IIJIMA Hiromitsu]

いいじまです。

１日考えてみて、新城さんの考えているものが見えてきたように思います。

新城さんの今までのところのスタンスは、「NGMP と CFD で適切なルールセットを
書き下せば、あとはごく少数のパラメータ（具体的には、それぞれの投票の票数）
を与えるだけでそのルールセットに従って機械的に、論理的整合性のある結論が
導かれる」と読みました。

でも、すべて前回の投稿の繰り返しになるのですが、私は、
○ルールセットを過不足なく書き下す能力がある人はごく限られてしまう
○ルールセットだけからは結果の見通しがつけにくく、また、ルールセッ
　トに穴がないという保証がつけにくいので、ルールセットから機械的に
　結論を導く手法は危険である
という理由で、反対です。

特に、適切なルールセットだと思って書き下してみたものに実は穴があった、と
いう場合はどうなりますか？　そもそも最初にルールセットを書き下す段階で、
各議案の依存・対立関係や状態遷移図は組合せ爆発を起こします。現に、fj.net.
watch.* vs fj.news.from.* では、net.watch vs news.from という「1 つの対立
軸」と、2ch・blog・slashdot・misc という「4 本の下位問題」だけを与えて可
能な組合せを探ったら、37 通りの選択肢が出てきました。対立軸と下位問題の
総数がせいぜい3 つ程度の簡単なルールセットならまだいいのですが、合計で
5 個程度を超えると、ルールセットを書き下す段階では、穴がないことを検証
するのは困難でしょう。

それともうひとつ、新城さんから見解表明をいただいていないのですが、「一見
したところの対立軸と実際のルールセットとが一致しないことがあり、その場合
に実際のルールセットが見えにくい」という問題はどうしますか？

たとえば、
fj.net.watch.2ch vs fj.news.from.2ch vs 廃案
という下位問題で、「fj.net.watch.2ch を作る」という結論が出たとします。

この下位問題は
fj.net.watch vs fj.news.from.misc vs 廃案
という上位の議案に依存しているわけですが、このとき、
fj.net.watch を作ることに決定→fj.net.watch.2ch ができる
fj.news.from.misc を作ることに決定→fj.news.from.2ch ができる
廃案に決定→この下位問題は「fj.net.watch.2ch を作る vs 作らない」
　　　　　　という下位問題に変質し、再度の議決を要する状態に戻る
となります。つまり、この下位問題は、実は上記のような対立関係にはなく、
○上位の議案がどちらかを作ることに決したときに限り、fj.X.2ch を作る
○上位案が可決なら fj.X.2ch を作り、廃案なら fj.net.watch.2ch を作る
○上位案が可決なら fj.X.2ch を作り、廃案なら fj.news.from.2ch を作る
○作らない
という 4 択の exclusive OR の関係にあるわけです。この 4 択で投票に付すと、
「fj.net.watch.2ch なら賛成だけど、fj.news.from.2ch なら反対」という人が
困ります。NGMP で禁止されている「条件つき投票」をしたいという人があらわれ
るでしょうし、そうなると、投票管理者が注意喚起しなければ現実に混乱が起こ
る懸念があります。

> > まあその書き方は直すとして、そのようなもの(同じCFDで同時に投票
> > に掛けられる)であれば、新城さんとしては受け入れ可能かどうか、そ
> > こを伺わせてください。

...

> 私の意見は、そういうスケジューリングが「可能」で、かつ、別の
> スケジューリングも可能であるような柔軟性があるものならＯＫです。
> 「必ず同時」は、不可です。

う～ん、そういう柔軟性を持たせるとルールセットや議案間の状態遷移図が複雑
になりすぎませんか？

> undo ではなくて、「仮成立」でもいいです。

いや、仮成立と言い換えてみても、「何を仮成立させるのか」「どういう条件の
もとで本成立になり、どういう条件の下で廃案になるのか」が、議決（CFX）前
に明確になっていないとマズいです。

> たとえば、A が yes 100 票 no 90 票、B が yes 50 票 no 40票、
> C が yes 10 票、no 9 票だとします。全部の案が yes > no になっ
> ています。この中では、A の得票が多いので、まず ず A を成立さ
> せます。C は、A と対立していたので、不成立にします。B ですが、
> B が C に依存していたら、これも不成立にします。逆に C が B
> に依存していたら、B は成立させます。
>
> 簡単ですよね。

ええ、この場合は確かに簡単です、私や、久野さんや、新城さんにとっては。

でも、それは計算機科学というか、数理系論理の素養があるから「簡単」と言い
切れるのであって、計算機屋でない一般の fj 参加者にとっては複雑怪奇なもの
です。そういう人は参加する資格がない、などというのであれば、河野さんの
言葉を借りて「新城さんのような論法が fj を滅ぼしてい」くのだと私は断言
します。

それから、「ある案が得票最上位になって可決させることになったら、どの組合
せをとっても論理的に不整合になる」という事態に陥ったらどうしますか？　投
票開始前に判明していればその案を排除すれば済みますが、すでにその案を含め
て投票に付してしまった場合や、投票終了後の検証になってはじめて判明した場
合は？

具体例が私には思い浮かばないのですが、それは理論的にそういう事態が存在し
得ないという証明ができる代物なのでしょうか、それとも単に私には思い浮かば
ないだけで現実には存在しうるのでしょうか？

☆

そもそも、「投機的」「楽観的」という、一部の専門家にしか理解できないキー
ワードを持ち出したり、それに関する専門雑誌への投稿記事を持ち出したりする
時点で、計算機屋でない一般の参加者を軽視、もっといえば無視しているといわ
ざるを得ません。

これらの用語の正確な意味を理解しようという気力は今の私にはないのですが、
「投機」という用語は、見通しが外れた場合には何らかのペナルティがあるとい
うことを意味するはずで、それをするからには、最悪の場合にどんなペナルティ
があるのか、そのペナルティは受入可能なのかの事前見積もりが必要です。

「投機的 make」なるものが今の時代に成り立つのは、あてが外れた場合のペナル
ティが「CPU 時間の浪費」「ディスクスペースの少々の浪費」「ハードウェア
（ハードディスクなど）の寿命の少々の短縮」だけであって、どれも今の時代の
計算機環境では無視できるほど小さいからでしょう。仮に、CPU 時間に対する従
量課金がシビアに行われているとしたら、「投機的 make」なるものの導入には
躊躇が伴うでしょう。

NGMP に「投機的」なるものを持ち出すことのペナルティの無視できない例のひ
とつが、fj.net.watch vs fj.news.from.misc がどちらも廃案になった場合に、
いったん議決の手続きをとって仮成立させた fj.X.2ch の取り扱いについて成案
か廃案かの再議決が必要になる例です。しかもこの例では CFA/CFR が通る見込
みが少ないので、再度 CFV/CFS という可能性が非常に高くなります。

[Yasushi Shinjo]

In article <bht55b$u...@utogw.gssm.otsuka.tsukuba.ac.jp>
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> 久野です。

> > 私の意見は、そういうスケジューリングが「可能」で、かつ、別の
> > スケジューリングも可能であるような柔軟性があるものならＯＫです。
> > 「必ず同時」は、不可です。
> そうですか、その「同時でない」場合はCFDを分けることによって
> 実現される、というのではダメですかね?

えっと、私は、「CFD」の定義には、あまりこだわっていません。
こだわっているのは、個々の議案の審議を並行にできるかどうかです。

別の CFD として独立させてしまってもいいですが、この場合は次
のような問題点が出てきます。ある意味で「関連」しているのに、
同時に投票をする時の縛りが効かなくなります。たとえば、
fj.net.watch, fj.news.from.misc, fj.news.from.2ch,
fj.news.from.blog, fj.news.from.slashdotは関連しているので、
１度に投票して決着をつけるということでができなくなります。

> > > > 議案群とCFDの関係で、CFXで CFD期間が終ってしまうので。
> > > これも、同時に投票して同時に決着させる結果終る、というのは受け
> > > 入れられないですか?
> >
> > これも、必ず同時は、不可です。同時も可能、別の順番でも可能と
> > いう柔軟性があるものならＯＫです。
>
> この「同時でない」はCFDを分けることによって実現される、という
> のはダメですかね?

これも、同じです。fj.net.watch, fj.news.from.misc,
fj.news.from.2ch, fj.news.from.blog, fj.news.from.slashdotは
「関連している」ので、同じCFD期間で審議したいと思った時にし
ばりが入れられるかです。別CFDで、１つ１つ逐次的に扱いうしか
ないというのでは、現行NGMPと同じです。

In article <bhll3s$u...@utogw.gssm.otsuka.tsukuba.ac.jp>
ku...@gssm.otsuka.tsukuba.ac.jp writes:

> NGMP改定案(新城・久野版) v8

> 3.4 CFD
> 類似した議案を一括して審議することをCFD(Call for Discussion) と
> 呼ぶ。CFDは管理人が管理するが、CFDに含まれる合意確認(CFX、後述)
> は管理人または提案者が管理する。

「類似した議案」というのは、新城が書いたものを引きずっている
わけですが、新城もアイディアも引きずるとすると、この定義のま
まで、

In article <bht55b$u...@utogw.gssm.otsuka.tsukuba.ac.jp>

ku...@gssm.otsuka.tsukuba.ac.jp writes:
> そうですか、その「同時でない」場合はCFDを分けることによって
> 実現される、というのではダメですかね?

と言われても、ちょっとね。「同時」かどうかでCFDを定義し直す
んですかね。でも、それだとCFDをないがしろにしている気もする
し。まあ、私は CFD の定義にはこだわらないのでいいけど。こだ
わるのは、「関連している具体的な案が同時並行的」に審議できる
かどうかです。

> 3.5 議案群(IG)
> CFDに属する議案は最終的に成立/不成立のいずれかとなる。議案が成立
> するのは、その議案を含む議案群が成立した場合に限られる。

この「議案群」の違いが、今一つ不明です。

私は、「CFD」とか「議案群」のような複数の「議案」の集まりを
中心に考えるよりは、個々の「議案」に着目した方がわかりやすい
と思います。個々の議案は、最終的に成立するか不成立になる。んー、
なんて、わかりやすいんでしょう。

ngMP v7:
------------------------------------------------------------
提出 承認開始 可決
[初期] ----> [審議中] ---------> [承認中] ----> [[成立]]
| |
| | 否決
| v
+------------> [[不成立]]
応答なし、
取下、満了
------------------------------------------------------------
この状態遷移も、わかりやすい。

いろいろな案がでてもめていた時、成立するものは、一番 yes を
たくさん集めた「議案」です。これも、わかりやすい。

議案群とか「CFD(久野)」とか、そういう概念がなくても、「議案」
だけで十分という話はあります。新城が入れたかったのは、グルー
プとしての「CFD」ではなくて、「CFD期間」という時間的な縛りだ
けです。グループとしての「CFD」はなくても平気です。上の例で
いうと、fj.net.watch, fj.news.from.misc, fj.news.from.2ch,
fj.news.from.blog, fj.news.from.slashdotは、提出されてたのが
数日ずれていたとしても、「CFD期間」は同時に終るということで
す。これも、わかりやすい。

CFD という用語自体、一般用語ではないわけで、これから fj に入っ
てくる人には意味不明な用語です。この際、これも分かりやすいも
のに替えたらいいんじゃないでしょうか。

まとめると、こんな感じです。

・CFDの定義にはこだわらない
・個々の案に着目した時に「関連している」議案を、同時並行的に
審議して、同時に投票にかけて、同時に決着がつけられるように
たい。
・個々の議案の動作は、グループよりもわかりやすい。
・「CFD」という用語は分かりにくい。

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

y...@is.tsukuba.ac.jpさん:

> > そうですか、その「同時でない」場合はCFDを分けることによって
> > 実現される、というのではダメですかね?
>
> えっと、私は、「CFD」の定義には、あまりこだわっていません。
> こだわっているのは、個々の議案の審議を並行にできるかどうかです。

分かりました、それでしたらもう少し考えましょう。

> 別の CFD として独立させてしまってもいいですが、この場合は次
> のような問題点が出てきます。ある意味で「関連」しているのに、
> 同時に投票をする時の縛りが効かなくなります。たとえば、
> fj.net.watch, fj.news.from.misc, fj.news.from.2ch,
> fj.news.from.blog, fj.news.from.slashdotは関連しているので、
> １度に投票して決着をつけるということでができなくなります。

その「できない」がよく分からないのですが、私としては

1度に決着したいときは1つのCFDにし、別々に(ないし順番に)決着
したいときは別のCFDにする。議案のCFDの間の移動は管理人が判断
する。

という方針を提案しているつもりですが、それではまずいですかね?

> これも、同じです。

についても。

> > NGMP改定案(新城・久野版) v8
> > 3.4 CFD
> > 類似した議案を一括して審議することをCFD(Call for Discussion) と
> > 呼ぶ。CFDは管理人が管理するが、CFDに含まれる合意確認(CFX、後述)
> > は管理人または提案者が管理する。

> 「類似した議案」というのは、新城が書いたものを引きずっている
> わけですが、新城もアイディアも引きずるとすると、この定義のま
> まで、

はいはい。

> と言われても、ちょっとね。「同時」かどうかでCFDを定義し直す
> んですかね。でも、それだとCFDをないがしろにしている気もする
> し。まあ、私は CFD の定義にはこだわらないのでいいけど。こだ
> わるのは、「関連している具体的な案が同時並行的」に審議できる
> かどうかです。

ようやく分かりました、では「類似」を落して「同時に決着すべき
議案」とすればどうでしょうか。

> > 3.5 議案群(IG)
> > CFDに属する議案は最終的に成立/不成立のいずれかとなる。議案が成立
> > するのは、その議案を含む議案群が成立した場合に限られる。

> この「議案群」の違いが、今一つ不明です。

はいはい、明確化しましょう。で、何が不明なのかがまだ私には分か
らないので説明してくださいよ。たとえば

同時に成立することが相当であると管理人が判断した議案の集まり
を議案群と呼ぶ

とかそういう方がいいですか?

> 私は、「CFD」とか「議案群」のような複数の「議案」の集まりを
> 中心に考えるよりは、個々の「議案」に着目した方がわかりやすい
> と思います。個々の議案は、最終的に成立するか不成立になる。んー、
> なんて、わかりやすいんでしょう。

だからそこの「わかりやすい」「わかりにくい」に主観の相違があるん
ですよね。私も新城さんも自分が考えたものはわかりやすい :-) まあ、
どっちも自案を放棄してないんだから、しばらくの間それぞれ歩みよっ
てみたらいいんじゃないですか。

> いろいろな案がでてもめていた時、成立するものは、一番 yes を
> たくさん集めた「議案」です。これも、わかりやすい。

その原理自体はいいんですよ。それでもともとの話、現在のNGMPは1つ
の「議案」が1つの「CFD」だという想定があって、それじゃ不十分
(fj.net.watchとfj.news-from.*群の選択)ができないから今回の検討を
してるんでしょ。

新城さんの提案は1番yesを集めた「議案」が成立することによってそれ
と「依存」関係で結ばれたものも一緒に成立するわけじゃないですか。
だったら「一緒に成立するものはこれとこれ」ということを明示した上
で投票してもらわないとフェアじゃない、それなら「これとこれ」の
方を明示することから始めたいと私は思います。

> 議案群とか「CFD(久野)」とか、そういう概念がなくても、「議案」
> だけで十分という話はあります。

そういうわけで「個々の議案」だけでは十分じゃなくて少なくとも「依
存関係」はないと困るんですよね? 「依存」がなくてもいい?

> 新城が入れたかったのは、グループとしての「CFD」ではなくて、
> 「CFD期間」という時間的な縛りだけです。グループとしての「CFD」
> はなくても平気です。上の例でいうと、fj.net.watch,
> fj.news.from.misc, fj.news.from.2ch, fj.news.from.blog,
> fj.news.from.slashdotは、提出されてたのが数日ずれていたとして

> も、「CFD期間」は同時に終るということです。これも、わかりやす

> い。

新城さんがどっちでもいいなら、現在のNGMPからの移行を考えると
CFDに期間がついているという枠組みは維持したいですね。

> CFD という用語自体、一般用語ではないわけで、これから fj に入っ
> てくる人には意味不明な用語です。この際、これも分かりやすいも
> のに替えたらいいんじゃないでしょうか。

CFDをどうしてもやめたいということでしたら、その意見に賛成の人が
他にいるかしばらく見守りたいです。ただ、その見守っている間にCFD
のある案を改訂して検討するのはいけませんかね。

> ・CFDの定義にはこだわらない
> ・個々の案に着目した時に「関連している」議案を、同時並行的に
> 審議して、同時に投票にかけて、同時に決着がつけられるように
> たい。

この2点についてはCFDの定義を「類似した議案の集合」から「同時に
決着をつける議案の集合」に変えることで対応できませんか。

> ・個々の議案の動作は、グループよりもわかりやすい。
> ・「CFD」という用語は分かりにくい。

わかりやすい、わかりにくいは主観の相違なので… 久野

[Yasushi Shinjo]

新城＠筑波大学情報です。こんにちは。

In article <bhua4v$1b...@utogw.gssm.otsuka.tsukuba.ac.jp>

ku...@gssm.otsuka.tsukuba.ac.jp writes:
> 新城さんの提案は1番yesを集めた「議案」が成立することによってそれ
> と「依存」関係で結ばれたものも一緒に成立するわけじゃないですか。

いいえ。依存関係は、片方向です。ですから、ＡがＢに依存してい
る時、Ｂが不成立ならＡも不成立ですが、Ａが不成立でもＢは不成
立になりません。たとえば、次の４つの議案を考えます。

(B) fj.news.from.misc
(A1) fj.news.from.2ch
(A2) fj.news.from.blog
(A3) fj.news.from.slashdot

A1, A2, A3 が B に依存していると考えると、B が不成立になった
段階で、道連れで A1, A2, A3 も不成立になります。逆に、A1 が
不成立になっても、B は成立する可能性はあります。A1, A2, A3
の間では、独立しているので、A1 が不成立しても、A2 が成立する
こともあります。A1, A2, A3 の決着の時期は、同時でもいいし、
バラバラでもいいです。

ここまでは、自然で分かりやすいですよね。

少し頭を使うのは、タイミングがずれる時です。実は、A 系列と B
の決着の時期も、どちらが先でもかまいません。普通は B を先に
決着(CFA/CFV/CFS)つけるのでしょうが、A1 が先でも、かまいませ
ん。A1 が先に決着して成立した場合、これはまだ予約した状態に
留めておけばいいんです。この場合、最終的な成立は、B の決着を
待ってから確定させます。もちろん、B が不成立になると、A1 の
予約は取消して不成立にします。

後で取消すということは、自然現象にはありますが、人間の営みに
はよく出てきます。たとえば、航空券の予約とかホテルの予約とか
結婚の予約とかそういう日常的に行われている取引と似たようなも
のです。予約していても、キャンセルされることもあるわけです。

キャンセルのことを、コンピュータ用語では、undo といいます。
ワードプロセッサには、undo 機能が付いているので、ワードプロ
セッサを使える人には、お馴染の考え方でしょう。undo やキャン
セルは、そんなに難しい話ではありません。キャンセルというと、
投稿した記事のキャンセルというというのもありました。fj の参
加者は、予約やキャンセルの概念を理解できていると仮定しても問
題ないでしょう。

というわけで、予約もキャンセルも、分かりやすい話です。これも
いいですね。

話を、難しい話に戻します。CFDと議案群です。

久野流だと、上の議案 B, A1, A2, A3 は、全部別の CFD(久野) の
別の議案群になるのですか？　同じ CFD の別の議案群になるので
すか？　別記事では、こう書いていますけれど。

In article <bhqoj9$2v...@utogw.gssm.otsuka.tsukuba.ac.jp>
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> 久野です。
> はい、同時に投票したいですね。そのために我々が今努力してるんで
> しょ。私がv6でこの件の管理をするのであれば、その議案を

> { fj.net.watch }
> { fj.news.from.misc, fj.news.from.2ch, fj.news.from.blog,
> fj.news.from.slashdot }
> という2つの議案群にまとめ、複数選択CFVかCFSとします。どちらかの
> 議案群が成立すればそのグループ(群)がまとめてできます。どっちも反
> 対という票が多数ならどちらもできません。

この括り方だと、fj.news.from.2ch と fj.news.from.blog が一蓮
托生になってしまって、直感と合いませんし、今までの NGMP の
CFD の数え方（記事は１つでも複数独立として数える）とも合いま
せん。ngMP v8 で導入された、新たな問題です。

私は「必ず同時」に投票したいということはなくて、同時に投票で
きればそれでもいいし、fj.news.from.{2ch,blog,slashdot}を先に
投票できるなら先でもいいし、後でもいいしです。ただ、３ヶ月待
たされるのは勘弁して欲しいと、そういうことを言っているわけです。

議案を提出する段階で、これとこれは同時というのが決められるか
というと、私の感じでは辛いんじゃないかなあと思います。議論の
過程で、これは同時がいい、これは後回しにしようと出てくるもの
だからです。

上の B, A1, A2, A3 が全部別の「CFD」とすると、「CFD」と「CFD」
の関係は、どうなるんですか。「CFD期間」という概念を入れるに
は、これを明確にする必要があります。同じと認定されると、３ヶ
月先送りになるので。この点が、ngMP v8 のもう１つの問題点です。

> 1度に決着したいときは1つのCFDにし、別々に(ないし順番に)決着
> したいときは別のCFDにする。議案のCFDの間の移動は管理人が判断
> する。
> という方針を提案しているつもりですが、それではまずいですかね?

決定的にまずくはないけれど、よりよい案があります。それは、
ngMP v4 や v5 にあるように、議案提出時に他の議案との関係を決
めたら、基本的に変更しないことです。動的に変えるのを当てにす
るよりは、静的に決められるものは決めていた方が簡単です。

In article <bhua4v$1b...@utogw.gssm.otsuka.tsukuba.ac.jp>

ku...@gssm.otsuka.tsukuba.ac.jp writes:
> > と言われても、ちょっとね。「同時」かどうかでCFDを定義し直す
> > んですかね。でも、それだとCFDをないがしろにしている気もする
> > し。まあ、私は CFD の定義にはこだわらないのでいいけど。こだ
> > わるのは、「関連している具体的な案が同時並行的」に審議できる
> > かどうかです。
> ようやく分かりました、では「類似」を落して「同時に決着すべき
> 議案」とすればどうでしょうか。

..
> 同時に成立することが相当であると管理人が判断した議案の集まり
> を議案群と呼ぶ
> とかそういう方がいいですか?

相変わらず、CFDと議案群が同じに見えます。でも、上の例であげ
た議案が全部別 CFD なら、それでいいです。複雑なCFDというくく
りと「議案群」という括りがあるのとないのでは、ない方がいいと
思いますが、まああってもいいです。

> その原理自体はいいんですよ。それでもともとの話、現在のNGMPは1つ
> の「議案」が1つの「CFD」だという想定があって、それじゃ不十分
> (fj.net.watchとfj.news-from.*群の選択)ができないから今回の検討を
> してるんでしょ。

なるほど。久野さんは、今までの NGMP を「決着」に重みをおいて
考えてらっしゃったわけですね。私は、「CFD」は、文字通り、
「議論をしましょう」ととう意味にとっていました。決着ではなく
て「議論」のことだと考えていました。ですから、上の例では、
A1, A2, A3, B は関連しているので１つの委員会で話をすると。

「委員会」という概念はいいかもしれませんね。わかりやすい。

> 新城さんがどっちでもいいなら、現在のNGMPからの移行を考えると
> CFDに期間がついているという枠組みは維持したいですね。

私は、「Ｘの期間」の「期間」といった時、「期間」が大事であっ
て、その「期間」さえ定義できればよくて、「Ｘ」の方は、さほど
重要ではないと言っているだけです。期間が大事というのは、同じ
です。

上で書いたように、ngMP v8 では、期間をうまく区切れるのか不明
です。v4, v5 では、この点大丈夫です。

> CFDをどうしてもやめたいということでしたら、その意見に賛成の人が
> 他にいるかしばらく見守りたいです。ただ、その見守っている間にCFD
> のある案を改訂して検討するのはいけませんかね。

はい。賛成です。そういうやり方を、楽観的／投機的といいます。
あとで、CFD の話がご破算になるかもしれないけど、そうならない
と仮定して話を先にすすめます。こういう楽観的／投機的な方法を
使うと、議論の収束が早くなります。成功する確率が高い時には。
悲観的な方法だと、まずCFDを決着して、何を決着して、とやるわ
けですが、成功する確率が高い時には遅くなります。上の例では、
B より先に A1, A2, A3 を先に投票にかけるような方法が楽観的／
投機的な方法です。逆に悲観的な方法では、予約とかキャンセルと
いう考え方がないので、こうはいきません。

まとめると、こうなります。

・「依存」は、具体例で考えると非常にわかりやすい。
・予約やキャンセルは、わかりやすい。
・予約やキャンセルという考え方を使うと議論が速くなる。
・議論の期間を区切ることは大事。
・ngMP v8 の「CFD」や「議案群」という、議案をグループ化した
ものの役割がまだ不明である。
・ngMP v8 の「CFD」と「CFD」の関係が不明で、期間が区切れるの
かも不明である。ngMP v4, v5 には、そのような問題はない。

というわけで、楽観的にいきましょう。

[shuji matsuda]

In article <bhsfqr$m...@utogw.gssm.otsuka.tsukuba.ac.jp>,
ku...@gssm.otsuka.tsukuba.ac.jp wrote:

: たとえばAさんが「fj.net.watchを作る」という議案を出します。

:
: そこでBさんが「fj.net.watchを作るのであれば、併せてそこにおけ
:る議論のスタイルについて議論する場であるfj.net.styleを作るべきだ」
:と考え、「fj.net.watchに依存する提案fj.net.style」の議案を出します。
:
: ところがAさんは「watchはそもそもstyleに包含されるものだから両
:方作るのは絶対におかしい」という強固な信念のもとに「fj.net.style
:に対立する提案としてのfj.net.watch」を出し直します。
:
: はいおめでとー、YはXに依存しXはYに対立します。 久野

これですが、図式化すると、

(newgroup fj.net.watch and newgroup fj.net.style)

or

(newgroup fj.net.watch)

ということですね。Xが(X and Y) に対立しているのではありませんか？

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

shuji__...@hotmail.comさん:

> ということですね。Xが(X and Y) に対立しているのではありませんか？

新城さんの考え方では議案の集合というものはない(全部が議案どう
しの関係)。

と理解しています。 久野

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

y...@is.tsukuba.ac.jpさん:
> 新城＠筑波大学情報です。こんにちは。

こんちは。ちょっと多忙で今晩検討できるかどうか。 久野

P.S. NGMP案の[2]は入れるなという人が多いようですが、引続き他の
方のご意見も待ちます。

[IIJIMA Hiromitsu]

いいじまです。

> P.S. NGMP案の[2]は入れるなという人が多いようですが、引続き他の
> 方のご意見も待ちます。

私は、[2]は[1]とは完全に別件なので、別々の CFX で処理してほしいです。

内容についても考えるところがあるので、余裕ができたら別途ポストします。

[IIJIMA Hiromitsu]

いいじまです。

私の問題提起、新城さんにはことごとく無視されてる…
fj.comp.security ではフォローをいただいているから、届いていないはずは
ないんだけど。

> いいえ。依存関係は、片方向です。

これは「計算機屋の文法で語る」という前提がないと、自明でないでしょう。
そして、計算機屋さんである久野さんにとっても今まで自明でなかった。

> ですから、ＡがＢに依存してい
> る時、Ｂが不成立ならＡも不成立ですが、Ａが不成立でもＢは不成
> 立になりません。

それは、わかりました。

> たとえば、次の４つの議案を考えます。
>
> (B) fj.news.from.misc
> (A1) fj.news.from.2ch
> (A2) fj.news.from.blog
> (A3) fj.news.from.slashdot
>
> A1, A2, A3 が B に依存していると考えると、B が不成立になった
> 段階で、道連れで A1, A2, A3 も不成立になります。逆に、A1 が
> 不成立になっても、B は成立する可能性はあります。A1, A2, A3
> の間では、独立しているので、A1 が不成立しても、A2 が成立する
> こともあります。A1, A2, A3 の決着の時期は、同時でもいいし、
> バラバラでもいいです。
>
> ここまでは、自然で分かりやすいですよね。

この 4 つの議題だけで閉じてれば、そのとおりですね。
でも、これで 3 回目の言明になりますが、
(X) fj.net.watch vs fj.news.from.misc vs 廃案
(Y) fj.net.watch.2ch vs fj.news.from.2ch vs 廃案
はどうなりますか？
X がどちらかで成立なら Y は X に依存です。
X がどちらも不成立なら、Y は複雑な問題を呈します。

さらに議案を分割して、
(X1) fj.net.watch
(X2) fj.news.from.misc
(Y1) fj.net.watch.2ch
(Y2) fj.news.from.2ch
の 4 個の 2 択問題に分割してみると、X1 と X2、Y1 と Y2 が対立しているのは
自明ですが、実は Y1 は X2 には片面しか依存していない（X2 が成立したら Y1
は不成立になるけど、X2 が不成立の時の Y1 の取り扱いについての記述はない）
し、Y1 が X1 に依存しているかどうかも別途記述しなければいけないわけです。

> 久野流だと、上の議案 B, A1, A2, A3 は、全部別の CFD(久野) の
> 別の議案群になるのですか？　同じ CFD の別の議案群になるので
> すか？

同じ CFD の中に 2^(B A1 A2 A3) という 16 個の議案群（全部不成立という選
択肢も含めて）が存在し得て、その中から管理人が提案者の意向を勘案して適切
なものに絞り込みます。絞り込めないと判断したら別 CFD に分割して逐次審議
です。

> > 私がv6でこの件の管理をするのであれば、その議案を
> > { fj.net.watch }
> > { fj.news.from.misc, fj.news.from.2ch, fj.news.from.blog,
> > fj.news.from.slashdot }
> > という2つの議案群にまとめ、複数選択CFVかCFSとします。どちらかの
> > 議案群が成立すればそのグループ(群)がまとめてできます。どっちも反
> > 対という票が多数ならどちらもできません。
>
> この括り方だと、fj.news.from.2ch と fj.news.from.blog が一蓮
> 托生になってしまって、直感と合いませんし、今までの NGMP の
> CFD の数え方（記事は１つでも複数独立として数える）とも合いま
> せん。ngMP v8 で導入された、新たな問題です。

いいえ、必ずしもこの 2 つの議案群にまとめる必要はありません。
fj.news.from.* の 4 本の枝からは、空集合でない議案群が 15 個できます。
その中から、適宜選べばいいのです。

> 私は「必ず同時」に投票したいということはなくて、同時に投票で
> きればそれでもいいし、fj.news.from.{2ch,blog,slashdot}を先に
> 投票できるなら先でもいいし、後でもいいしです。ただ、３ヶ月待
> たされるのは勘弁して欲しいと、そういうことを言っているわけです。

結局それは無理だと思います。逐次審議にしないと、「CFV は YES/NO の 2 択・
無条件」という部分に手を入れる必要が出てきます。そうしないで順不同審議を
すると、「fj.net.watch.2ch なら fj.net.watch の正否に関係なく賛成だけど、
fj.news.from.2ch ならfj.news.from.misc が成立したときに限って賛成」（も
しくはその逆）という人が、投票行動に困ります。

> よりよい案があります。それは、
> ngMP v4 や v5 にあるように、議案提出時に他の議案との関係を決
> めたら、基本的に変更しないことです。動的に変えるのを当てにす
> るよりは、静的に決められるものは決めていた方が簡単です。

議案間の関係記述に穴が空かない保証は？

> そういうやり方を、楽観的／投機的といいます。
> あとで、CFD の話がご破算になるかもしれないけど、そうならない
> と仮定して話を先にすすめます。こういう楽観的／投機的な方法を
> 使うと、議論の収束が早くなります。成功する確率が高い時には。
> 悲観的な方法だと、まずCFDを決着して、何を決着して、とやるわ
> けですが、成功する確率が高い時には遅くなります。上の例では、
> B より先に A1, A2, A3 を先に投票にかけるような方法が楽観的／
> 投機的な方法です。逆に悲観的な方法では、予約とかキャンセルと
> いう考え方がないので、こうはいきません。

本質が出てきましたね。
「議論の収束が早くなります。成功する確率が高い時には。」
では、逆に成功する確率が低いときには？
失敗したときのペナルティの効用関数がべらぼうな値になる、という事態が
待っていますね。

私の意見では、fj.net.watch vs fj.news.from.misc の例では成功する確率は
決して高くなかったと思いますよ。そして、今後出てくる CFD が必ずしも成功
する確率の高いものでないことを考えれば、楽観的／投機的方法なるものを無
条件で適用するのには反対です。

> まとめると、こうなります。
>
> ・「依存」は、具体例で考えると非常にわかりやすい。

その具体例と類似していない、あるいはその具体例より複雑な事例をカバーでき
ますか？　現に、新城さんが出した事例に fj.net.watch.2ch という要素を導入
しただけで、少なくとも私には取り扱い困難な様相を呈しています。それは飯嶋
の頭が空っぽだから、という批判は大いにけっこうですが、私以外の人を説得で
きますか？

> ・予約やキャンセルは、わかりやすい。

ここが本質ですね。

どういう条件をつけて予約が成立するのか、逆にどういう条件ならキャンセル
するのか、を、予約の時点で一意に定められますか？　予約することには賛成だ
けどキャンセル条件で意見の食い違いが出た（たとえば、fj.net.watch vs fj.
news.from.misc が両方不成立になった場合に、予約しておいた fj.net.watch.
2ch の成立をキャンセルするかどうかで意見の食い違いが出た）場合に、どうや
って議論を収束させますか？　事前に決めておくことを新城さんは想定している
ようですが、簡単に決められますか？

予約やキャンセルという概念が現実世界で問題なく運用されているのは、意志を
持った主体が予約者１名だけという状態で運用されているためです。その前提が
fj にはありません。

現実世界でもたとえば、「3 人ぶんの『北斗星』の予約を取った」という例を挙
げると、運休になったときにどうするのか（翌朝の飛行機を使うのか、それとも
旅行を取りやめるのか）を 3 人であらかじめ決めておかないと、当日になって
あわてて別途協議ということになります。3 人ならまだしも、fj で投票に参加
する人は、きわめて悲観的に見積もって 30 人います。その意思統一ができます
か？

旅行の例に戻ると、パックツアーなら、知識と経験を持ったスタッフが詳細なシ
ナリオを事前に用意しておきます。飛行機を使うか旅行取りやめにするかは各参
加者の意志に任せるが、旅行を取りやめた参加者には所定の割合のキャンセル料
（宿代などのぶん）を差し引いてツアー代金を返金、というシナリオを描いて、
事前に了承をとりつけておくのが無難な線でしょう。（事前に了承をとりつけて
おかないと面倒なトラブルになります。）

しかし、fj にそれだけの権力を持った存在がありますか？　安易に管理人裁定
を発動すると今度は、管理人の中立性に依拠して各提案者の衡平をはかるという
新 NGMP の根幹が揺るぎます。

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

delm...@ht.sakura.ne.jpさん:

> 私は、[2]は[1]とは完全に別件なので、別々の CFX で処理してほしいです。

おお、そうですか、じゃ[2]は完全に後回しで今回は[1]にしぼります。

> 内容についても考えるところがあるので、余裕ができたら別途ポストします。

はい、となれば急がないでいいですが。 久野

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

delm...@ht.sakura.ne.jpさん:

> 私の問題提起、新城さんにはことごとく無視されてる…
> fj.comp.security ではフォローをいただいているから、届いていな

> いはずはないんだけど。

私からもお願いします。私が多忙で反応できない間に新城さんと
飯嶋さんで進めていてくれると嬉しいです。

明日はもうちょっと時間取れるかな 久野

[shuji matsuda]

In article <3F40E31C...@ht.sakura.ne.jp>,
IIJIMA Hiromitsu <delm...@ht.sakura.ne.jp> wrote:
:まずは、単一の CFD に属するとすれば、次のような最大16個の議案群に分割で

:きます。(watch) と 2^(misc+2ch+blog+slashdot)-φ の 16 件です。
:
: watchのみ
: miscのみ
: misc+2ch
: misc+blog
: misc+slashdot
: misc+2ch+blog
: misc+2ch+slashdot
: misc+blog+slashdot
: misc+2ch+blog+slashdot
: 2chのみ
: 2ch+blog
: 2ch+shashdot
: 2ch+blog+slashdot
: blogのみ
: blog+slashdot
: slashdotのみ

:1.アンケートで絞ることができます。

こういう方法は、私には、自分の頭で考えるのが嫌なばかりに、人の手を煩わせて
決めているだけに見えます。

[shuji matsuda]

In article <3F4383EB...@ht.sakura.ne.jp>,
IIJIMA Hiromitsu <delm...@ht.sakura.ne.jp> wrote:
:私の意見では、fj.net.watch vs fj.news.from.misc の例では成功する確率は

:決して高くなかったと思いますよ。そして、今後出てくる CFD が必ずしも成功
:する確率の高いものでないことを考えれば、楽観的／投機的方法なるものを無
:条件で適用するのには反対です。

要するに、『楽観的／投機的』というのは、結論を出すためのコストをかけさせ
ることで、決断を遅くするだけのことです。『次のCFVが通れば成立させるため
の予備CFV』に投票するだけの思い入れのある人は少ないでしょう。それだけ結
論をダラダラと無意味に長引かせるだけのことです。新城さんなら、『これだけ
豊かな議論を得られる成果があげられました』とおっしゃるのかもしれませんが。

そういえば、新城さん、昔に、『fjの議論は二週間くらい間をあけた方がよいノ
ダ』とおっしゃって、Naoya Kinjoばりの『亀レス』を繰返していましたが、そ
れは趣旨変えされたのでしょうか？こういう議論を二週間あけての応酬で、結論
を出せると思うのであれば、変節せず、最後までそれで押し通してください。

:しかし、fj にそれだけの権力を持った存在がありますか？　安易に管理人裁定

:を発動すると今度は、管理人の中立性に依拠して各提案者の衡平をはかるという
:新 NGMP の根幹が揺るぎます。

『管理人の中立性』というのは、別にNGMPの根幹ではありません。
やはりNGMPの根幹はCFD、期限を切った議論で結論をだすことです。CFVやCFSの
手間をかけるだけの価値のないものなら、私は管理人による、即決CFAを導入して
も良いと思っています。賛成してくれるのは河野さんくらいのようですが。

[IIJIMA Hiromitsu]

いいじまです。

> > 私は、[2]は[1]とは完全に別件なので、別々の CFX で処理してほしいです。
>
> おお、そうですか、じゃ[2]は完全に後回しで今回は[1]にしぼります。

はい。おねがいします。

[IIJIMA Hiromitsu]

いいじまです。

> :まずは、単一の CFD に属するとすれば、次のような最大16個の議案群に分割で
> :きます。(watch) と 2^(misc+2ch+blog+slashdot)-φ の 16 件です。
> :
> : watchのみ
> : miscのみ
> : misc+2ch
> : misc+blog
> : misc+slashdot
> : misc+2ch+blog
> : misc+2ch+slashdot
> : misc+blog+slashdot
> : misc+2ch+blog+slashdot
> : 2chのみ
> : 2ch+blog
> : 2ch+shashdot
> : 2ch+blog+slashdot
> : blogのみ
> : blog+slashdot
> : slashdotのみ
>
> :1.アンケートで絞ることができます。
>
> こういう方法は、私には、自分の頭で考えるのが嫌なばかりに、人の手を煩わせて
> 決めているだけに見えます。

悪く言ってしまえば、まさにその通りです。

しかし、再三に渡って述べているのですが、この例では、「自分の頭で考える」
ことの限界を超えているように思います。特に、計算機科学の素養のない一般の
参加者にとっては。

新城さんの案の本質は「ルールを書き下してパラメータを与えれば結果が出る」
ということですが、たった５項の議案の相互関係で、上記引用では廃案を含めて
17 の議案群が出ています。さらに fj.net.watch のほうにもサブカテゴリを導
入したら全体では 37 案が出ることも私が示したとおりです。

そして、どんな投票でどの案が落ちるのか、どの投票で議案の相互関係がどう書
き変わるのかは、計算機科学的な発想法に慣れた人が精密に分析しないと正確な
ところはわかりません。

不適切なルール記述をすると無駄な投票が増える（たとえば、fj.net.watch.2ch
vs fj.news.from.2ch vs 廃案 などという投票をしても、それだけでは「どちら
かを必ず作る」という結果は得られない）ことも示したとおりです。

私はニュースグループの管理を、このような「一般の参加者にはわからない雲の
上の議論」にしたくないのです。

そういうわけで久野さんの案は、「（一般参加者＋複雑な CFD、という組合せで
は）頭で考えることは困難だから、人手を使った力押しの方法で行こう」という
主張であると認識しています。

[Yasushi Shinjo]

新城＠筑波大学情報です。こんにちは。

In article <3F4383EB...@ht.sakura.ne.jp>

IIJIMA Hiromitsu <delm...@ht.sakura.ne.jp> writes:
> (X) fj.net.watch vs fj.news.from.misc vs 廃案
> (Y) fj.net.watch.2ch vs fj.news.from.2ch vs 廃案
> はどうなりますか？
> X がどちらかで成立なら Y は X に依存です。
> X がどちらも不成立なら、Y は複雑な問題を呈します。

この(X)、(Y) は、新城版 ngMP (v4/v5) の「議案」の定義に当て
はまりません。新城版 ngMP の議案の定義は、次の通りです。
------------------------------------------------------------
次世代NGMP案(v5)
最終更新: v5 2003/08/11 新城 靖

*1.3 「議案」
「議案」には、次のような種類がある。
(1) 新しいニュースグループの作成
(2) 既存のニュースグループの削除
(3) 既存のニュースグループの、憲章案、状態
(moderated/unmoderated)の変更
------------------------------------------------------------

この定義は、一見なんの変哲もないように見えるかもしれませんが、
実は、ちゃんと考えて作ってあります。それは、最終的なコントロー
ル・メッセージに１対１に対応するようにしてあります。新城版
ngMP は、この「議案」を通じて、コントロール・メッセージの送
出方法を議論していることになっています。

議案の種類が、これだけしかないので、(X),(Y) は、次のように表
現することになります。

> さらに議案を分割して、
> (X1) fj.net.watch
> (X2) fj.news.from.misc
> (Y1) fj.net.watch.2ch
> (Y2) fj.news.from.2ch

議案と議案の関係は、次の通り。

(X1): (X2) と対立
(X2): (X1) と対立
(Y1): (Y2) と対立、(X1)に依存
(Y2): (Y1) と対立、(X2)に依存

依存関係と対立関係の記述は、これだけです。簡単でしょ。
成立、不成立は、投票にかけて、数の多い順に決めて行くから、こ
れも簡単。

> > 久野流だと、上の議案 B, A1, A2, A3 は、全部別の CFD(久野) の
> > 別の議案群になるのですか？　同じ CFD の別の議案群になるので
> > すか？
>
> 同じ CFD の中に 2^(B A1 A2 A3) という 16 個の議案群（全部不成立という選
> 択肢も含めて）が存在し得て、その中から管理人が提案者の意向を勘案して適切
> なものに絞り込みます。絞り込めないと判断したら別 CFD に分割して逐次審議
> です。

久野版だと 2 の 4 乗の 16 個ですか。ホントですか。
新城版だと、4 つです。これも、新城案のほうが数が少ない。
久野版の弱点の提供にしか見えないんだけれど。

> いいえ、必ずしもこの 2 つの議案群にまとめる必要はありません。
> fj.news.from.* の 4 本の枝からは、空集合でない議案群が 15 個できます。
> その中から、適宜選べばいいのです。

新城版だと、選ぶ手間も不要です。提案者から出てきた４つの議案
だけです。どこにももめる要素はありません。すばらしい。

> > 私は「必ず同時」に投票したいということはなくて、同時に投票で
> > きればそれでもいいし、fj.news.from.{2ch,blog,slashdot}を先に
> > 投票できるなら先でもいいし、後でもいいしです。ただ、３ヶ月待
> > たされるのは勘弁して欲しいと、そういうことを言っているわけです。
>
> 結局それは無理だと思います。逐次審議にしないと、「CFV は YES/NO の 2 択・
> 無条件」という部分に手を入れる必要が出てきます。

そんなことはありません。新城f版だと、それぞれの「議案」につ
いて、ほとんど同一時期に yes/no を問うだけで終りです。同時で
もいいし、少し前後していてもいいです。それで、数の多い順に優
先して決めていきます。

> 「議論の収束が早くなります。成功する確率が高い時には。」
> では、逆に成功する確率が低いときには？

この文の意味がわかりません。依存している議案が先に不成立にな
ると、もっと早く決着が付くんだけど。

> 失敗したときのペナルティの効用関数がべらぼうな値になる、という事態が
> 待っていますね。

ペナルティは、実はほとんど０です。「成立」したら本来ならコン
トロール・メッセージを流す必要があります。作成なら newgroup、
削除なら、rmgroup。でも、「予約成立」の段階では、コントロー
ル・メッセージは出しません。ですから、予約をキャンセルすると
いうことは、何もしないということなのです。つまり、newgroup
を打ち消す rmgroup や、rmgroup を打ち消す newgroup を流す必
要はありません。結局、コストはほとんど０です。

すばらしい。

雑談ですが、投機の実現をソフトウェアでやると、コストあんまり
かからないんですよね。ハードウェアでやると大変なんだけど。ハー
ドでやると回路が余計に必要という意味でコストかかるのですが、
ソフトウェアでやると、メモリを増やすだけです。ハードウェアの
と投機的実行というのは、条件分岐が出てきたら、分岐する場合と
分岐しない場合の両方を先回りて計算してしまうというものです。
たとえば、Ｃで書くと
if( cond )
{
A
}
else
{
B
}
というプログラムがあった時、A と B の両方を実行してしまう
というものです。後で cond が来たら、どちらかの結果を捨てます。
なんでこんなことをするかというと、もちろん高速化のためです。
前に書いた論文が、ハード屋さんの所に査読が回って、往生しまし
た。ソフトウェアでやると、コストがかからないというのが分から
なかったみたい。雑談終り。

ホテルや飛行機ならキャンセル料は、ある程度は無料ですよね。結
婚のどたキャンとか高くつきそうだけど。どちらにしても、コント
ロール・メッセージとは関係ありません。

まとめると、こんな感じです。

・新城版 ngMP では、「議案」とコントロール・メッセージが対応
している。
・2 の 4乗の話が、本当に久野版 ngMP から導出できるの不明である。
導出できるなら、新城版の方が簡単である。
・コントロール・メッセージ送出の予約をキャンセルするにはコス
トはかからない。

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。出先の内職なんであまり書けないんですが :-)

とりあえず、新城さんと私での議論で相手を論破して自案を通そうと
するのは無理だし不毛でしょ。長いつきあいだしそんなことはわかって
いる :-) ですからできるだけ共通点を見つけて合流させたいですね。

y...@is.tsukuba.ac.jpさん:

> 「議案」には、次のような種類がある。
> (1) 新しいニュースグループの作成
> (2) 既存のニュースグループの削除
> (3) 既存のニュースグループの、憲章案、状態
> (moderated/unmoderated)の変更

ここにはさして対立はないんで。(3)を(1)と(2)の組合せにしたくない
強固な理由がありますか。私は(1)と(2)だけの方が簡単でいいと思って
いるけど(だって分割とか統合になったらどうせ(1)と(2)の組合せで実
現するしかないから)、まあ(3)があったっていいです。

とすると、新城案でも久野案でも最終的に(新城案の仮成立が確定した
ものとして)、議案のうちいくつかが成立し、いくつかが却下される、
ということは同じですよね。

そうすると、新城案ではその「いくつか」を依存と対立というrelation
によって指定し、久野案ではその「いくつか」を実際に議案を列挙する
ことによって指定する、その違いだけですよね。

好き嫌いは別として、ここまで合ってますか? 久野

[IIJIMA Hiromitsu]

いいじまです。

> 新城版 ngMP の議案の定義は、次の通りです。
> ------------------------------------------------------------
> 次世代NGMP案(v5)
> 最終更新: v5 2003/08/11 新城 靖
>
> *1.3 「議案」
> 「議案」には、次のような種類がある。
> (1) 新しいニュースグループの作成
> (2) 既存のニュースグループの削除
> (3) 既存のニュースグループの、憲章案、状態
> (moderated/unmoderated)の変更
> ------------------------------------------------------------
>
> この定義は、一見なんの変哲もないように見えるかもしれませんが、
> 実は、ちゃんと考えて作ってあります。それは、最終的なコントロー
> ル・メッセージに１対１に対応するようにしてあります。新城版
> ngMP は、この「議案」を通じて、コントロール・メッセージの送
> 出方法を議論していることになっています。

なるほどそうでしたか。
ではぜひとも、その旨の解説を付記するようにお願いします。
「なぜそう規定しているのか」が明確になっていたほうがいいと思います。

> > さらに議案を分割して、
> > (X1) fj.net.watch
> > (X2) fj.news.from.misc
> > (Y1) fj.net.watch.2ch
> > (Y2) fj.news.from.2ch
>
> 議案と議案の関係は、次の通り。
>
> (X1): (X2) と対立
> (X2): (X1) と対立
> (Y1): (Y2) と対立、(X1)に依存
> (Y2): (Y1) と対立、(X2)に依存
>
> 依存関係と対立関係の記述は、これだけです。簡単でしょ。

いえ、私はこれについては、

○Y1 は X1 には依存も対立もしていない
　※議論の経過によっては、「fj.net.watch も fj.news.from.misc も成立せず
　　とも fj.net.watch.2ch は作る」という結論が出てもいい
○一方で、Y1 は X2 に対立？依存？している
　※fj.news.from.misc が成立したら fj.net.watch.2ch という名前で作る案は
　　排除され、fj.news.from.2ch を作るか、それとも廃案にするかのどちらか
　　しか残らない
○Y2 についても同様に、X2 には依存も対立もしておらず、逆に X1 に依存ない
　し対立している

という関係だと考えています。ちっとも簡単なことではないです。X2-Y1、X1-Y2
の関係を依存と規定するのか対立と規定するのかについては恣意入る余地があり、
「Ya が先に成立したら Xb は不成立」とするならば対立、「Ya が成立してもあ
とで Xb が成立したら Ya を不成立・Yb を成立とする」とするならば依存です。

> 久野版だと 2 の 4 乗の 16 個ですか。ホントですか。
> 新城版だと、4 つです。これも、新城案のほうが数が少ない。
> 久野版の弱点の提供にしか見えないんだけれど。

久野版の 16 という数字が示しているのは「成立する可能性のある選択肢の数」
で、いっぽう、新城版の 4 という数字が示しているのは「出すべきコントロール
メッセージの数」です。16 という数字は、16 個のコントロールメッセージを出
すという意味ではなく、「出す可能性のあるコントロールメッセージの組合せが
16 通りある」という意味です。両者の間に指数・対数の関係があるのは当然です。
もともと違うものを換算処理しないで単純比較しても意味がありません。

> > いいえ、必ずしもこの 2 つの議案群にまとめる必要はありません。
> > fj.news.from.* の 4 本の枝からは、空集合でない議案群が 15 個できます。
> > その中から、適宜選べばいいのです。
>
> 新城版だと、選ぶ手間も不要です。提案者から出てきた４つの議案
> だけです。どこにももめる要素はありません。すばらしい。

選ぶ手間がない代わりに、議案間の関係を記述する手間があります。

そして、その記述の仕方は各提案者によって異なるものとなる可能性があります
（現に、上記の例では新城さんの記述と私の記述が異なるものとなりましたし、
さらに、私の記述は２案出ています）。

ここに「もめる要素」が明らかにあります。もめたら、誰が調整するんでしょう。
調整のための投票？　管理人裁定？

久野案は、明確に「議案群の構成作業は管理人裁定」と規定しています。
新城案は「議案間の関係は自明だからそれを確定する手順を定める必要はない」
ととりましたが、それが自明ではないことはいま明らかになりました。

> > 失敗したときのペナルティの効用関数がべらぼうな値になる、という事態が
> > 待っていますね。
>
> ペナルティは、実はほとんど０です。

いいえ。
私が言っているペナルティというのは、コントロールメッセージを出す無駄手間
だけではありません。何度も投票を行う手間や、投票結果が無駄になることによ
って参加者の投票意欲が失われる問題など、主として人的なものを想定していま
す。

> ホテルや飛行機ならキャンセル料は、ある程度は無料ですよね。

まあそうですが、「ある程度は」です。ホテルでは 3 日前 20%、2 日前 30%、
前日なら 50%、当日 100% というのが通例です。

引き合いに出した「『北斗星』利用のパックツアー」の例では、「北斗星」が運
休になったらその運賃・料金は当然に無手数料払戻になりますが、到着後に利用
予定であった観光施設なりホテルなりのキャンセル料を JR は補償してくれませ
ん。

そしてたとえば、

○3 日前に台風上陸の可能性が出たけど、その時点では東日本に影響が出るかど
　うかわからないので様子見
○出発当日になって現実に上陸して運休が決まった

という場合に、事前に、最悪でも運休決定前に、決めておかないとモメます。

パックツアーなら旅行会社の責任者が決めて了解をとりつけておきますが、そう
いうことになれていない人たちだけで連れ立って旅行を計画すると、こういうト
ラブルは現実に起こり得ます。もし、幹事だけがそういう可能性を認識していて
も他の人が無知だと、そしてその無知な人が偉い人だと、そんなことまで決める
必要はない、面倒だ、と一蹴されて、後から幹事が割を食うことになります。

> まとめると、こんな感じです。
>
> ・新城版 ngMP では、「議案」とコントロール・メッセージが対応
> している。

はい。了解しました。

> ・2 の 4乗の話が、本当に久野版 ngMP から導出できるの不明である。
> 導出できるなら、新城版の方が簡単である。

いいえ。現実に導出できますし、新城版では 2^4（もしくは、以前に列挙した
37）という数字が参加者に即座には見えないので、全部見せてしまう久野案の
ほうが簡単です。

> ・コントロール・メッセージ送出の予約をキャンセルするにはコス
> トはかからない。

それ以外のコストが無視できません。

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

───【宣伝/ADVERTISEMENT】──────────────────────
fj.os.ms-windows.server2003 または fj.os.ms-windows.server の新設の可否
を問う投票を実施中です。
fj.news.group.comp をご参照のうえ、ふるってご投票ください。

投票期限は 8/25(月)です。期限が近いのでお急ぎを！
────────────────────────────────────

[Yasushi Shinjo]

新城＠筑波大学情報です。こんにちは。

In article <bi6fv9$22...@utogw.gssm.otsuka.tsukuba.ac.jp>
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> 久野です。出先の内職なんであまり書けないんですが :-)

> > 「議案」には、次のような種類がある。
> > (1) 新しいニュースグループの作成
> > (2) 既存のニュースグループの削除
> > (3) 既存のニュースグループの、憲章案、状態
> > (moderated/unmoderated)の変更

> とすると、新城案でも久野案でも最終的に(新城案の仮成立が確定した
> ものとして)、議案のうちいくつかが成立し、いくつかが却下される、
> ということは同じですよね。

この点については、久野さんがそうおっしゃるなら、そうなんでしょう。

> そうすると、新城案ではその「いくつか」を依存と対立というrelation
> によって指定し、久野案ではその「いくつか」を実際に議案を列挙する
> ことによって指定する、その違いだけですよね。

まだ「議案を列挙する」ということに関して、イメージがつかめな
いので、この点については、わかりません。飯島さんの列挙の例も
よくわからないし。2 の 4 乗の辺りと、例を出している本人も理
解できないような関係の話と。

In article <3F4704AE...@ht.sakura.ne.jp>

IIJIMA Hiromitsu <delm...@ht.sakura.ne.jp> writes:
> > 依存関係と対立関係の記述は、これだけです。簡単でしょ。
> いえ、私はこれについては、

...
> という関係だと考えています。

それなら、それでもけっこうです。私にはよく分からないけれど。

依存関係や対立関係は、管理人が決めます。議案を提出した人は、
「ヒント」としていっしょに提出しますが、決めるのは管理人です。
ですから、この点に関してもめる余地はありません。パチバチ。

飯嶋さんが管理人だった場合は、依存関係と対立関係を飯島さんが
決めて下さい。ただし、使える言葉は、依存と対立だけです。依存
は、個々の案件について、「ＡがＢに依存している」だけです。Ａ
とＢには、具体的に提出されている案件しか入りません。案件のグ
ループは無しです。このような制限された言葉の中で、提出されて
いる議案を整理することが管理人の仕事です。

と言うわけで、上の例を、制限された言葉の中で記述してみてくだ
さい。プロトコルというのは、そのような制限を設けることです。

現行NGMPでも、「同じCFDかどうか」の判定を、管理人がしていま
す。前回は、fj.net.watch と fj.news.from.{2ch,blog,slashdot}
を、「同じ」と判定されました。このCFDの同一性と、依存してい
るか、対立しているかは、今の所は人間が判断するしかありません。
もめると言えばもめますが、管理人が決めるということにしていれ
ば、それで終りです。パチバチ。

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

y...@is.tsukuba.ac.jpさん:
> この点については、久野さんがそうおっしゃるなら、そうなんでしょう。

そうですとも。

> > そうすると、新城案ではその「いくつか」を依存と対立というrelation
> > によって指定し、久野案ではその「いくつか」を実際に議案を列挙する
> > ことによって指定する、その違いだけですよね。

> まだ「議案を列挙する」ということに関して、イメージがつかめな
> いので、この点については、わかりません。飯島さんの列挙の例も
> よくわからないし。2 の 4 乗の辺りと、例を出している本人も理
> 解できないような関係の話と。

そうですか、じゃあそこが分かるまでやりましょう。

たとえば新城案で議案Aを投票して確定した結果議案{A, B, C}が成立
したものとします。

対応して私の案では{A, B, C}を議案群と宣告してそれに対してCFXし
た結果成立すれば議案{A, B, C}が成立します。

その場合起こること(効果)は同じですよね。

> 依存関係や対立関係は、管理人が決めます。議案を提出した人は、
> 「ヒント」としていっしょに提出しますが、決めるのは管理人です。
> ですから、この点に関してもめる余地はありません。パチバチ。

はい、これも私と新城さんで相違ありません。 久野

P.S. ということは提案者がすることも相違なくて、ただ管理人が「決
定を公告」する手段が依存/対立関係か議案群かの違いですね。

[Yasushi Shinjo]

新城＠筑波大学情報です。

In article <bi7gjm$2e...@utogw.gssm.otsuka.tsukuba.ac.jp>

ku...@gssm.otsuka.tsukuba.ac.jp writes:
> たとえば新城案で議案Aを投票して確定した結果議案{A, B, C}が成立
> したものとします。

新城版では、１つの議案では、A, B, C しかなくて、１つの投票で
は、１つしか決まらないので、その点が違います。

> たとえば新城案で議案Aを投票して確定した結果議案{A, B, C}が成立
> したものとします。
> 対応して私の案では{A, B, C}を議案群と宣告してそれに対してCFXし
> た結果成立すれば議案{A, B, C}が成立します。
> その場合起こること(効果)は同じですよね。

この効果を得るなら、新城版では、次のようにします。

A: Bに依存、Cに依存
B: Cに依存、Aに依存
C: Aに依存、Bに依存

ループができればそれでもいいんですけど、まあ、１行みただけで
分かるようにぐじゃぐじゃ書いてみました。

A, B, C とかすると、なんか気分が出ませんので、具体例で言って
みましょう。

A: fj.sys.sun の削除
B: fj.os.solaris の作成
C: fj.os.sunos の作成

こういう改名を一発でやりたいという話です。たぶん、こういう話
なら、結果が同じということは言えます。これだけなら、特に問題
にはなりません。

こういう時に、久野版で問題になるのは、これに関連して、次のよ
うな案が出てきた時です。

E: fj.os.solaris.intel の作成
F: fj.os.solaris.sparc の作成

新城版だと、同時審議可能です。B に依存することにして。
CFD は、同一です。

久野版だと、CFX の単位をどうするかでもめます。

(1) {A, B, C, D, E} # 全部まとめちゃえ
(2) {A, B, C} {D, E} # 提案の順序で
(3) {A, B, C} {D} {E} # 提案の順序で
(4) {A, B} {B, D, E} # 意味的
(5) {A, B, C} {B, D, E} # (B が 2回!)
(6) {A, B, C} {B, D} {B, E} # (B が 3回!)
(7) {A} {B} {C} {D} {E} {D} # 全部ばらばら
(8) ...

新城版の雰囲気に一番近いのは、(6) かなあ。久野版だと(6) の
{A, B, C}が不成立で {B, D}が成立することもあるんですかね。完
全に同じ表現はできないんですよね。きっと。どっちが表現能力が
広いということはないんでしょうけれど。

いい組合わせを示してくださいませんか。
この組み合わせを決めるのは、管理人ですよね。

こういう組み合わせで悩むのは、久野版の時です。新城版だと悩む
ことはありません。投票して、yes の多い順にたんたんと成立させ
ていくだけです。

さて、ここで問題です。また議案が増えました。

H: fj.os.solaris.solaris9 の作成
I: fj.sys.sun.solaris9 の作成

新城版だと、簡単に扱えます。久野版ではどうなりますか。

[IIJIMA Hiromitsu]

いいじまです。

> > そうすると、新城案ではその「いくつか」を依存と対立というrelation
> > によって指定し、久野案ではその「いくつか」を実際に議案を列挙する
> > ことによって指定する、その違いだけですよね。
>
> まだ「議案を列挙する」ということに関して、イメージがつかめな
> いので、この点については、わかりません。飯島さんの列挙の例も
> よくわからないし。2 の 4 乗の辺りと、例を出している本人も理
> 解できないような関係の話と。

むう。そうですか…
fj.sys.sun の例で「議案の列挙」をしてみましょうか。
そろそろ寝たいのでこれは別記事にさせてください。

> 依存関係や対立関係は、管理人が決めます。議案を提出した人は、
> 「ヒント」としていっしょに提出しますが、決めるのは管理人です。
> ですから、この点に関してもめる余地はありません。パチバチ。

それは了解しました。しかし…

> 飯嶋さんが管理人だった場合は、依存関係と対立関係を飯島さんが
> 決めて下さい。ただし、使える言葉は、依存と対立だけです。依存
> は、個々の案件について、「ＡがＢに依存している」だけです。Ａ
> とＢには、具体的に提出されている案件しか入りません。案件のグ
> ループは無しです。このような制限された言葉の中で、提出されて
> いる議案を整理することが管理人の仕事です。
>
> と言うわけで、上の例を、制限された言葉の中で記述してみてくだ
> さい。プロトコルというのは、そのような制限を設けることです。

「上の例」というのが引用から省かれちゃったので、まずはその再掲から。

X1: fj.net.watch 新設
X2: fj.news.from.misc 新設
Y1: fj.net.watch.2ch 新設
Y2: fj.news.from.2ch 新設

これを新城さんの言葉で記述して、さらにその意味を平たく言い直してみると、
次のようになります。

1.X1 と X2 は、互いに対立している。つまり、一方が成立すれば他方は不成立と
　なる。一方について不成立の議決が為された場合にも、他方が自動的に成立は
　しない。
2.Y1 は、X2 に依存？対立？（どちらになるのか理解できてませんので解説お願
　いできますか？）している。つまり、X2 が成立すれば Y1 は不成立になる。
　X2 が成立しない場合の Y1 の扱いはここでは規定されない。また、Y1 が成立
　しても X2 は自動的に不成立とはならないし、Y1 が不成立になっても X2 が
　成立することはない。
3.同様に、Y2 は、X1 に依存？対立？（同上）している。つまり、X1 が成立すれ
　ば Y2 は不成立になる。X1 が成立しない場合の Y2 の扱いはここでは規定され
　ない。また、Y2 が成立しても、X1 は自動的に不成立とはならない。
4.Y1 と Y2 は、X1 と X2 の関係同様、互いに対立している。この規定がないと、
　X1・X2 がともに不成立になったときに、Y1 と Y2 の両方の成立を許すことに
　なる。
5.X1 は Y1 と依存・対立関係にない。つまり、一方の成否は他方の成否に関係な
　い。
6.同様に、X2 は Y2 と依存・対立関係にない。

ここで私が問題と感じる点は、
・出された議案から 2.、3. を導くのは自明ではないこと
　（すでに、新城さんと私とで見解が分かれました）
・こういうふうに書き下したとして、それを解読できる人が fj の人口の中で決
　して多くないこと（以前は新城さんは計算機科学の素養を要求していましたが、
　今度はプログラミングセンスを要求しています）
・さらに、書き下す作業を自らできる人材で、管理人になろうとする人はもっと
　少ないこと（ま、もともと管理人になる人は一般参加者よりも知識・経験のあ
　人ばかりなので、この点は大きな問題ではないかもしれません）

さらに、この書き下し例でいうと、たとえば最初に「Y1 成立」という議決が出
たとします。そうすると、Y2 は不成立となります。次に「X2 成立」という議決
が出たら、X1 は不成立、Y1 の成立はキャンセルとなりますが、Y2 については、
不成立を覆す理由がないので、そのまま不成立となります。これは、X2 が成立
のときに限って Y2 に賛成、という人には不満な結果です。これを回避するには
　　○現行 NGMP で禁止されている「条件つき投票」を導入する
　　○Y1 と Y2 の間に対立関係を設定することを避けるたる、X1・X2 の成
　　　否によって Y1・Y2 の関係が変わるという、今回新城さんが指定した
　　　文法では記述できないルールを設ける
　　○さもなくば、CFD から 3 か月待って Y2 単体の CFD を再度出す
のいずれかになります。

また、いまだに「依存」の意味が不明確なので質問です。
2 案 A・B 間の関係は「A 成立なら B がどうなるか、A 不成立なら B がどうな
るか」の両方（およびその逆方向）を記述しないと、適切な関係図を描けません。
この記述の可能性としては、単純に全部組合せを列挙すると
a)A 成立なら B 成立、A 不成立なら B 成立
b)A 成立なら B 成立、A 不成立なら B 不成立
c)A 成立なら B 成立、A 不成立なら B に影響なし
d)A 成立なら B 不成立、A 不成立なら B 成立
e)A 成立なら B 不成立、A 不成立なら B 不成立
f)A 成立なら B 不成立、A 不成立なら B に影響なし
g)A 成立なら B に影響なし、A 不成立なら B 成立
h)A 成立なら B に影響なし、A 不成立なら B 不成立
i)A 成立なら B に影響なし、A 不成立なら B に影響なし
となりますが、まず a) は「両方不成立」という選択肢を排除するので除外、
e) は B が成立し得なくなるので B が議案から外されるケースに該当します。
残ったものを再掲して
b)A 成立なら B 成立、A 不成立なら B 不成立
c)A 成立なら B 成立、A 不成立なら B に影響なし
d)A 成立なら B 不成立、A 不成立なら B 成立
f)A 成立なら B 不成立、A 不成立なら B に影響なし
g)A 成立なら B に影響なし、A 不成立なら B 成立
h)A 成立なら B に影響なし、A 不成立なら B 不成立
i)A 成立なら B に影響なし、A 不成立なら B に影響なし
のうち、f) を「B が A に対立」と称することは自明です。i) が「B は A に非
依存・非対立」を示していることも自明です。では、残りの 5 つを再掲して
b)A 成立なら B 成立、A 不成立なら B 不成立
c)A 成立なら B 成立、A 不成立なら B に影響なし
d)A 成立なら B 不成立、A 不成立なら B 成立
g)A 成立なら B に影響なし、A 不成立なら B 成立
h)A 成立なら B に影響なし、A 不成立なら B 不成立
のうち、(1)A が B に依存、かつ、B は A には非依存、(2)A が B に依存、か
つ、B が A に依存、とははて、どれを指すのでしょう。

b)～h) はすべて、新城案によれば「依存」「対立」という言葉のみで表現でき
る必要があります。そのためには、(1)(2) はそれぞれ、b)～h) のどれか一つだ
けを指す必要があります。2 つのものと 5 つのものの 1 対 1 対応なんて不可
能ですよね。(1) (2) はどれに対応するのか、(1) (2) と対応しない残り 3 つ
は「依存」「対立」の用語を用いてどう表現すべきなのか、新城さんから示して
いただけませんか？

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

y...@is.tsukuba.ac.jpさん:

> 新城版では、１つの議案では、A, B, C しかなくて、１つの投票で
> は、１つしか決まらないので、その点が違います。

その「決まった」でなくて、最終的に複数の議案が

> この効果を得るなら、新城版では、次のようにします。
> A: Bに依存、Cに依存
> B: Cに依存、Aに依存
> C: Aに依存、Bに依存

のような効果により決まった場合、というつもりだったんですけど。
ここでたとえば依存を「←」で表して

A←B
A←C
C←B

だとAが「決まった」ら{A, B, C}が成立しますよね。しかし依存関係が
これだけだとBが「決まった」ら{B, C}が成立、Cが「決まった」ら{C}
だけが成立ですよね。ここまで私の理解あってますか?

で、議案と依存関係がこれだけだと、起こり得る成立のパターンは

{A, B, C} または {B, C} または {C}

のいずれかですよね。ということは、Aについての投票は{A, B, C}を成
立させる投票、Bについての投票は{B, C}を成立させる投票、Cについて
の投票は{C}を成立させる投票、になるんじゃないでしょうか…

もしかしてまだ違うのかな…

> A: fj.sys.sun の削除
> B: fj.os.solaris の作成
> C: fj.os.sunos の作成

> こういう改名を一発でやりたいという話です。たぶん、こういう話
> なら、結果が同じということは言えます。これだけなら、特に問題
> にはなりません。

そうですね、同じでしょう。

> こういう時に、久野版で問題になるのは、これに関連して、次のよ
> うな案が出てきた時です。

> E: fj.os.solaris.intel の作成
> F: fj.os.solaris.sparc の作成

> 新城版だと、同時審議可能です。B に依存することにして。CFD は、
> 同一です。

CFDはやはり同一だと思います。で、Bが成立するとき必ずEとFも成立
するなら{B, E, F}という集合ができるじゃないですか。もしかしてBは
できてもEやFはできない可能性がある、でもEないしFができるのは必ず
Bはできる、ということですか。それだと

{B}, {B, E}, {B, F}, {B, E, F}

という集合になりますね。よって

{A, B, C}, {A, B, C, E}, {A, B, C, F}, {A, B, C, E, F}

の中から1つ選ぶんではないでしょうか。もっとも別の組合せがどーし
てもしたいという人がいれば追加してもいいんだけど。

> 久野版だと、CFX の単位をどうするかでもめます。

え? 議案群をどうするか、じゃないのかな。 久野

[IIJIMA Hiromitsu]

いいじまです。

新城さんの意図がまたもうひとつ私の頭の中で言葉になりました。
「議論の高速化の手段として並列処理を利用したい」ですね。

とすると、参加者には並列プログラミングの素養（MMX、SIMD の類を使いこなせ
るというレベルではダメで、少なくともマルチスレッドプログラミングの経験）
を求めることになります。私自身もマルチスレッドプログラミングの経験がない
（VB による OOP もどきの経験くらいはある）ので、CFD の構成法しだいでは、
ついていけなくなる可能性があります。

というわけでやはり反対なのですが…

＃私個人がついていけないからダメ、といっているわけではないですよ。
＃私の他にもついてこられなくなる人が出るだろう、という意味です。

☆

つぎに、「議案群」という言葉について。この用語を使ったのは不適切だった
かもしれませんね。久野案で言う「議案群」とは、「どれとどれを並立させ、
逆にどれを並立させないのかを、並立させる議案の列挙によって示したもの」
ですので、「選択候補」といった用語のほうがよかったかもしれません。

新城さん：

> (6) {A, B, C} {B, D} {B, E} # (B が 3回!)

という切り方をして久野案で処理すると、D というのは存在しないので F と
読み替えるとして、これは「{A,B,C}、{B,E}、{B,F} の３つの中から高々一つ
を選ぶ」という意味になります。

そういうわけで、こういう切り方は久野案では行いません。{B,E} と {B,F} が
あるなら、{B,E,F} がほぼ必然的に候補に挙がってきます。

> (7) {A} {B} {C} {D} {E} {D} # 全部ばらばら

これもおかしいです。やはり D を F と読み替えて、{D} が 2 回現れることは
ありませんし、この記述は A～F の中から高々一つを選ぶ複数選択投票を意味
します。A のみ成立（fj.sys.sun を削除するけど fj.os.{sunos,solaris}.*
ヒエラルキーはいっさい作らない）という選択肢は誰も望まないでしょう。

要するに、久野案の「議案群を構成して一括採決」というのは、現行の複数選択
投票の制度を拡張して、その際の選択候補を「ひとつのグループの改廃」から
「ひとつまたは複数のグループの改廃」に拡張するもの、と理解しています。

☆

さて、本題。

> > A: fj.sys.sun の削除
> > B: fj.os.solaris の作成
> > C: fj.os.sunos の作成
>
> > こういう改名を一発でやりたいという話です。たぶん、こういう話
> > なら、結果が同じということは言えます。これだけなら、特に問題
> > にはなりません。
>
> そうですね、同じでしょう。

これは同意です。

> > こういう時に、久野版で問題になるのは、これに関連して、次のよ
> > うな案が出てきた時です。
>
> > E: fj.os.solaris.intel の作成
> > F: fj.os.solaris.sparc の作成
>
> > 新城版だと、同時審議可能です。B に依存することにして。CFD は、
> > 同一です。
>
> CFDはやはり同一だと思います。で、Bが成立するとき必ずEとFも成立
> するなら{B, E, F}という集合ができるじゃないですか。もしかしてBは
> できてもEやFはできない可能性がある、でもEないしFができるのは必ず
> Bはできる、ということですか。それだと
>
> {B}, {B, E}, {B, F}, {B, E, F}
>
> という集合になりますね。よって
>
> {A, B, C}, {A, B, C, E}, {A, B, C, F}, {A, B, C, E, F}
>
> の中から1つ選ぶんではないでしょうか。もっとも別の組合せがどーし
> てもしたいという人がいれば追加してもいいんだけど。

う～、私なら他の案も候補に上がりかねないと思いますよ(^^;)　{A, C} とか。

で、「B 不成立・C 成立なら fj.os.sunos.intel を作りたい」という意見が出
た場合にはどうしようか悩むので、その場合には E, F を別 CFD に切り出して
後回しにします。結果の最終確定が遅くなるのはやむを得ないとします。

ただここで、fj.os.{sunos,solaris}.intel について、Proposal 段階のまま話
を進めるとか、あるいは「依存関係にある CFD は同時審議してもいいけど、依
存先（この例では B and/or C）の結果が確定するまで依存元（この例では fj.
os.{sunos,solaris}.intel）の CFA/CFS/CFV はできない」という条項を設ける
ことは検討してもよいと思います。

☆

ちょっと今はここまで。

追って別記事で、A-C が出てきてから H-I が出てくるまでを、どの議案が出る
ことによって久野案によればどういう議案群＝選択候補があがってくるのか、
を時系列順に記述してみます。

[Yasushi Shinjo]

新城＠筑波大学情報です。こんにちは。

In article <bi8vmt$31...@utogw.gssm.otsuka.tsukuba.ac.jp>
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> 久野です。

> > この効果を得るなら、新城版では、次のようにします。
> > A: Bに依存、Cに依存
> > B: Cに依存、Aに依存
> > C: Aに依存、Bに依存
> のような効果により決まった場合、というつもりだったんですけど。
> ここでたとえば依存を「←」で表して
> A←B
> A←C
> C←B
> だとAが「決まった」ら{A, B, C}が成立しますよね。

いいえ。依存関係は、そういう意味ではありません。

A が B に依存しているとは、A が「不」成立ならば、B が自動的
に「不」成立になることである。

逆に、A が 成立しても、B は成立することはありせん。B は、成
立するかもしれないし、不成立になるかもしれない。

子供が親に依存している時には、親がこけたら子供もこける、とい
う意味です。子供がこけても親がこけるかどうかはわかりません。
親がこけなかったからといって、子供がこけないという保証はあり
ません。

> > 久野版だと、CFX の単位をどうするかでもめます。
> え? 議案群をどうするか、じゃないのかな。 久野

１議案群とCFX単位は、１対１対応じゃなかったの？
どちでもいいです。

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

y...@is.tsukuba.ac.jpさん:

> A が B に依存しているとは、A が「不」成立ならば、B が自動的
> に「不」成立になることである。

ようやく了解しました。ということは「BがAに依存」を「A←B」と記
すものとして、

> > A←B
> > A←C
> > C←B

の場合、成立する可能性がある議案の集合は

{A} {A, C} {A, B, C}

ということでいいですか。また、新城さんの考える依存関係を上記のよ
うな集合の組に翻訳することは機械的にできると思いますがどうですか。

> > > 久野版だと、CFX の単位をどうするかでもめます。
> > え? 議案群をどうするか、じゃないのかな。 久野
>
> １議案群とCFX単位は、１対１対応じゃなかったの？

1つのCFXは「CFDに含まれる全ての議案群のうちから1個(または全部
否決なら0個)を選ぶもの」というつもりです。まあ久野案をそう読めな
かった原因の修正はいずれ行うとしてですね。

そうしますと、久野案で

{A} {A, C} {A, B, C}

のような集合(=議案群)からCFXで1個(ないし0個)を選ぶことは、新城案
で依存関係に基づいて制約されたCFXの結果と同じにならないでしょう
かね。まだ違うことがありますでしょうか…

だいぶ違いは減っているという気がします。 久野

P.S. もうすこししたら出かけて27日夜まで反応できません。

[Yasushi Shinjo]

新城＠筑波大学情報です。

In article <bic4at$11...@utogw.gssm.otsuka.tsukuba.ac.jp>
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> 久野です。

> > A が B に依存しているとは、A が「不」成立ならば、B が自動的
> > に「不」成立になることである。

> > > A←B
> > > A←C
> > > C←B
> の場合、成立する可能性がある議案の集合は
> {A} {A, C} {A, B, C}
> ということでいいですか。また、新城さんの考える依存関係を上記のよ
> うな集合の組に翻訳することは機械的にできると思いますがどうですか。

はい。新城版ngMPの依存関係から、この集合の組を機械的に生成で
きると思います。

> そうしますと、久野案で
> {A} {A, C} {A, B, C}
> のような集合(=議案群)からCFXで1個(ないし0個)を選ぶことは、新城案
> で依存関係に基づいて制約されたCFXの結果と同じにならないでしょう
> かね。

これは、同じにはならないですね。というのも、A が３個所に出て
います。議案 A にしか関心がない人は、この３つ全部（あと全部
ボツもあるからこれも入れると４つ）全部に注意を払わないといけ
ないというあたりが違います。

新城版だと、A にしか関心がない人は、A にだけ yes/no を投票す
ればそれで十分です。

依存関係だけなら、こんな感じで似たような話になるのでしょうが、
対立関係、つまり、対案を提起した時には、久野版だと組み合わせ
爆発的に、成立可能な案が出てきて、けっこう大変そうな気がしま
すが、そうなんでしょうか。たとえば、A の対案として、D があっ
た時には、

{A} {A, C} {A, B, C} {D} {D, C} {D, B, C} {}

となりますか。さらに、B の対案 E が出てくると

{A} {A, C} {A, B, C} {D} {D, C} {D, B, C} {}
{A} {A, C} {A, E, C} {D} {D, C} {D, E, C}

こんな感じでしょうか。

[IIJIMA Hiromitsu]

いいじまです。

すでに新城さんには久野案がどういうものかご理解いただけたと思いますけど、
一応、約束したことですから「私ならこうする」という例を出してみますね。
「同じ名前で憲章が違う」という対案を出されると面倒なので（こういうときに
新城版だと全体把握が困難になる…）、とりあえず名前だけで考えます。

> A, B, C とかすると、なんか気分が出ませんので、具体例で言って
> みましょう。
>
> A: fj.sys.sun の削除
> B: fj.os.solaris の作成
> C: fj.os.sunos の作成
>
> こういう改名を一発でやりたいという話です。たぶん、こういう話
> なら、結果が同じということは言えます。これだけなら、特に問題
> にはなりません。

ここで絶対に重要なこと。「B も C も可決されずに、A だけが可決される」と
いう事態は避けなければいけません。とすると、新城版では「B と C が両方と
も否決されたら、A は自動的に否決される」と規定しなければいけません。
「A の成立は {B,C} の少なくとも一方の成立に依存」という記述（依存先が複
数議案の OR である場合）を新城さんは想定されていましたか？

☆

まず、最初の提案者が「fj.sys.sun→fj.os.solaris」の改名を提案したとします。
そうすると、議案群は {A,B} {} の 2 つです。

で、別の人が「いや、solaris という名前では SunOS 4.x を排除することになる
から、fj.os.solaris ではなく fj.os.sunos とすべきだ」と主張したとすると、
議案群は {A,B} {A,C} {} となります。

で、「fj.os.solaris と fj.os.sunos を両方作って、バージョンで住み分けるべ
きだ」という主張が出たら、{A,B} {A,C} {A,B,C} {} になります。

ここまでは、議案群が増えるといっても、提案者の数だけに収まっています。
これが重要な点です。

さらに、「fj.os.* 階層に移動するとハードウェアの話題が排除されるので、元
のfj.sys.sun も残すべきだ」という主張をする人が出たとします。爆発が起こ
りうるのはこのときで、最悪で {A,B} {A,C} {A,B,C} {B} {C} {B,C} {} となり
ますが、fj.sys.sun を残すべきだと主張した提案者が {B} のみしか希望しなけ
れば、{A,B} {A,C} {A,B,C} {B} {} となり、他の候補は他の提案者が主張しな
ければ排除されます。

> こういう時に、久野版で問題になるのは、これに関連して、次のよ
> うな案が出てきた時です。
>
> E: fj.os.solaris.intel の作成
> F: fj.os.solaris.sparc の作成
>
> 新城版だと、同時審議可能です。B に依存することにして。
> CFD は、同一です。

これだと、私なら B と C のどちらが成立するのか（あるいは、両方成立するの
か、どちらも成立しないのか）を先に見たいので、別 CFD にしちゃいます。
「2 つに分ける」というのは組合せ爆発対策の常道ですよね。

「fj.os.solaris.intel ならあってもいいけど、fj.os.solaris が否決されたら
fj.os.sunos.intel は要らない」という意見で全員が一致していれば、これはそ
のまま同一 CFD です。

しかし、もし「fj.os.sunos が成立して fj.os.solaris 否決されたならば、
E': fj.os.sunos.intel がほしい」という話が出たとしたら、この時点が CFD
分割と、fj.X.intel の審議中断の決断点です。

で、これを先に審議したいのであれば、現行の「依存する CFD の同時審議は不
可」という規定を改めて、「依存する CFD の同時審議は可能だが、CFA/CFV/CFS
は依存先の結果が出るまで出せない」とするのが得策と考えます。

久野式の議案群羅列方式は維持したままで、「条件つき CFD」の概念を導入し、
「上位カテゴリー未定のままでの可決」を認める、というのも考えられます。
つまり、「fj.X.intel（X は sys.sun、os.solaris、os.sunos のいずれか）を
作る」ということを可決してしまうわけです。

ただしこれだと、「fj.os.solaris.intel や fj.os.sunos.intel は認めるけど、
fj.sys.sun.intel は変だ」という人と、「fj.sys.sun.intel でもいいじゃない
か」という人とで意見が分かれたら、「fj.{sys.sun,os.solaris,os.sunos}.intel
vs fj.{os.solaris,os.sunos}.intel」という投票で決することになりますが、
これだけ案件が複雑になると、投票者も判断に迷います。結局は久野案の難点の
「組合せ爆発」と新城案の難点の「複雑になると全体把握が困難」の両方を抱え
込むような。

☆

と書いてみると、「なんだ、これって CFD 分割で対応できるじゃん」というこ
となんですね。新城案は、どうも、是が非でも議論を高速化しようとして、複雑
なことを同時に扱おうとしているように思います。そこまでするメリットはある
の？　というのが私の疑問点です。

急な事態に対応したいならむしろ、緊急動議の範囲を拡大して、特定のグループ
が特定の種類の記事で爆発したらその隔離のためのグループを作って後から CFX、
ということで対応できるように思います。

2ch ではこういうことは頻繁にあって、同時多発テロのとき、サッカーワールド
カップのとき、イラク戦争のときなどに、既存の板がその話題で占拠されるのを
防ぐために管理人の裁量で新しい板が作られ、結局そのまま利用され続けていま
す。

fj でいうなら、fj.os.ms-windows.server2003 新設案の CFD で河野さんがつぶ
やいていましたが、96 年ごろに fj.rec.animation.evangelion 新設の緊急動議
を出すこともできたでしょう。

もっとも、残念ながら、今の fj の人口でそこまでの必要性は感じません。

それに、fj 全体の再編のために多数の議案を出したければ、依存しないものど
うしの組合せを並行させるということもできます。依存しないものどうしを同時
に実行するのは並列計算のごく初歩的な方法ですよね。

☆

> H: fj.os.solaris.solaris9 の作成
> I: fj.sys.sun.solaris9 の作成

これも、両方の意見が出た時点で CFD 分割です。7 件出てますから、人間の頭
の処理能力を超えていると判断せざるを得ないでしょう。7 件の間の相互関係図
を書くと、線の本数が 7 本を超えることも当然ありますよね。これだと、頭の
中だけではどうしても把握困難で、実際に羅列してみないと、「どういう結果が
予想されるのか」がピンとこないんですよね。

☆

ちと話が逸れますが、次の話の前提なので聴いてください。

私の専門である「認知心理学」という分野でさんざん研究されていることなんで
すが、生身の人間が論理的思考をする場合には、言葉で書き下されたルールを順
番に適用して形式論理的に正しい結論を導き出すということは決して多くなく、
実際には、具体例を頭の中に描いてそれを頭の中で動かしてみたり、あるいはヒ
ューリスティクスで解いてそれでよしとしてしまったりする場合が大半です。

プログラミングでも、たとえば不正な入力を弾くコードが正しく動作しているか
どうかを検証する場合にプログラマが何をするかというと、コードを読んで可能
性の樹形図を書くことはまずありません。実際に不正な入力の具体例をひとつか
ふたつ考えて入力として与え、それで実際に意図した通りの手順で意図したとお
りの場所にたどりつくかを確認して、それでよしとします。
＃だから、プログラマの想定外のの入力でハングアップしてバグ露呈、というこ
＃とがよくあるわけです。

そういう頭の構造になっているのはなぜ、というのは今のところ神のみぞ知るこ
とですが、そのほうが、人間の頭のアーキテクチャでは、結論が出るまでの時間
が格段に短くなることは確かです。

このへんの人間の頭のヒューリスティクスについては、
　　市川伸一著『考えることの科学』（1997、中公新書、ISBN4-12-101345-X）
にわかりやすい例が多数載っています。

残念ながら新城さん・久野さんの両方が所属しておられる筑波大には収蔵がない
ようですし、一般読者対象の書籍なので大学の図書館での収蔵は少ないのですが、
絶版にはなっていないので、お近くの書店で見つかると思います。ぜひ一読され
ることをお勧めします。

☆

話を戻します。

とすると、「具体例を頭の中に描」くためには、考え得る結論の数が、組合せ爆
発しない程度の少数におさまっている必要があります。7 個程度までにおさめる
のが理想ですが、12 個くらいまでなら何とかなるでしょう。それ以上だとちょ
っと投票参加者の手に負えません。

新城案では、「結果的に組合せ爆発するような依存関係の記述」になった場合に、
その爆発を押さえ込むことができません。下位案が先に否決されれば爆発候補は
減っていきますが、下位案が可決されてしまったり、あるいは下位案が上院案の
様子見になって同時採決になったりした場合には、爆発の可能性が残されたまま
になります。そして、「具体例を頭の中に描」けない事態に陥ると、

| 確率や統計に限らず、数学や科学を学んでいると、理論的には理解で
| きても直観的には腑に落ちないということがいろいろ出てくる。理論
| 的な結論を「御託宣」として鵜のみに…
（前掲書 p126）

ということになります。

久野案は、先に小爆発をいくつか発生させてから、それを CFX の前に人為的に
削ったり、爆発しないサイズに小分けしたりすることで、結論の候補をあらかじ
め人間が把握可能な数に絞り込もうというものと理解しています。

新城案は組合せ爆発しないといいますが、結局、爆発が表面に出ないだけで、そ
れぞれの投票参加者が投票行動を選ぶ際に、その頭の中で「見えない大爆発」が
起きています。つまり、爆発しないのではなく、見えない場所に押し込んでいる
だけに過ぎません。

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。お休みから復帰しました。

y...@is.tsukuba.ac.jpさん:

> > そうしますと、久野案で
> > {A} {A, C} {A, B, C}
> > のような集合(=議案群)からCFXで1個(ないし0個)を選ぶことは、新城案
> > で依存関係に基づいて制約されたCFXの結果と同じにならないでしょう
> > かね。
>
> これは、同じにはならないですね。というのも、A が３個所に出て
> います。議案 A にしか関心がない人は、この３つ全部（あと全部
> ボツもあるからこれも入れると４つ）全部に注意を払わないといけ
> ないというあたりが違います。

「結果が」同じになるかどうか伺っていたのですが、それについては
よろしいんですよね(記事の後の方から見て)。

「心理的に、見ためは」もちろん違いますとも。それについては、
「結果が」同じにできるのなら(またはできなくても最後に残る違いを
明らかにした上で)多くのfj参加者に支持されるかどうかで決めるんじゃ
ないですかね。まあそれを急ぐつもりはないですし、合流する可能性は
あると思っていますから。

> 新城版だと、A にしか関心がない人は、A にだけ yes/no を投票す
> ればそれで十分です。

その分、すべての組合せに関心がある人は何が起こるか導出するのに
手間が掛かるんじゃないでしょうか…

> 依存関係だけなら、こんな感じで似たような話になるのでしょうが、
> 対立関係、つまり、対案を提起した時には、久野版だと組み合わせ
> 爆発的に、成立可能な案が出てきて、けっこう大変そうな気がしま
> すが、そうなんでしょうか。

その通りだと思いますよ。でも「私が主観的に考えると」何が選ばれ
たら何が起こるかはこの方が分かりやすくて「優れている」のね。

いえ別にそのことに反論は不要です :-) 久野

P.S. それでそろそろv8を好きなように改訂してv9を作ってみないんで
しょうか。何か問題ありますか。

[kunihito takaYASHIKI]

高屋敷です。

>P.S. それでそろそろv8を好きなように改訂してv9を作ってみないんで
> しょうか。何か問題ありますか。

問題という以前に、難しくてついていけてません。

高屋敷 一仁 Kunihito Takayashiki
ニュースグループの新設関係はhttp://www2s.biglobe.ne.jp/~kyashiki/fj/
fjの歩き方メーリングリストでの成果を公開中
http://www2s.biglobe.ne.jp/~kyashiki/fj/arukikata/ です。

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

yas...@msf.biglobe.ne.jpさん:
> 問題という以前に、難しくてついていけてません。

なるほど。高屋敷さんにしてそのご意見ということは、久野案も新城
案もこのままだとボツのようですね。

何かいいアイデアありますかね? 久野

[MATSUMIYA Yoshihiko]

松宮です.

少し時間がとれるようになったので, まとめて追ってみました.

In article <bii7c6$h...@utogw.gssm.otsuka.tsukuba.ac.jp>
ku...@gssm.otsuka.tsukuba.ac.jp wrote:

: P.S. それでそろそろv8を好きなように改訂してv9を作ってみないんで
: しょうか。何か問題ありますか。
:
問題というか, 久野案にせよ新城案にせよ, 複雑過ぎます.
# 計算機屋でなければ理解できないとは言わないが.

fj参加者に今よりもっと気軽に使ってもらうには, これだと少
し敷居が高すぎると思いますけど?

--
MATSUMIYA Yoshihiko
E-mail: matu...@ann.club.ne.jp

[笠原 励（氷炎 雷光風）]

どうも。氷炎　雷光風（ひえん　らいこふ）こと笠原です。

Message-ID: <biii8k$9h7f2$1...@ID-123361.news.uni-berlin.de>
において高屋敷さんは書きました。

> 問題という以前に、難しくてついていけてません。
自分だけではなかったのか。何だか安心してしまいました・・・
ｍ（＿）ｍ

ちょっと思ったんですが、ＣＦＡの期限をいじってみるというのはどうでしょう？

特に指定がなければ、ＮＧＭＰに規定されている２週間。
＃場合によっては、ＮＧＭＰで規定されている「ＣＦＡは２週間必要」
＃そのものをいじってもいいかもしれません。

短い期間でのＣＦＡが必要ならその理由をきちんと示し、管理人が認定した上で、
＃管理人の認定とは、提案者の提示した期限が妥当ではないと思われる場合、
＃管理人が妥当だと思われる期間を示し、提案者との折り合いをつけるよう
＃な行為を含む。
１週間とか、１０日とかの期限でＣＦＡ期間にするというのは？
＃次世代のＮＧＭＰが必要になるというのはわかるけど、今の段階での
＃久野さんと新城さんのやりとりを見ていると、とてもついていけないし、
＃ついていこうという気をなくしました。

逐次的に処理する場合でも、多少はスピードに変化が出るような気がします。

ではでは。
--
笠原　励（氷炎　雷光風／ひえん　らいこふ）
fj.rec.games.video.*の統廃合についてご協力いただきまして
ありがとうございました。
cun...@uranus.interq.or.jp －受信専用－cun...@yahoo.co.jp
オリジナルストーリー等の感想は、if_...@lycos.co.jpまで。

[Yasushi Shinjo]

新城＠筑波大学情報です。こんにちは。

In article <bii7c6$h...@utogw.gssm.otsuka.tsukuba.ac.jp>
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> 「結果が」同じになるかどうか伺っていたのですが、それについては
> よろしいんですよね(記事の後の方から見て)。

あ、最終結果にこだわる久野さんだ。私は、経過と利用者からの視
点にこだわるので、その点から違うと申し上げておきます。

> その分、すべての組合せに関心がある人は何が起こるか導出するのに
> 手間が掛かるんじゃないでしょうか…

「導出する必要がない」と書くと、新城版の利点になります。個々
の議案に yes/no を投じるだけで、最終的につじつまが合っている
議案が成立します。矛盾は出てきません。すばらしい。ってね。

> P.S. それでそろそろv8を好きなように改訂してv9を作ってみないんで
> しょうか。何か問題ありますか。

内容は、単純化するにしても、次は v9 でしょうね。

In article <3F4B29EB...@ht.sakura.ne.jp>

IIJIMA Hiromitsu <delm...@ht.sakura.ne.jp> writes:
> これだと、私なら B と C のどちらが成立するのか（あるいは、両方成立するの
> か、どちらも成立しないのか）を先に見たいので、別 CFD にしちゃいます。
> 「2 つに分ける」というのは組合せ爆発対策の常道ですよね。

「(関連)CFD は、必ず逐次化」という仮定は、久野版にも新城版に
もありません。

新城版では、単一CFDでも、議論の決着の順序は、管理人が制御で
きるので、実質的にそういうことが可能です。逆に別 CFD にして
しまうと、この辺りの制御がやりにくくなる（担当管理人が別にな
るかもしれない）ので、単一 CFD がいいだろうということです。

> しかし、もし「fj.os.sunos が成立して fj.os.solaris 否決されたならば、
> E': fj.os.sunos.intel がほしい」という話が出たとしたら、この時点が CFD
> 分割と、fj.X.intel の審議中断の決断点です。

新城版ngMPでは、そのような話は、議案の定義に反するので扱えま
せん。「否決されたら」という条件は扱えません。扱えるのは、
「A が成立するためには、その前提として B が成立している」と
いうパタンだけです。ですから、「否決されたら」のような扱えな
い条件のために話が複雑化することはありません。それ以下の議論
は的外れです。

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

y...@is.tsukuba.ac.jpさん:

> あ、最終結果にこだわる久野さんだ。私は、経過と利用者からの視
> 点にこだわるので、その点から違うと申し上げておきます。

はい、承りました。いや、プロセスがどうでもいいっていうわけじゃ
ないですよ、もちろん。

ま、とりあえずこれまでの複雑なのはダメという人が続出してるので
ボツじゃないでしょうか?

> 内容は、単純化するにしても、次は v9 でしょうね。

はい、お待ちしてます。単純化ね。 久野

[IIJIMA Hiromitsu]

いいじまです。

他の人から「複雑すぎる」との意見が多数あがっていますね。
松宮さん、高屋敷さんまで反対、ということになると厳しいですよ。

> > 「結果が」同じになるかどうか伺っていたのですが、それについては
> > よろしいんですよね(記事の後の方から見て)。
>
> あ、最終結果にこだわる久野さんだ。私は、経過と利用者からの視
> 点にこだわるので、その点から違うと申し上げておきます。

私も「最終結果にこだわる」立場です。
もちろん、「利用者からの視点」にもこだわりますよ、ただし、「グループが
できた後の」利用者の視点ですが。

> > その分、すべての組合せに関心がある人は何が起こるか導出するのに
> > 手間が掛かるんじゃないでしょうか…
>
> 「導出する必要がない」と書くと、新城版の利点になります。個々
> の議案に yes/no を投じるだけで、最終的につじつまが合っている
> 議案が成立します。矛盾は出てきません。すばらしい。ってね。

それは賛成できないなあ。

「最終的につじつまが合っている」ことは、それほど重要ではないと考えます。
もちろん、つじつまが合わないのは好ましいことではないけど、ほかの点を犠牲
にしてまで追求すべきことではないと思います。

たとえば、fj.mail.friends。

これは fj.mail に跋扈するメル友募集記事の隔離用として用意されました。こ
の際に重視されたのが、ニュースリーダー（今では Google などの http-nntp
ゲートウェイを含みます）のグループ一覧上で、fj.mail のすぐそばに並ばせる
ことで、fj.mail を購読しようとした人の矛先を fj.mail.friends に向ける、
ということが最優先課題でした。

そこまではいいのですが、注目すべきなのが、これが、fj.personal-ads.* の
改名ではなく、それを温存したままでの新設として処理されたこと。そうすると
fj.personal-ads.penpals と重複することになりますが、それは甘んじて受け入
れる、ということになったはずです。

ここからもわかるように、参加者が問題にするのは、「最終的にどういう組合せ
のグループができあがるか」であって、必ずしも無矛盾性ではありません。

ですので、新城版を採用するとすれば、どこかで「可能性例」をすべて導出する
作業が必要です。複雑な CFD の CFX の前には誰かが全部チェックして公開する、
ということが明文で規定されるか、あるいは慣習法として必ず行われるようにな
るかするといいのですが。

ここが今のところ、私や久野さんと、新城さんとの、譲れない相違点ですか。

＃そういう意味で、今回の私の投票では、積極的に慣習法（になりうる前例）を
＃作ってしまえ、という意図で文章を書いています。

> > これだと、私なら B と C のどちらが成立するのか（あるいは、両方成立するの
> > か、どちらも成立しないのか）を先に見たいので、別 CFD にしちゃいます。
> > 「2 つに分ける」というのは組合せ爆発対策の常道ですよね。
>
> 「(関連)CFD は、必ず逐次化」という仮定は、久野版にも新城版に
> もありません。

了解しています。

私の意図するのは、新城さんが導入しようとしている「A が成立すれば対案 B が
無条件で廃案」「A が否決されれば B も共倒れで廃案」という文法だけでは処理
できない状態になったときにどうするか、ということです。これは後述します。

> 新城版では、単一CFDでも、議論の決着の順序は、管理人が制御で
> きるので、実質的にそういうことが可能です。

了解しました。

> 逆に別 CFD にして
> しまうと、この辺りの制御がやりにくくなる（担当管理人が別にな
> るかもしれない）ので、単一 CFD がいいだろうということです。

これは了解です。でも、別 CFD にしても、委員会裁量で本来の担当とは違う人
が担当管理人になることは現行 NGMP でもできるわけですから、「もともと単一
だったものを分割した場合は、原則として分割後の所属分野に関わらず元の管理
人が両方を担当する」という規定を置けば、それで済むのではないですか？

> > しかし、もし「fj.os.sunos が成立して fj.os.solaris 否決されたならば、
> > E': fj.os.sunos.intel がほしい」という話が出たとしたら、この時点が CFD
> > 分割と、fj.X.intel の審議中断の決断点です。
>
> 新城版ngMPでは、そのような話は、議案の定義に反するので扱えま
> せん。「否決されたら」という条件は扱えません。扱えるのは、
> 「A が成立するためには、その前提として B が成立している」と
> いうパタンだけです。

ですよね。それが新城さんの案の問題点なんです。つまり、

> ですから、「否決されたら」のような扱えない条件

を扱いたいという提案者が出てきたらどうするの、ということです。
fj.os.solaris の成否を待って、別 CFD にするしかないですよね。

> それ以下の議論は的外れです。

んと、「それ以下」というのは、私が引き合いに出した心理学の話も含んでます？

私がそこで言いたかったのは、新城案のめざす「ルールを形式論理で記述してそ
れに基づいて結果を導出する」という手法よりも、久野案のめざす「可能性例を
ぜんぶ頭の中に列挙して、その中から適切なものをピックアップする」という手
法のほうが、人間の頭脳というアーキテクチャにとっては自然である、というこ
となんですが。

説明不足、ないし、根拠不足であれば、前の投稿で出した文献から具体例を出し
ますが、いかがですか？

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

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

[MATSUMIYA Yoshihiko]

松宮です.

In article <3F4D8556...@ht.sakura.ne.jp>
IIJIMA Hiromitsu wrote:

: 他の人から「複雑すぎる」との意見が多数あがっていますね。
: 松宮さん、高屋敷さんまで反対、ということになると厳しいですよ。
:
# まあ, 私が反対したからといって, それほど影響があるかどうかは
# さておき.

一言でいうと, たかがニュースグループ一個をいじくるのに, あれや
これや考えなければならない, というのは面倒なんですね.

参加者の負担を軽減しようとすれば管理人の負担が増えて, 久野さん
の台詞ではないですが, 委員になろうという人がますます減ってしま
うかも知れない. 少なくとも今の体制でやっていこうというなら, そ
れは困る.

今現在の読者層とか利用状況を鑑みるに, 大改訂も結構なんですが,
もう少し小改訂を続けて改善を試みていくのも良いかな, と思います
けれど.

で, この場の思い付きですが, 例えば再提案可能になるまでの期限を
もう少し短くできるようにしてみるとか, 類似の提案については門前
払いにするのでなく, 管理人預かりにして CFD をマージ (勿論提案
者の意思は尊重しつつ, ですが), 複数選択投票にするとか, ですね.
# あくまで思い付きで, 深く検討したものではありません.

大改訂については, できるだけ直感的に分かり易い方が良い, という
のが取り敢えずの意見です.
# ルールが分かり易いと同時に, 手続きや制御(管理)する対象も分か
# り易い方が良いでしょう, ということです.

[shuji matsuda]

In article <3F4B29EB...@ht.sakura.ne.jp>,
IIJIMA Hiromitsu <delm...@ht.sakura.ne.jp> wrote:
:久野式の議案群羅列方式は維持したままで、「条件つき CFD」の概念を導入し、

:「上位カテゴリー未定のままでの可決」を認める、というのも考えられます。
:つまり、「fj.X.intel（X は sys.sun、os.solaris、os.sunos のいずれか）を
:作る」ということを可決してしまうわけです。

私はこれには明確に反対します。
無駄以外のなにものでもないですね。詳細は別記事の『条件付きCFX』で述べます。

:2ch ではこういうことは頻繁にあって、同時多発テロのとき、サッカーワールド

:カップのとき、イラク戦争のときなどに、既存の板がその話題で占拠されるのを
:防ぐために管理人の裁量で新しい板が作られ、結局そのまま利用され続けていま
:す。

私の考えでは、こういうことは、委員会が積極的にやってもよいことなんですね。
河野さんも、勇ましいことを言う割には作らないですね。需要がなくても、

イラク戦争が始まりましたので、
fj.soc.iraq-warを作りました。関連はそちらへどうぞ。

とか、作っても良いと思います。

[shuji matsuda]

In article <20030828014721.1...@uranus.interq.or.jp>,
笠原　励（氷炎　雷光風） <cun...@uranus.interq.or.jp> wrote:
:１週間とか、１０日とかの期限でＣＦＡ期間にするというのは？

こういうのとか、

In article <bipk73$hqf$1...@caraway.media.kyoto-u.ac.jp>,
MATSUMIYA Yoshihiko <matu...@ann.club.ne.jp> wrote:
:で, この場の思い付きですが, 例えば再提案可能になるまでの期限を
:もう少し短くできるようにしてみるとか,

こういうの、意味がないと思います。
人を説得することをせず、文句だけ垂れている人の機嫌をとって
どうするのでしょうか。

In article <bipk73$hqf$1...@caraway.media.kyoto-u.ac.jp>,
MATSUMIYA Yoshihiko <matu...@ann.club.ne.jp> wrote:
:類似の提案については門前

:払いにするのでなく, 管理人預かりにして CFD をマージ (勿論提案
:者の意思は尊重しつつ, ですが), 複数選択投票にするとか, ですね.

この程度のことなら、現行NGMPでもできます。

3.4.1 CFDの条件

CFDは議論開始の公式な宣言である。CFD後は、管理人が権限を持って関
与し、提案者と共同して期間内に管理行為を決定することをめざす。

3.5
CFXは原則として提案者が出す。管理人が出すこともできるが、その場
合は提案者の意思を尊重しておこなう。

[Yasushi Shinjo]

新城＠筑波大学情報です。こんにちは。

In article <3F4B29EB...@ht.sakura.ne.jp>
IIJIMA Hiromitsu <delm...@ht.sakura.ne.jp> writes:
> 新城案では、「結果的に組合せ爆発するような依存関係の記述」になった場合に、
> その爆発を押さえ込むことができません。

私は楽観的です。人間の思考がもともとその程度なので、そもそも
複雑な議案の組み合わせは最初から提出されないと思っています。
今の例で複雑になっているのは、飯島さんが、自説の補強材料とし
て、複雑な例、しかも、新城案ではもともと禁止されているような
例を出しているからです。元々の新城案の範囲内では、複雑にはな
りません。

> とすると、「具体例を頭の中に描」くためには、考え得る結論の数が、組合せ爆
> 発しない程度の少数におさまっている必要があります。7 個程度までにおさめる
> のが理想ですが、12 個くらいまでなら何とかなるでしょう。それ以上だとちょ
> っと投票参加者の手に負えません。

一度に認識できるのは、６か７ですが、チャンクを作ればもっとい
けるという話は、聞いたことがあります。７色の虹とか、ＯＳＩの
７層モデルとか。

> プログラミングでも、たとえば不正な入力を弾くコードが正しく動作しているか
> どうかを検証する場合にプログラマが何をするかというと、コードを読んで可能
> 性の樹形図を書くことはまずありません。実際に不正な入力の具体例をひとつか
> ふたつ考えて入力として与え、それで実際に意図した通りの手順で意図したとお
> りの場所にたどりつくかを確認して、それでよしとします。
> ＃だから、プログラマの想定外のの入力でハングアップしてバグ露呈、というこ
> ＃とがよくあるわけです。

面白いですね。

私の提案は、全体像を見渡すことが難しい時には、個々の議案（作
成、削除、状態変更）に対して、局所的に賛成、反対を求めるだけ
にするといいのではないかということです。認知心理学的にも、よ
い方法と言えませんか。小さい関数をバグがないよう書くというこ
とを繰り返すことで、大局的に自然にバグがないプログラムが完成
させようという試みとも言えます。

In article <3F4D8556...@ht.sakura.ne.jp>

IIJIMA Hiromitsu <delm...@ht.sakura.ne.jp> writes:
> > ですから、「否決されたら」のような扱えない条件
>
> を扱いたいという提案者が出てきたらどうするの、ということです。
> fj.os.solaris の成否を待って、別 CFD にするしかないですよね。

いいえ。同じ CFD で扱ってもいいです。同じ CFD なんだれども、
「否決されたら」ということなので、否決されるのを待ってから、
投票すればいいんです。その案が否決されるまで、
CFA/CVV/CVS/CFR などの承認手続きを遅らせればいいんです。

CFD の中で、１つの CFA/CVV/CVS/CFR が終ったとしても、決着し
ていないで別の案については、CFD 期間は続行して「同じ CFD」で
決着をつけられます。

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

成立しなかったものも、もっとたくさんあります。fj.unix 系の再
編など。こちらの方が、これを全部合わせたものより大変だったん
だけど。CFD の数は、* のものは、CFD としてはたくさんあります。
人間、このくらいは、扱えます。

[MATSUMIYA Yoshihiko]

松宮です.

In article <bipr59$c157e$2...@ID-37799.news.uni-berlin.de>
shuji matsuda wrote:

: こういうの、意味がないと思います。
: 人を説得することをせず、文句だけ垂れている人の機嫌をとって
: どうするのでしょうか。
:
じゃなくてですね. 例えば, 先行する CFD の終了から 2 週間
経過したら再 CFD 可としますね. すると, 気に入らない進行中
の CFD をさっさと決着させるように活動してもらって, その後
自分の CFD を出してもらえばいいのです.

提案者に文句を言うのでなく, fj の「世論」とか管理人までを
も動かすくらいの論陣を張って貰ってね.

本当に自分の提案するグループを作りたいとかなら, それくら
いの努力はできるでしょう.

: この程度のことなら、現行NGMPでもできます。
:
「解釈次第で」できないこともないでしょうが, 明確に読み取
れないんですよ. だから, もっと分かり易い表現に改めようと
いう話です.

ルールを変えるのでなく, 文面を変えるのも「改訂」ですから.

現に, 現行 NGMP の文章は難しいという意味のことを言ってい
る方も何人かおられましたから.
悪い文章だとは思いませんが, 確かに解釈に困るという部分が
散見されるのも事実だと, 個人的には見ていますけど.

[Yasushi Shinjo]

新城＠筑波大学情報です。こんにちは。
fj.mail.friends の関係者として少し。

In article <3F4D8556...@ht.sakura.ne.jp>
IIJIMA Hiromitsu <delm...@ht.sakura.ne.jp> writes:

> 「最終的につじつまが合っている」ことは、それほど重要ではないと考えます。
> もちろん、つじつまが合わないのは好ましいことではないけど、ほかの点を犠牲
> にしてまで追求すべきことではないと思います。
>
> たとえば、fj.mail.friends。

これは、当時の管理人が、すばらしいつじつまの合わせ方を考えた
んです。
------------------------------------------------------------
fj.mail.friends
電子メールでの文通相手の募集
fj.personal-ads.penpals
電子メール意外での文通相手の募集。
(普通は、普通の郵便でしょうが、電報とか伝書鳩とか
飛脚とか電子メール意外ならなんでもあり)
------------------------------------------------------------

> ここからもわかるように、参加者が問題にするのは、「最終的にどういう組合せ
> のグループができあがるか」であって、必ずしも無矛盾性ではありません。

矛盾ができないというのは、たとえば、改名の時に、「fj.sys.sun
の削除」と「fj.os.solaris の作成」の片方だけ成立しては困ると
いう意味で、矛盾がないと言っています。改名の時には、明らかに、
この意味での矛盾が起きないことが望まれています。

無矛盾性というのは、そういう意味であって、自分の都合のいいよ
うに拡大解釈をして、批判するのはやめていただきたい。「キャン
セル」の拡大解釈もひどかったけけど。

> ですので、新城版を採用するとすれば、どこかで「可能性例」をすべて導出する
> 作業が必要です。

私は不要だと思います。

実際に、今の管理人は、CFD の同一性を判断する時に、直感的にこ
の辺りを考えています。いちいち全ての場合の可能性例を導出した
りは為ていません。依存関係は、なければない方がいいわけですが、
「改名」のような特殊な場合には、必要になります。使われるのは、
稀です。

新城版から、依存関係を取り除いて、現行通り、改名だけを特別扱
いにするという方法は考えられます。fj.X.misc と fj.X.Y の依存
関係が扱えるのは魅力的なんだけれど。投票の結果、実際に矛盾し
た結果が出てくることはあるでしょうが、それが、１０年に一度く
らいなら面白い出来事ということになるでしょう。fj.X.misc が否
決で、fj.X.Y が可決とかね。

＼＼　新城　靖　（しんじょう　やすし）　＼＼
＼＼　筑波大学　電子・情報　　　　　　　＼＼

----------------------------------------------------------------------
From: y...@is.tsukuba.ac.jp (Yasushi Shinjo)
Message-ID: <YAS.99Fe...@is.tsukuba.ac.jp>
Date: 08 Feb 1999 17:17:04 GMT
Organization: Institute of Information Sciences and Electronics, University of
Tsukuba
Distribution:
In-reply-to: taj...@med.teikyo-u.ac.jp's message of 8 Feb 1999 10:37:15 GMT
Newsgroups: fj.news.group.net
Followup-To: fj.news.group.net
Subject: Re: [2nd Change of CFD] newgroup fj.mail.friends
References: <79meor$i7i$2...@aida.med.teikyo-u.ac.jp>

新城(net分野担当委員)です。こんにちは。

In article <79meor$i7i$2...@aida.med.teikyo-u.ac.jp>
taj...@med.teikyo-u.ac.jp (Yasuo Tajima) writes:
> CFDを変更しfj.mail.friendsの新設を提案します。
> 名称 fj.mail.friends
> 憲章 電子メール友達(電子メールによる文通相手)の募集について
> Requests for e-mail friends.
> Status: unmoderated
> CFD期間: 98/12/11 - 99/2/11
> 提案者: 田島　康夫 <taj...@med.teikyo-u.ac.jp>

はい。CFD 内容の変更として受け付けました。旧内容は、こうでした。
------------------------------------------------------------
CFD内容: fj.personal-ads.penpals -> fj.mail.friends の改名
憲章 電子メールを利用した友人の募集について
Calls for e-mail friends and related topics.
------------------------------------------------------------

> そこでfj.mail.friends新設のCFDに変更することにしました．新提案で
> はメール友達募集の場として実験的一時的にfj.personal-ads.penpalsと
> fj.mail.friendsが並立することになります．

それから、「並立の実験」とありますが、実験ではなくて、次のよ
うな「論理的解釈」が可能です。
------------------------------------------------------------
fj.mail.friends
電子メールでの文通相手の募集
fj.personal-ads.penpals
電子メール意外での文通相手の募集。
(普通は、普通の郵便でしょうが、電報とか伝書鳩とか
飛脚とか電子メール意外ならなんでもあり)
------------------------------------------------------------
このような役割分担をした結果、fj.personal-ads.penpals が空に
なったりすると、削除の対象になるでしょうね。これは、今回の
CFD とは別の CFD で扱うということです。

「実験」でも「論理的解釈」でも、同じというと同じですが、「実
験はけしからん」という意見の人もいるかと思いまして「論理的解
釈」を付けてみました。筋は通っていますよね。

[IIJIMA Hiromitsu]

いいじまです。

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

ここまでは同意です。

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

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

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

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

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

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

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

> > とすると、「具体例を頭の中に描」くためには、考え得る結論の数が、組合せ爆
> > 発しない程度の少数におさまっている必要があります。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 に関しては次の手を考えています。これの原稿はいったん
＃書き上げてありますが、投票結果が確定してから文面を再度推敲して、それか
＃ら最終的に出します。

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

新城さんが「依存と対立」をやめてもいいと書かれているのは(私にとっ
て)朗報でした ^_^;

そうすると、できるだけ簡単にするのは次のようなのでどうでしょう。

・提案者は議案を提出する
・管理人は(必要ならCFDを作成し)議案のCFDへの所属を決める
・CFVの1つの選択肢はCFDに所属するどの議案が成立するかを列挙した
もの(言及されない議案があってよい)
・そのほかに「すべて棄却」の選択肢があってもよい
・管理人はfj参加者の意見を参考に選択肢と投票管理者を定めて公告する
・CFV終了時にCFDが終了するかどうかも管理人が定めて公告する
・終了する場合はそこまでで成立しなかった議案はまとめて棄却される
・CFSの選択肢はCFVと同様
・CFAはCFVの選択肢の1つに相当するものの賛否を問う(「すべて棄却」
が旧CFRに相当)

こうすれば新城さんが気にされていた「CFVすると終ってしまう」のを
やめることができますし複数のCFVを通して最終結果を詰めて行くこと
ができますがどうですか。ただ、何回もCFVするのは時間が掛かるんで
すぐ2か月たっちゃうかな。

今日もこれから仕事で不在。 久野

[shuji matsuda]

In article <birfgk$1l...@utogw.gssm.otsuka.tsukuba.ac.jp>,
ku...@gssm.otsuka.tsukuba.ac.jp wrote:
:・管理人はfj参加者の意見を参考に選択肢と投票管理者を定めて公告する

これと、

:・CFV終了時にCFDが終了するかどうかも管理人が定めて公告する

これ、には反対します。

理由。

投票管理の実際は、提案者が行うべきであること。（したい人がその努力を行う
べきであること。）

CFV終了時にCFDを終了させるという目処を提案者に与えるべきであること。

:・CFSの選択肢はCFVと同様

これは、難しい。CFSは死んでおりますから、意味のない項目になります。

:・CFAはCFVの選択肢の1つに相当するものの賛否を問う(「すべて棄却」
: が旧CFRに相当)

これは、現行と同じです。別投稿参照。

[shuji matsuda]

これが話題の『別投稿』です。

In article <bhll3s$u...@utogw.gssm.otsuka.tsukuba.ac.jp>,
ku...@gssm.otsuka.tsukuba.ac.jp wrote:

この議論が混迷を深めている（と思う）ので、私なりに整理します。

今回、久野さんの主張と、新城さんのころころ変わる主張を以下のように単純化
しました。

○久野さんの『議案群』について。

現行NGMPでは、複数選択投票というのがあって、

A or B (or C)

を投票で決定する、ということができます。ここで、関連あるものを一群として
まとめることができれば、複数のグループを一括して扱えることになります。例
えば、

(a1 and a2) or B

のような形ですね。少し前の例を出せば、

(fj.news.from.2ch and fj.news.from.misc) or fj.net.watch

a1= fj.news.from.2ch
a2= fj.news.from.misc
B= fj.net.watch

このorのことを『対立』、andのことを『従属』と呼びましょう。対立も従属も双
方向になります。

News的には、本当は、
((newgroup fj.news.grom.2ch) and (newgroup fj.news.from.misc))
or newgroup fj.net.watch
ということです。良く考えると

rmgroup とnewgroupを組み合わせても良い

わけですね。

この変更は、CFDの定義、3.3のところ、

CFDは次のa)～e)のうちの1つだけを提案するものでなくてはならない。
CFDには、CFD期間(開始日および満了予定日。満了予定日は開始日の2か
月後)が明示されているとともに、該当する項に示された情報をすべて含
んでいる必要がある。これら以外の情報、理由づけなどは要求しない。
a) 作成: 対象NGの名称、憲章、1行英文、moderated/unmoderatedの別
b) 削除: 対象NGの名称
c) 名称変更または移動: 対象NGの名称、変更後の名称、憲章、1行英文、
moderated/unmoderatedの別
d) 憲章変更: 対象NGの名称、変更後の憲章、1行英文
e) moderated/unmoderatedの変更: 対象NGの名称、変更後の憲章、1行
英文、moderated/unmoderatedの別

前記の情報に関して複数の候補を持つこともできるが、複数選択投票以
外の合意方式を選択する場合にはCFXまでに1つに絞らなければならない。

を、

『CFDは次のa)～e)のうちの1つだけを提案するものでなくてはならない。』
が、『管理人が認定すれば』『a)からe)までの一つ一つの提案の任意の組み
合わせを一括して可否を問う一つの提案として扱うことができる。』

としておけば、全ての久野さん風組み合わせは解決できます。ちゃんちゃん。こ
れのインパクトは、新設よりも、グループ再編のときに効きます。例えば、先日
のひえん、らいこうさんでしたっけ。全体を移動する時、newgroupが済めば、
rmgroupをしたいが、そうでなければ提案自体を棄てたい、とか、そういうややこ
しい場合です。また、bulk removalを一つのCFXで行うことができるようになりま
す。

もちろん、欠陥はあります。その際たるものは、

どれとどれが同一CFDであるのかの判別が自明でなくなる

ことです。例えば、ここに河野さんという人がいて、bulk removalを一つのCFD
でおこなったとしましょう。

rmgroup fj.A and rmtoup fj.B and ....rmgroup fj.X

を一括提案して否決されたとします。

そこで、ここに新城さんという人がでてきて、

rmgroup fj.B

を直後に提案したとします。

これは、bulk removal という観点からすると別のCFDであると強弁できますが、
対象ニュースグループからみると、同一CFDであると言えます。ですので、ここに
二つの選択肢があって、

対象ニュースグループが一部でも重なっているものは同一CFDであるとしておく。

か、

同一CFDかどうかは管理人が適宜判定する（つまり、現行に手を加えない）

か決めなくてはなりません。

○さて、訳のわからない新城先生の提案ですが、気に入らん等、御趣味を全て無視
すると、要点は三つです。

１）提案者以外であっても類似の提案をしてCFDを乗っ取りたい。
２）提案を生煮えのままだして、練られていない選択肢のまま、投票、署名
を行いたい。（当然、混乱しますが、その混乱を『議論』と呼ぶ）
３）『条件付きCFX』という『他のCFXに依存したCFX』というものを新設す
る。（もちろん、『親亀がこければ子亀がこける』わけですが、その場合、
一切の『条件付きCFX』に費やした手間が無駄になります。この無駄を『楽観
的』、もしくは『投機的』と呼ぶ。)

こうすると、何が決定されるのか分からないようなもの（これを『分かりやす
い』と呼ぶ』）でもCFXにかけることができて、混乱する訳です。もちろんこれを
『議論が深まった』と呼ぶわけで、『分かりやすい』わけです。大変、『楽観
的』な御提案でございました。

さて、私は、２）及び、３）は明白に反対します。１）は議論の余地はあるかも
しれませんが、CFSの実績をみると、『提案者有利』の現行を変える必要は無いと
思います。

理由。

１）現行NGMPではCFDを行う人がCFXを行えるようになっています。実際、CFXの際
には、ある程度の作業が必要です。委員会は、節目節目で提案者から連絡がいく
ようになっていますが、実際の作業を主体的に行うのはあくまで提案者です。提
案者がそのような報われない（たかがニュースグループを改廃するだけのこと
で、俺様のニュースグループになるわけでもない）ことをするのは、提案を通し
たいからです。従って、提案者の動機がCFDを進行していく機関車のようなもので
あって、その動機に酬いが来るように、提案者がCFDの主導権を握ることができる
ようになっています。これを『提案者有利（河野さん談）』と呼びます。

現行NGMPで『提案者有利』となっていないような運営ができるところは、二点、

CFDは管理人と提案者の共同作業であると規定していること
CFSでは、対案を提出できること

この二ケ所だけです。従って、管理人がある対案をCFDに含めたいと思えば、提案
者の協力を促して対案をCFDに含めることができますし、提案者が積極的に対案を
求めていれば、CFSを行うでしょう。

しかしながら、前回のNGMP改訂で、CFSの最低数が５０のまま変更されなかった以
上、また、それに大した異議も出なかった以上、提案者が成立しないCFSを選択す
る可能性は限り無くゼロに近い。これを大した異議なく承認した人も、CFSは死ん
だということを認めている訳ですから、このような対案を求めることを制度化す
る必要は認められない。

こう私は考えております。

２）現行のCFDの構成は、期限を切って結論を出すということに大きな重点が
ありますが、もう一つ大事な点として、

何についての議論であるのかを明確に限定する

ということがあります。なぜこんなことが必要なのかといえば、CFDでは、延々と続
く議論を避けるために、同一議論禁止期間をおいています。従って、何が何と同一議
論であるのかを判別できなければなりません。そこで、現行NGMPでは『1 CFD ==
1 CFX』という建て前で、CFXの内容が違えばCFDも当然異なるという、分かりやすい
仕組みをつくっています。新城流の『分かりやすさ』とは無縁の、シンプルなものです。
この例外は選択的CFVですが、それでもまだ分かりやすい。しかし、どのCFD (NGMP
用語で言えば、CFDの部分を構成する『提案』）がどのCFXと対応しているのかわから
ない仕組みをつくれば、大変『分かりやすい』問題に変身します。これを１）と組みあ
わせると、

『分かりやすい』提案に別提案者が更に『分かりやすい』提案をぶつけて、別CFDと
できる

という何をfj参加者が選択すべきなのかかさっぱり訳の『分かりやすい』議論になります。
随分と『議論が深まり』ましたね。これには、私は明確に反対します。

３）現行のCFDは、CFX終了時にCFDが終了します。fjでの議論にはきりがありません
（河野さん談）。そのきりをつけるための仕組みがCFXです。そのCFXを最終確定とし
ないのであれば、これは、単に、いたずらに議論を引き延ばしてfj参加者がCFXやCFD
に投下した人的資源、コストを無駄にするだけのことです。それを『楽観的』と呼ぶ
わけですが、私は、この新城さんの提案を『楽観的』に取り扱うことを提案致しておる
わけです。

以上。

[shuji matsuda]

In article <bipumi$n1n$1...@caraway.media.kyoto-u.ac.jp>,
MATSUMIYA Yoshihiko <matu...@ann.club.ne.jp> wrote:
:じゃなくてですね. 例えば, 先行する CFD の終了から 2 週間
:経過したら再 CFD 可としますね.

現行は、CFD開始から３ヶ月です。公告一週間ですぐさま
CFVを行えば、最短で３週間、投票確認に１週間、コントロールに
１週間かかりますから、グループが作成されるのには早くて６週間
かかります。従って、次のCFDまでにニュースグループでの実際の
実験が行われるのは最大６週間、最小ではひょっとしてないかもし
れません。実験の結果という新しい情報無しに議論して意味がある
のでしょうか？無いと思いますね。考えを変えない人が、お経のよ
うに呪文を繰返すだけのことです。

先行するCFDの終了２週間とすると、次のCFDが始められる日には
コントロールは出ていません。

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

shuji__...@hotmail.comさん:

> 投票管理の実際は、提案者が行うべきであること。（したい人がその努力を行う
> べきであること。）
>
> CFV終了時にCFDを終了させるという目処を提案者に与えるべきであること。

ま、松田さんのご意見は了解しました。

「委員会(管理人)がもっとサービスしちゃう」「次々と気軽に投票す
る」なんてなことも試してみたらいいかなと思って。もちろん私が思っ
ただけでそうなるというわけではないです。

> これは、難しい。CFSは死んでおりますから、意味のない項目になります。

CFSの最低票数50を0に改定するの忘れてた(春の改定時に保留したま
んまだった)のですが、0にしてもいいんじゃないですかね?

今のCFVが終ったらやろうかな。 久野

[Yasushi Shinjo]

新城＠筑波大学情報です。こんにちは。

In article <birfgk$1l...@utogw.gssm.otsuka.tsukuba.ac.jp>

ku...@gssm.otsuka.tsukuba.ac.jp writes:
> 新城さんが「依存と対立」をやめてもいいと書かれているのは(私にとっ
> て)朗報でした ^_^;

依存だけなんだけど。対立というのは、対案なので、やめられません。

依存は、親ガメがこけたら子ガメもこけるという話で、
shuji__matsuda さんにでも理解できる分かりやすい話です。現行
NGMP には、もっと難解な部分がたくさんあります。依存の話は、
十分分かりやすい話なのに、あれだけ飯嶋さんがブツブツ言うのは
話の持って行方の問題かなあと思います。

なんで依存が入っているかというと、複数の議案を同時に審議する
と、逐次的に審議する時よりも、矛盾した結果が出てくる可能性が
高くなります。逐次でも矛盾した結果は出てくるので、並行では少
し確率が上がります。とはいっても、「トランザクション」という
技術を使えば、結果は、必ず逐次でやったことと同じになることが
保証できます。親ガメがこけたら子ガメもこけるというのは、トラ
ンザクションの技術の、ネストしたトランザクションという、一番
分かりやすい話です。

ちなみにトランザクションは、mutex よりもはるかに簡単です。デッ
ドロックになりそうになれば、abort して全部チャラにすればいい
ので。つまり、危なくなったら、現状維持です。わかりやすい。

矛盾の保証が要らないと言われてもね。要らないなら要らないでい
いんだけど、要ると言っている人がいるんだから、要ると言ってい
る人に合わせておけば、要らない人も要る人も両方満足できてそれ
で終りなんだけどなあ。普通は。fj は普通じゃないからいいんだけど。

> そうすると、できるだけ簡単にするのは次のようなのでどうでしょう。
> ・提案者は議案を提出する
> ・管理人は(必要ならCFDを作成し)議案のCFDへの所属を決める
> ・CFVの1つの選択肢はCFDに所属するどの議案が成立するかを列挙した
> もの(言及されない議案があってよい)

列挙は、やめてほしい。列挙をやめたら依存をやめてもいいです。

提案者としては、自分の提案と関係なくパックされるというのは、
気に入りません。自分の提案は、自分の提案だけ見て、その成否を
最後まで追い掛けるというのが筋じゃないでしょうか。この点は、
現行NGMPと新城版は同じで、新城版の分かりやすさであり利点です。

> こうすれば新城さんが気にされていた「CFVすると終ってしまう」のを
> やめることができますし複数のCFVを通して最終結果を詰めて行くこと
> ができますがどうですか。ただ、何回もCFVするのは時間が掛かるんで
> すぐ2か月たっちゃうかな。

複数の議案（提案者）で、何か同期を取ろうとすると、けっこう大
変です。その点、新城案 v4 とか v5 は、巧みに作ってあって、個々
の案件で同期を取らなくても平気になっています。もちろん、同期
をとってやった方が分かりやすいのでとった方がいいですが、誰か
反応しない人が出てきたとしても、その遅れた分は後回しかそのま
ま流して、他のものだけで先に進むことができるようになっています。

やっぱり、新城版、いい所が多いですね。

ngMP の目標としては、今の NGMP より簡単ということでしょうね。
現行NGMP は、十分難解だから、十分達成可能な目標ではないです。
変りたくないという人は、常に存在するんですけれどね。

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

y...@is.tsukuba.ac.jpさん:
> 列挙は、やめてほしい。列挙をやめたら依存をやめてもいいです。

はい、そんなのは別にこだわりません。でも対立は残されるという以
上、議案どうしの関係というものは何か残るんだろうな。それはさておき。

> ngMP の目標としては、今の NGMP より簡単ということでしょうね。

そうですね。単純に。

> 現行NGMP は、十分難解だから、十分達成可能な目標ではないです。

「十分達成可能な目標だ」ですよね?

> 変りたくないという人は、常に存在するんですけれどね。

現行よりよくなると思う人が多ければ大丈夫、改定できますよ。

では次の案待ってますね。 久野