cocolog:92616760

仏教の最適化プログラムのメモ その４ 結婚・不倫・扶養・相続などのマッチングのシミュレーション 編。「シミュレーション仏教」の模索のその１・その２から一般的な社会シミュレーションへと軸足を移したその３からの流れ。「グローバル共有メモ」で詰めていっていることのバックアップ。 (JRF 6045)

JRF 2021年3月14日 (日) Tweet

その１・その２・その３は↓。これらを読んでいることが前提。

[cocolog:92288127]
＞仏教の最適化プログラムのメモ その１。仏教は「来世がないのが良い」「生きなければならない」「自己の探求が良い」の三つの命令的前提による最適化プログラムではないか。…みたいな考えを「グローバル共有メモ」で詰めていっている。メモはやがて消えてしまうので、「ひとこと」に書き移しておく。＜

JRF2021/3/142574

[cocolog:92431465]
＞その２ 生産シミュレーションのアイデア編。「シミュレーション仏教」の模索をするその１に続きながら、少し仏教から離れ、社会の生産を中心にしてそのシミュレーションをどうするかを考えた。＜

JRF2021/3/148817

[cocolog:92541965]
＞その３ 経済と不倫のシミュレーションの部分実装 編。「シミュレーション仏教」の模索をするその１・その２に続きながら、少し仏教から離れ、経済・不倫を中心にどうするかを考え、部分実装してみた。＜

JRF2021/3/149371

プログラムの GitHub レポジトリは↓にある。今回は、test_of_matching_2.py の話が大部分を占める。

《JRF-2018/simbd: Buddhistic Philosophical Computer-Simulation of Society》
https://github.com/JRF-2018/simbd

JRF2021/3/148639

では、「グローバル共有メモ」に書いたことをコピペしていく、少し誤字修正等もあるかもしれない。

JRF2021/3/143449

……。

……。

○ 2021-02-08T10:08:57Z

子供を表すデータ構造について。

人(Person)は、実父・実母(biological_father ・ biological_mother)と養父・養母(father・mother) のデータ(ID)を持つ。

JRF2021/3/146301

親は children のリストに Child クラスのデータを持つ。Child クラスは、Child の id の他にその子との関係 実子(biological)と思っているか、養子(adopted)と思っているか の別(attr)を記録する。

JRF2021/3/142499

重要なことは、biological のデータが正しいのは、人(Person)にあるほうのデータで、Child クラスのデータは、そう思っているということでしかないということ。古代では特に父親は実子と思っているが、養子であることがあるというのを表すために使う。これにより時限爆弾的に恨みが発生することに対応したい。

JRF2021/3/148977

そして、これらのデータとは別に、扶養(supporting)、被扶養(supported)がデータとしてある。子供が成人すれば、子供のままだが、扶養からは外れる。扶養は経済的な一体として処理することを考えている。

JRF2021/3/142130

……。

結婚について。

結婚しているカップルが子供ができず、一方が不倫して子供ができると離婚の可能性がかなり上がるとすべきだろう。

そして、不倫して子供ができたカップルで共に結婚していなければ、結婚する可能性がかなり高くなる。このとき、結婚誘度(魅力度？)や結婚好意度に関係なく、そのカップルが結婚すると選ばれなければならない。不倫から結婚への「昇格」みたいな処理になるのだと思う。ここは不倫と大きく違うところだろう。

JRF2021/3/141835

この際、結婚して子供ができて後に別れたカップルと区別しなければならないが、どう判定すればいいのか…。

JRF2021/3/146423

……。

……。

○ 2021-02-09T08:27:37Z

ある程度、step させてそれで親子関係ができるのはある意味話は簡単なんだけど、問題は初期値・初期社会をどう作るかという点。

初期値で親子関係を構造的に決めるのは難しい。そこで、詳細な関係が不明なところは id を '' (空文字列)で表すことにする。None は、そのような関係な者がいないこと、'' はそのような関係の者がいるが「不明」というよりは「追えない」ことを示すとする。

JRF2021/3/144079

そして、'' でもそれなりに処理が起こるようにしなければならない。扶養とかでも何人かを扶養するかランダムに決めたあと、その人数分 '' を並べるみたいなことをする。

年を経るにしたがって扶養から出ていくというのも '' のメンバーを徐々に削除していくみたいなことが必要になる。

それは逆に難し過ぎないか？

ある年齢に達すれば '' の扶養を一人削るみたいなルールにすれば問題ない？

JRF2021/3/140614

……。

もし、'' がなければ、不倫の終りのアルゴリズムは女性側だけで不倫が終るかどうかを判定し、それを男性側にも適用する…で十分。…なのだが、'' があると、男性側だけでも相手が '' なら不倫が終るかどうか判定すべきとなるだろう。

女性側で相手が '' で別れるとなった数と同じだけ、男性側も相手が '' な者の中から別れる者が選ばれる。…となるか。

相手が '' である限り、不倫で子供ができても結婚にいたることがないとなろう。それぐらいはかまわない？

JRF2021/3/148459

……。

人(Person)の children の他に、結婚(Marriage)や不倫(Adultery)も children の項目を持ち、Person の children の Child クラスの情報を共有するとしよう。

結婚して子供ができて別れたカップルと不倫で子供ができたカップルの違いは、後者は不倫が続いていることによって判定できるだろう。

不倫や結婚が起こるとき、前の同じ相手との不倫や結婚で子供ができていれば、それを引き継ぐ処理が必要だろう。ただし、不倫期間などは引き継がず、別の「不倫」みたいに扱う。

JRF2021/3/144766

……。

……。

○ 2021-02-10T10:21:48Z

死んだとき、不倫関係などの精算は即時でいいが、経済が一年単位のため、相続の情報は別に残しておかないといけない。死亡情報には相続割合のデータも残す。そして、経済に残っている dead な者などを不倫のマッチングに使わないようにしないといけない。

JRF2021/3/146979

……。

死ぬのも即時に扱えるように経済も1ケ月単位にできれば楽だ。ただ経済のレヴィ関数を 1/12 の効果にする方法がいまいちわからない。

それで一年経済にするわけだが、一年経済で、収入や消費はどうなされると考えるべきなのだろう。一年経済だから、一年分の収入がガサッと入り、それを1ヶ月ずつ消費していくというのはあまりリアルに感じない。super-consumption をやるなら、どう実現するかという問題もある。

JRF2021/3/147082

やはり、収入は 1/12 した者が毎月支払われるとして、そこから super-consumption する…super-consumption は割合で取るからその処理は簡単…というのが、妥当な方法か？

でも、その意味ってなんだ？ 誰かが収入をプールしてくれているのか？

それより、収入は一年単位だが、消費も一年単位で起こるとして、一年に一回だけ資産が増えるとしてはどうだろう。これのリクツは、消費は借金＝ツケで回しているため、1年に1回、支払うことになる…という感じになる。

JRF2021/3/141706

どっちがリアルかと言えば難しいが、処理が簡単なのは一年単位で、月の消費額によって性格を変えるなど、論理に適用しやすいのは月単位になるか。

まぁ、でも、消費額を一年で決めて、毎月の消費額を別に保存しておけば月単位で必要な論理は適用できる気がするし、消費額は借金返済が含まれるから、むしろ資産額を見るべきという点で、そういうデータは残さないほうが吉かな？

JRF2021/3/140351

それとも上昇志向などを加味した消費額という概念は必要なのだろうか…。それは消費推計という借金返済などを除けて資産額と上昇志向・教育レベルなどから計算した別の関数にすればいのでは？ 不倫については資産額より消費推計を使ったほうがいいのかもなぁ…。

いや、消費推計の計算は面倒だな。所得の計算のときに一緒に消費の計算もして、その消費額を記録しておくほうが素直な気がする…。

JRF2021/3/147911

……。

子供などの被扶養者の消費は扶養者とともに計算すべきだから、所得計算の家族対応が待たれる感じ…。

扶養から離れるとき財産をいくらか分けてもらう…みたいなのも考えないとな…。それは扶養の終りを決めるときに決めたいが…もう少し先の話か…。

JRF2021/3/146904

……。

所得を決めるとき、12ヶ月の平均にしたがって決めるとすると考えた。ただ、μ や θ はそれで決めるとしても、cut は、12ヶ月の最大または cut なしにして、結果、タネ銭よりもマイナスになればその資産については 0 にするということでよいのではないかと思う。

JRF2021/3/143156

あと、それと絡んで、「債券」「株式」「大バクチ」とそれぞれ cut を独自に持っていて、マイナスのレヴィ分布がマイナス側に大きく振れても、それぞれの種別で 0 になるだけで、他は分散投資的に守られるようになっていたが、その根拠は何かという問題が気になる。「農地」も分散投資的にしたが、それがリアルなのかという問題がある。

ただ、分散投資がどこかで有効になるべきだという考えも私の中にはあって、どう折り合いをつけるべきか迷っている。

JRF2021/3/149115

……。

……。

○ 2021-02-11T08:00:14Z

normal_levy_rand、ゼロ除算の可能性がありうるのか。対策したほうがいいのかな？

JRF2021/3/148999

……。

相続は、かなり離れた親族でも起こるとするべきだろうか。すると、死んだ親の情報とかが残ってないといけないとなる。

寺がそういうのを保存していて、全部覚えているとするとデータが大きくなり過ぎるから、一定割合で忘れていく…というふうにしてみるか…。寄付をすると本人またはその親が「記憶」に残りやすくなる感じか…？

JRF2021/3/149468

「バーチャルな真理体系」はまずそういったところに現れてくるか…。初期値のための空 ID '' に対する処理とかもバーチャルな感じだが…。

子供が死んだのもある程度覚えることにすべきだろうか。いわゆる「水子供養」を金持ちがすると、子が死んで扶養されない親などを保護するために、そのお金が使われる。…生活を支えるほどの金はないかもしれないので、子のない老人を親のない子に引き合わせる感じだろうか。そのとき、「遠縁」の親戚などの理由が必要になるが、それを消えてしまった ID などを基に、バーチャルに理由付けする…という感じか。

JRF2021/3/149060

でも、「水子供養」した分だけしか、親が救われなければならないという理由はない。が、そういう活動は「ハードコーディング」するものの、その背景に、シミュレーションの中の「人」に参照され、納得されていることが前提とされるバーチャルな真理があるとはできるかもしれない。

JRF2021/3/147951

……。

「自己の探求がよい」または「思考と思念を深めるのがよい」については、教化レベル(education)が上がるというのだけではない何かがある。社会としての思考の深まりなどがありえ、それはシステムのあり方に影響する… educatioin が社会のパラメータとして別のところに使われるなどする…使われてどうなるか…という感じになるのだろうか。

「来世がないほうがよい」も education に少し絡み、education が高いと「来世がないほうがよい」という価値観をよく受け容れており、それがシステムに反映されている…ということになろう。

JRF2021/3/140281

「来世がないほうがよい」は、上の「記憶」との絡みを考えると、「記憶」が残らないのを気にしないということで「記憶」が残るように寄付にいそしむことはしない…となるのだろうか、それとも来世すなわち子に財産を残すことにこだわらない…とすれば寄付をよくすることになるのだろうか。

また、寄付が自己のために使われないことに納得する…自分とはあまり関係ない公共事業に投資されることを喜ぶ…ことが「来世がないほうがよい」の実現になるのだろうか。

JRF2021/3/140466

……。

……。

○ 2021-02-12T07:09:34Z

次は、test_of_matching_1.py を大きくいじって (test_of_matching_2.py にするなどして)、数期におよぶ不倫や結婚による変化を実装していこうかな…とか思っている。それを長くしながら、扶養の構築や解消なども、同じプログラムを拡張していく中でいずれひとまず実装することを考えている。簡単な経済・簡単な生死とともに。

その中で、まずは、不倫の終りの精緻化のために、恨みの精緻化が求められる。

JRF2021/3/146062

まず、商業的恨み・恨まれを作ったように、政治的な恨み・恨まれは別にしようと思う。政治的な恨まれは一般市民が持つが、恨まれは、支配層にのみある属性となるか。

あと、誰かわからないけど恨んでいる hating_unknown みたいなのが必要になろう。

誰かへの恨みは 1 から 0 の間で変化する。殺人が起こったとするときはこの数値が参照され怨恨殺人が選ばれる。hating_unknown も大きいと特定の誰かへの殺人も起きやすいとするか。

JRF2021/3/148126

誰かへの恨みが 1 上がるべき状況で、それが誰かがわからないときは hating_unknown は 0.1 上がるという相場感としよう。

特定の誰かへの恨みは減りにくいが、hating_unknown は日々の生活の中、(教育があれば)減りやすいとしよう。

JRF2021/3/141559

……。

寄付は、僧院の発展…僧を中心とした福祉事業に使われる他に、大事なところとして、国家のために使われる「税」的な分も含まれると今は考えている。そこは税と寄付を分けるべきなのかもしれないが、今のところは分けていない。

支配層の教化度合いによって、国家のために使われるか、福祉のために使われるかが変わるとなろう。基本、古代なので、福祉＝宗教と考える。ただ、農地開拓などの公共事業は、国家のためとも福祉のためともとれるので、判然と分けることはできない…と思う。それが、今のところ税と寄付を分けない理由でもある。

JRF2021/3/143420

……。

……。

○ 2021-02-13T06:15:43Z

高齢死亡率、誕生時死亡率、幼年時死亡率、一定の一般死亡率があるという感じで決まっていて、一方で、妊娠確率なども決まっているとすると、人口調節はどこで行われればいいのか？

人口調節…といえば…誕生時死亡率をいじることになるのだろうか。人口が減りぎみなら誕生時死亡率を大きくし、そうでなければ小さくするよう「制御」する。…と。

人が幸せに生きて死んでないのが「うまくいってる状態」であるとすると、それで人口一定であるためには、「誕生時死亡率」が大きいことを許容せねばならない…。

JRF2021/3/143942

「来世がないほうがよい」には「誕生時死亡率」が大きいことが許容されてることが示唆されている。…と？ いや、そんなことはありえない。

誕生時死亡率ではなく成人の数…一般死亡率で制御するというのはどうだろう？ 人口が増えると事件や蛮族侵入のような災害が増える…と。しかし、それは「災害」であってコントロール不能でないか。

それとも結婚の数だとどうだろう？ 不倫のほうが誕生時死亡率が高いから、結婚を増やしたり減らしたりでコントロールする…。しかし、宗教側としてはあえて不倫を多くするという選択肢はないだろう。ただ、結婚を遅くする…という選択肢はあるかもしれない。

JRF2021/3/146114

宗教側は、結婚を常にすすめる。そして教育による pregnancy (妊娠率) の制御を試みるということではないか。そして、教育ある結婚になるようにする。…と。

自然な「誕生時死亡率」コントロールがあるとして、宗教側は赤ん坊の「生きなければならない」を重視して pregnancy の制御によってその必要性を緩和する…というふうにするということになるだろうか。

JRF2021/3/145303

……。

古代だから、出産には死がともなうことが多い。すると、女性と男性の人口バランスがくずれがちになる。そのため男性全体は危険な仕事に従事する確率を大きくすることでバランスを取るとすればよいのだろうか。

逆に、何らかの「災害」で男ばかりが多く死んだとき、出産を増やす…というよりも、男性が危険な仕事をしないですむようにすることで「女の平和」が実現する。…のだろうか。

JRF2021/3/144020

……。

……。

○ 2021-02-18T06:22:09Z

予告どおり、数期におよぶ不倫や結婚による変化を実装する予定の test_of_matching_2.py を create した。今のところ不倫のみで、test_of_matching_1.py と test_of_reduce_2.py を合わせただけの感じになっている。(バージョン 0.0.1。)

《test_of_matching_2.py - マッチングのシミュレーション》
https://gist.github.com/JRF-2018/6650bc84f238e40826251c400f45f328

JRF2021/3/146713

この test_of_matching_2.py はどんどん改造していく予定。このプロジェクトを追ってる奇特な方はもしかすると、改造する前の初期のバージョンとかが欲しくなることがあるかもしれないが、それは GitHub Gist の機能で遡ればよいと思う。

使い方は、ソースを読んでいただく以外に知る方法がないが、今回から 4 つあるグラフの view を好きな物に指定したり、economy のセーブ、ロード (ファイルは test_of_matching_2.pickle) ができるようになっている。

JRF2021/3/147433

……。

あと、蛇足的に、もうあまりいじる予定はないのだけど、↑を作ってるときに気付いたミスが一箇所あったので↓も更新しておいた (バージョン 0.0.2)。ただ、もっとミスが隠れてるはずなので、このバージョンアップはあまり意味がないかも…だけど。

《test_of_matching_1.py - 不倫のマッチングのシミュレーション》
https://gist.github.com/JRF-2018/2792da451992dae3e918c72a66ab67b0

JRF2021/3/146043

……。

……。

○ 2021-02-19T16:04:09Z

妊娠は、妊娠しやすさみたいなパラメータが必要だろうな。妊娠できない人はできない…みたいな。出産や流産のごとに一定確率で 0 になる場合がある…という感じか。一方で、一度妊娠すると妊娠しやすさが上がるみたいなのもあってよさそう。「堕胎」を経験すると、心理的に少し下がる感じか。

あと当然、男性側にも似たパラメータがあるべきで、生殖能力(fertility?)と呼んだほうがいいか。男性は出産しないので、途中で 0 になることは病気以外ではありえない感じか。

JRF2021/3/146157

ただ、何人子供を生むかは妊娠しやすさというよりも、何人子供が欲しいかというパラメータに依存するべきだろう。

当然、経済状態によって生める生めないは変わってくるので、金を持ってれば生みたい最大数をパラメータとして持ってる感じか。

男女最低一人ずつ欲しいみたいなのは、勘定に入れるべきか否か…。まぁ、メンドクサくなるので、私は入れない方向でいくか…。

JRF2021/3/145350

途中で子供がたくさん死ぬ社会では、それを見越して子供を多めに産むだろう。実際に1年で子供が死んだ数に応じて、その逆数を欲しい子供の数にかける感じか。

ところで、僧が教育を通じて妊娠に作用できるという話があったが、それはきっと、死んだ数などを正確に把握しているのが僧で、その情報を制御できるから…ということなのかもしれない。

JRF2021/3/141953

……。

たくさん死ぬのを想定してない生みたい最大数は、2 から 12 あたりにしておくか、それを乱数で一様に(?)決める。死んだ数に応じて増える場合も最大数は 12 を超えない感じで計算しよう。

経済的に生める子供の数より育てている数が多くなると、養子に出す。逆に、妊娠しやすさが低いと養子をもらうといったところか。

欲しい子供の数に達していても、ごく小さな一定割合は妊娠する感じか。

30歳から徐々に妊娠しやすさは衰え、50歳でなくなる…といちおうしとこうか。

JRF2021/3/140050

主に男性についてだが、不倫誘度は 50 歳を超えると徐々に衰え、成功体験がなければ 70歳でほぼなくなる感じにするか。いちおう 40 歳を越えると男性も生殖能力が減る感じにするか。ただ、100歳でも残存する者は残存するとする？ 確率的に(1年で10%ぐらい)障害みたいなのにぶちあたると10%減っていく感じにするか。

JRF2021/3/142114

結婚している男女の子供の欲しい数は、男女の欲しい数の平均でいいだろう。不倫してるカップルは普通子供の欲しい数は 0 だが、他に結婚している場合は、その相手の生殖能力が低いと、本来の欲しい子供の数を求める…という感じか。複数不倫があると扱いが難しいか…いや、子供ができるまではすべての不倫相手に子供を求め、子供が生まれたら、子供がいるうち一番長くつき合ってる者に生ませたがる…というので…。いや、普通に欲しい子供の数に達するまでは、不倫相手に平等に子供を生ませたがるものかな…？

JRF2021/3/144743

流産の確率は全期で20%とするか。本来は年齢ごとに違うようだが、それは妊娠のしやすさのほうでカバーする方向で。

JRF2021/3/149468

……。

……。

○ 2021-02-20T08:27:33Z

妊娠の確率はもっとも妊娠の確率が高い組み合わせで、30%ぐらいか。高いな。それでもできない者が結構いるということは不妊が結構多いということなんだろうな。

望む妊娠がそれほど多いとすると望まない妊娠ってかなり少ないのかな？

すると結婚するとすぐに妊娠するもので、不倫の妊娠は皆失敗ということなんだろうな…。

JRF2021/3/149617

不倫者は妊娠可能なものは10%ぐらい妊娠しているとして、逆算して失敗妊娠の確率を求めることになるか。難しいな…。

それとも不倫女性のうち全体として10%になるよう妊娠している者が「補充」されるようにするか…。結婚者の妊娠も全体の10%となるよう「補充」されるように行われるとするのはどうか？ これはかなり社会の妊娠コントロール圧力が強い…と想定することになるが…。そうすると、プログラムがこれまでのものの応用になるので作りやすく、制御しやすくはなる。

JRF2021/3/144071

そうじゃないとすると一気に妊娠する者が増えてその後妊娠する者がなくなるような波ができるのではないか？ それとも、長期的には安定するようなルールがあるんだろうか？

むしろ動物の「サカリ」のように周期性が現れるのではないか？ もしかして、そもそも動物のサカリのメカニズムはそんな感じからはじまっていて、人間が一年中子供を生めるのは、まさに社会のコントロール圧力が強いからなのか？

いや、待てよ。10% ずつ補充される場合でも周期性みたいなのは出てくるんじゃないか？ やってみないとわらない感じか…。

JRF2021/3/146871

……。

……。

○ 2021-02-21T11:54:09Z

どちらかと言えば、10%になるよう補充する方向よりは、妊娠しやすさによって決まった確率で妊娠する方向のほうがよいな。そのほうが自然だ。

ただ、一気に増える…みたいなことを防止するため、子供の数が欲しい数に達しなくて妊娠を望む場合でも、前子供を生んだときからしばらくは猶予期間(1ヶ月から3年)をおくとするか。結婚の時期、不倫の時期が分散してれば、あとは猶予期間があれば十分なのではないか。

JRF2021/3/143058

そして、妊娠のしやすさは妊娠を望む場合と望まない場合で分ける。ともに妊娠の発生を random.random() < k * (妊娠のしやすさ ** m) で判定する感じにして k と m を、不倫女性のうち全体として10%になるよう…または、結婚者の妊娠も全体の10%となるよう…だいたいの値を実験して決める方向か。

結婚している女性のほうが、意識している分、妊娠しやすさの影響を受けやすいということで、妊娠を望まない女性の m より妊娠を望む女性の m のほうが大きくなるだろうと思われる。

JRF2021/3/145277

ただ、妊娠はそうするが、「堕胎」は、社会圧力が強いから、「補充」的方法を採るべきかもしれない。まぁ、でも望む妊娠の場合は「堕胎」は一定率にすべきか。

ところで、この実験、test_of_matching_2.py を使わずもっと簡単で速いモデルでできないものか…。それともメンドクサがらずに test_of_matching_2.py に早いとこ「結婚」のモデルも入れて、時間かけて実験するか…。

JRF2021/3/146523

……。

欲しい子供の数は整数でなくて実数にする。そのほうが、他のパラメータが作用されたときの変化が様々になりやすい。いずれは、僧がそこに作用することもあるとしたい。

欲しい子供の数は、結婚後の favor によって変わってくるべきだろうか。資産が大きくなると favor も大きくなりがちで、自分の資産が大きいと欲しい子供の数が大きくなるのと重なるのをどう考えるか。まぁ、そういうのはなしでいいか。

欲しい子供の数が「圧縮」されるときは、関数をいじって 2 を下まわらないようにするべきだろう。

JRF2021/3/142227

……。

……。

○ 2021-02-22T05:14:33Z

簡単な数式で、妊娠確率をどれぐらいにすればよいか考えてみる。

1ヶ月のうち r の確率妊娠できる者がいるとすると k (== 12 を考える)期で妊娠する確率 q は、

q = r + r * (1 - r) + ... + r * (1- r) ** (k - 1) = 1 - (1 - r) ** k

…になる。目標となる確率を R として q = R となるのは、

JRF2021/3/146891

r = 1 - exp(ln(1- R) / k)

…のときになる。

「望む妊娠」の場合、最も妊娠しやすい者は、12ヶ月で 50% ぐらいが妊娠する感じだろうか。すると k = 12, R = 0.5 とすると、r = 0.0561256873183065 になる。

「望まない妊娠」の場合、最も妊娠しやすい者は、12ヶ月で 10% ぐらいが妊娠する感じだろうか。すると k = 12, R = 0.1 とすると、r = 0.00874161095469671 になる。

JRF2021/3/140962

妊娠しにくい者は、10年で10%ぐらいが妊娠する感じだろうか。すると、k = 12 * 10, R = 0.1 とすると、r = 0.000877618964158571 になる。

JRF2021/3/142774

「望む妊娠」の場合は、妊娠のしやすさ=1.0 のとき r = 0.0561256873183065 で、妊娠のしやすさ＝0.1 のとき r = 0.000877618964158571 にして判定すればよい感じだろうか。ここで前は判定は random.random() < K * (妊娠のしやすさ ** m) にすると言っていたが、そうではなく線形に変化させればいいのではないか。でも、m を使うなら m = 1.8058556732541744 になる。

JRF2021/3/147889

「望まない妊娠」の場合は、妊娠のしやすさ=1.0 のとき r = 0.00874161095469671 で、妊娠のしやすさ＝0.1 のとき r = 0.000877618964158571 で線形に変化させればいいのだろうか？ 0.1 のときはもっと小さくしても良さそうだが…。ところで r = 0.000877618964158571 の場合、m を使うなら、m = 0.9982854751280996 になる。

JRF2021/3/142606

ちなみに不倫で、1ヶ月で終る「行きずりの関係」の場合は、うかつなことが多いとして、両者の中間ぐらいの確率を用意するか…。

JRF2021/3/142616

……。

不倫から結婚への「昇格」。12ヶ月で 20% が昇格するする感じでいいだろうか (r = 0.0184234701262483 になる)。もっと大きな確率にするなら、離婚から結婚までの猶予期間があってもよいかもしれない。

JRF2021/3/146269

……。

このあたり Python を計算機として使って出した。なにかの参考になるかもしれないから、特に整理せず、それも公開しておくか…(↓ バージョン 0.0.1)。まぁ、こんなふうに計算機として使ってる…ということで。

《test_of_increase_1.py - 増えていく確率のテスト》
https://gist.github.com/JRF-2018/aace48ebc44229844b6f75a39a287578

JRF2021/3/142103

……。

……。

○ 2021-02-22T15:59:01Z

プログラムの将来のモジュール化を考える。(test_of_matching_2.py に関しては複数ファイルに分けないが、将来の「新プロジェクト」では分けることを考える。)

メンバ変数を定義する Person0 のクラスを作ったあと、不倫用関数を集めた Person である PersonAD、結婚用関数を集めた Person である PersonMA を別のファイルで作り、最後に class Person (PersonAD, PersonMA) などと多重継承を使って統合する。

JRF2021/3/144353

統合は最後になるので、プログラム中で Person を使いたい場合は、base モジュールの Person すなわち base.Person を使う。統合した class Person を base.Person に代入しておく。from base import Person とやったグローバル変数 Person に統合したものを代入するのはなぜかうまくいかないのでこうする。

JRF2021/3/147222

Person 以外のクラスや共通の関数は common モジュールに入れ from common import * で読み込む。ただし、Frozen や Serializable は base でも使うので base に入れる。base についても from base import * でいいが、別に import base しておいて base.Person を使うようにしないと上に書いたようにうまくいかないことがあり、詰む。

ARGS も base に入れる。

JRF2021/3/149601

EconomyPlot も EconomyPlot0, EconomyPlotAD, EconomyPlotMA と作って最後に統合するが、これは main ルーチンでしか使わないので、base.EconomyPlot は用意しない。

…このような方針を先取りして、test_of_matching_2.py (↓)のクラスなどの整理を行った (バージョン 0.0.2)。

《test_of_matching_2.py - マッチングのシミュレーション》
https://gist.github.com/JRF-2018/6650bc84f238e40826251c400f45f328

JRF2021/3/142307

……。

……。

○ 2021-02-23T08:46:58Z

私のシミュレーションを作るときに使っている脳の部位は、きっと嘘をついているときと同じ部位なんだろうな。…いかにもっともらしい「うそ」をつくか、特に、特にデータなく、やってるところが、「うそ」をついてるのと同じ感じ。

JRF2021/3/149185

……。

……。

○ 2021-02-23T10:33:21Z

生死をやりたいように作ろうとすると時間がかかり、他のテストができないので、簡易版の生死をとりあえず作っておく予定。

test_of_matching_2.py はマッチングに関するシミュレーションがメインで、あとはあとから作っていけばいいので、それ以外はそれに必要最小限とりあえず動く程度のものをまず実装しようかと思う。

JRF2021/3/146272

経済…所得も test_of_merchant_peasant_ratio.py の成果を使わず、ランダムに資産が上下するだけの簡単なものをとりあえず作っておく予定。

JRF2021/3/145006

……。

「人口調節」のための「堕胎」を組み入れるつもりだが、その基準となる新生児人口をどう決定するか。

最初の人口の 12 * 100 分の一を一ヶ月の新生児人口とする感じか。成長にともなう死で人が死んでいく一方だから、むしろ、人口ピラミッドを、60歳まで左台形分布、60歳から110歳までを左三角分布にして両者をシームレスにつなぐ感じにすればどうだろう？ そしてそこから新生児人口も計算で導けるだろう…。

JRF2021/3/140307

…いや、それはメンドクサイな。むしろ、人口は大きくなることも小さくなることもあるとして、新生児人口を死亡数に応じて自動調節するのを最初から組み込んだほうがいいように思う。

JRF2021/3/146761

初期人口の当期不足分に対し、前期新生児誕生を引いて、それがそのまま当期新生児誕生になる…というのはちょっとアジケないから、(初期人口の当期不足分 - 前期新生児誕生) * 0.5 + 前期新生児誕生 …を当期新生児誕生としよう。まぁ、0.5 は 0.3 とかでもいいんだけど。ただし、当期新生児誕生の最小値は 最初の人口の 12 * 100 分の一 とし、それより少なくなったら切り上げる形で。人口は成長にともない減る一方だから、そうやって切り上げても増えすぎることはないであろう。

JRF2021/3/141727

……。

「堕胎」が増えるのを防ぎたいというのは「システムの中の人」も願うことだろう。この場合、コントロールできるのは、欲しい子供の数…ということだった。

欲しい子供の数の倍率を変化させるが、「堕胎」がどの水準ならどれぐらい…と事前に知るのは私にとっては難しい感じ。だから、「望む妊娠」のうち、「堕胎」されてしまったのがあれば、「倍率」を -0.1 し、そうでなければ +0.1 する感じで(偶然等しければ +0で)。ただし、「倍率」は 0.5 から 1.5 の間までしかコントロールできないとする。

JRF2021/3/147879

このコントロールをするのは、「僧」ということだったが、もしそうなら教化されたもの(education が高いもの) のみが従うとする感じにしてもよさそうだが、とにかく今は、このコントロールは大事なことなので「噂」などによって教化されてない者も従う…としよう。

JRF2021/3/142440

……。

妊娠には、全期で 20% の流産する確率があり(一定率 r = 0.0220672314570715)、それにプラスして、産むときに 5 % の新生児死亡があり、1.5%の経産婦死亡があるとしよう。本来は、新生児死亡と経産婦死亡は相関があるはずだが、それは考えないものとする。

「堕胎」は、まず、「望む妊娠」が全部助けられるようなら、そこは全部助けるものとする。そして余裕があれば、「望まない妊娠」の者が助けられるとする。

JRF2021/3/143397

「望む妊娠」か「望まない妊娠」かでは区別するが、今のところは「望む妊娠」内、または「望まない妊娠」内では、差がないものとする。もしかすると、経済力の差によって差があるなどとしたほうがリアリティがあるかもしれないが、今のところはそうしない。

妊娠猶予前というだけで「望まない妊娠」だったものは、生む前には「望む妊娠」に変わっているとする。「堕胎」のときの「望む妊娠」かどうかの判定は、出産時のデータを使う。

JRF2021/3/145685

……。

……。

○ 2021-02-24T11:37:14Z

年齢による死亡は、60歳から80歳までは毎期一定率で80歳のとき70%が死ぬようにする(r = 0.00500399146216878)。80歳から110歳までも毎期一定率で110歳のとき99%に死ぬようにする(r = 0.0127106677591385)。110歳になれば強制的に死ぬものとする。

JRF2021/3/149653

一般死亡率は一年で 0.5% とする(r = 0.000417624589192991,100年で 0.394229563509303)。病気のときの加算は将来的には考えるはずだが、今は考えない。3歳までの幼児死亡は、上の一般死亡にあわせて、さらに三年で5%とする(r = 0.00142379916781333)。

妊婦死亡と釣り合いがとれるように、男性死亡率を別に設ける可能性が将来的にはあるが、今のところは入れないでおく。災害や戦争(蛮族の侵入)などを考える際には、男性の死亡率を上げることがあるだろうし。

JRF2021/3/147477

……。

経済と教育は、毎期、一定の正規分布で上がったり下がったりする感じで。本来なら、子供・被扶養者については特別な扱いが必要なはずだが、simple な実装をとりあえず行う今は、考えないものとする。

消費は資産のだいたい5%、寄付もだいたい 5% 行っているものとする。

JRF2021/3/149785

……。

死亡にともなう相続や、結婚の際の家族資産の考慮などは今は行わないことにする。行うのは、test_of_matching_2.py に test_of_merchant_peasant_ratio.py を統合してさらに扶養を考慮した所得のルールを定めて以降に承継に関するルールを定める予定。

JRF2021/3/143563

……。

このような方針のもと、↓に誕生・死亡をプラスした (バージョン 0.0.4)。

《test_of_matching_2.py - マッチングのシミュレーション》
https://gist.github.com/JRF-2018/6650bc84f238e40826251c400f45f328

まだ結婚は入れてない。次はその結婚の実装かな…？

JRF2021/3/142453

……。

……。

○ 2021-02-25T17:57:26Z

そろそろプロジェクトの名称を考えないといけない。複数のファイル・モジュールからなるプログラムで、GitHub を使うようになるため、そのディレクトリ・リポジトリ名を考えないといけないから。

プログラムを作りはじめた当初は simulatioin buddhism でいいと思っていたが、現状あまり仏教的でないから、buddhism は大き過ぎるように思う。

JRF2021/3/146127

これは科学でなく哲学だ…といったところから、philosophical social simulation (PSS) という名称が浮かぶが、それだと逆に仏教から大きなヒントを得ていることを隠しているようで、よくない気がする。

仏教「的」哲学的社会シミュレーションということで Buddhistic philosophical computer-simulation of society あたりでどうだろう。computer を入れたのは、社会実験的なものと誤解されないため。

JRF2021/3/141018

ただ、ディレクトリ名としては長過ぎるので、bdpsimsoc か、もっと縮めて simbd あたりだろう。まぁ、ディレクトリ名は当初の simulation buddhism に戻る感じでいいか…と思う。

基本、私のリポジトリの中の一つの名前だから、simbd みたいに短い名前でいいと思う。もしワールドワイドなインターネット用に長いユニークな名前が必要なら bdpsimsoc にすることも考えるかもしれない、将来的には…といったところ。

ただ今度作るのは simbdp1 あたりにする。p は prototype の p。プロトタイプ 1号。

JRF2021/3/144794

……。

……。

○ 2021-02-26T09:21:17Z

私のやってることは、ソースコードの大きさから言って、有能なプロであれば一週間もあればできることなんだろうな。それに何ヶ月もかけてる私はひたすら「無能」ということ…。

JRF2021/3/140256

……。

……。

○ 2021-02-26T10:30:34Z

↓をバージョン 0.0.7 に。--strong-consumption を使うとき、所得だけでなく資産もみて、資産の 5% ぐらいは消費する…所得から決まる消費と資産から決まる消費の高いほうをその期の消費とする…ようにした。従来の --strong-consumption を試したいときは --strong-consumption-1 で指定できる。

JRF2021/3/140945

《test_of_income_1.py - 主に商業財産から決まる収入のテスト経済シミュレーション。》
https://gist.github.com/JRF-2018/39ed54ff14cb3c79c21f42f7254fa7bc

基本的に --strong-donation --strong-consumption --donation-rate=0.3 --donation-limit=1000 で今後のプログラムに統合して使おうかと思っている。

JRF2021/3/145634

……。

……。

○ 2021-02-26T17:09:46Z

「主に男性についてだが、不倫誘度は 50 歳を超えると徐々に衰え、成功体験がなければ 70歳でほぼなくなる感じにするか。」と書いたが、老人どうしの恋というのはあってよいので、年齢によるこの特別なマイナスはないものとする。ただ、適齢期の 24歳・20歳付近であるかどうかだけが問題とする。

test_of_matching_2.py について「結婚」の実装の前にこのあたり fertility に関する update を足した (バージョン 0.0.5)。

JRF2021/3/142625

なお、今回から GitHub Gist ではなく、GitHub のレポジトリを作ったので、そこでの更新となる。レポジトリは↓。

《JRF-2018/simbd: Buddhistic Philosophical Computer-Simulation of Society》
https://github.com/JRF-2018/simbd

JRF2021/3/145129

……。

……。

○ 2021-02-27T15:52:59Z

結婚と不倫の大きな違いは、結婚には財産移動がともなうことだろう。結納・持参金…といったものを考えないといけない。

ただ、複雑なことをあまり考えず、被扶養者(+扶養者)の人数分の一だけ、扶養者から財産が分与される…男女とも…とすれば十分か。そしてその男女は扶養からは離れる。古代なので妻は夫の扶養に入る…といったところか。まぁ、扶養自体、経済評価が一になる以上の意味はなさそうなんだけど。

JRF2021/3/144094

するとそれをするためには「扶養」のモデルが必要になってくる。

ただ、「結婚」のモデルを先に決めてしまって、あとから財産分与のための扶養を考えるという順番でも良さそうだな。

JRF2021/3/143653

……。

親が両方とも死んだ子供は、養子にならなければならない。子供が生まれない夫婦は養子が欲しい。子供が多い親は養子に出してもいい。…それぞれ需要に濃淡がある。順番に評価していく感じにすべきなのだろう。

JRF2021/3/147730

あと、子供がいない老人を扶養してもらうために誰かを養子にもらうべき…みたいな話も以前したが、老人の数が親のいない子供の数より多くなることはありえるのでその場合、扶養されない老人が出てくる。その扶養されない老人が死んでしまうわけではない…とするつもりだから、それなら、…結局、扶養されなくても老人が生きていけるなら、…そもそも老人が扶養される必要がないという話になる。

JRF2021/3/146273

そこで、親がいない若者がいれば(親が死んでから一定期間を空けたのち)、最も困窮している老人の中から選んで扶養してもらうという話にすればいいのではないか。あまり困窮していなければ特に扶養される必要もないとする。

あとこのとき、前は老人が養子にもらうことを考えたが、そうではなく、単に扶養に入るだけでいいのではないかと思う。これは、子供が扶養されるようなトシになって、孫に扶養されるような場合、親子関係が直接なくても扶養の処理が必要になる。それと同じような処理を親がいない者と老人とのマッチングの際にもすればいいという話だから。

JRF2021/3/148688

……。

扶養関係者一体すなわち「家族」が、経済の一単位となる予定だが、その場合、eagerness などは、関係者全員の平均よりも、高い者の影響を受けやすいとしたい。そこで、関係者全員の最大値 * 2/3 と全員の平均 * 1/3 の和とでもしようか。

JRF2021/3/144590

……。

相続は、死んだ者を扶養する者がいれば、それが総取りすべきだろうか？ 配偶者や子供がいれば優先すべきだろうか？

配偶者と子供を優先するが、その中に扶養する者が含まれなければ、一定、割合で扶養する者が取るという感じにするか。いや、扶養する者が配偶者なら通常の割合のままだが、扶養する者がそれ以外の場合は、まず、扶養する者が死者の二割の財産を必ずもらう…とするか。その後、通常の割合で分けられる…と。

JRF2021/3/149963

基本は日本の法定相続分の計算とする。

ただし、扶養されている場合は、それが配偶者でないかぎり、扶養されている者が 2 割をまず問答無用で取る。

JRF2021/3/146256

また、(扶養されていなくて) 扶養している場合、扶養しているものが 正常な全割合を 1 とすると余計に 1/10 ずつもらえることにする。つまり、扶養しているものが二人いて、両者が 0.2 ずつ通常ならもらえる場合、(0.2 / (1 + 1/10 + 1/10)) + ((1/10) / (1 + 1/10 + 1/10)) の割合がもらえることになるとする。

これは相続分というよりは、自然にそれぐらいの分け前が生じる…といった部分になると思う。

JRF2021/3/142167

……。

相続割合の計算をテスト実装してみた。test_of_inheritance_1.py がそれになる。(バージョン 0.0.1)。

《simbd/test_of_inheritance_1.py at master - JRF-2018/simbd》
https://github.com/JRF-2018/simbd/blob/master/test_of_inheritance_1.py

JRF2021/3/140417

……。

死者は死んですぐ相続されたあと、相続人のうち、相続割合がもっとも大きい者もしくはその大きい者が扶養されている者の扶養に入り、経済の計算がされたのち、economy.people から除去されるとしよう。

JRF2021/3/140419

……。

相続するときの土地と商業財産は、最大の相続人からまず土地をめいっぱい取るとしよう。

土地が増えるときは、家族の中で扶養者の土地から増え、減るときは被扶養者の土地から減ることとしよう。

JRF2021/3/145766

……。

Tomb は30年は無償で削られないとしよう。

JRF2021/3/149769

……。

……。

○ 2021-02-28T17:57:57Z

死んだあと経済にだけは「参加」することになるが、最後の精算のときに、相続割合の再計算が必要となる。精算のときまでにさらに死んだ者がいるかもしれないから。

それを試すのが↓になる (バージョン 0.0.1)。

《simbd/test_of_inheritance_2.py at master - JRF-2018/simbd》
https://github.com/JRF-2018/simbd/blob/master/test_of_inheritance_2.py

JRF2021/3/140336

↓もアップデートしておいた (バージョン 0.0.2)。

《simbd/test_of_inheritance_1.py at master - JRF-2018/simbd》
https://github.com/JRF-2018/simbd/blob/master/test_of_inheritance_1.py

JRF2021/3/144683

……。

扶養は木構造になるが、それが循環しないように注意しないといけない！

JRF2021/3/144398

……。

死んだときは扶養のはりかえは基本、相続割合のもっとも多い第一相続人が扶養を引き継ぐ形になるが、第一相続人としては自身が扶養されていないこと、18歳以上であることなどが必要になる。

父が死んだ場合、第一相続人が子供の場合は母は第一相続人にならないが、そうでない場合は母が第一相続人になるとする。ただし、母が18歳から70歳までの間にあることが必要。

JRF2021/3/141537

……。

成人して扶養から出るときは、0.5/子供の数 を資産にかけた「餞別」をもらえる。その後結婚したら同じだけの「餞別」をもらえる。結婚を機に扶養から離れたなら 1/子供の数を資産にかけた「餞別」をもらえる。…という感じにするか。

JRF2021/3/145645

……。

↓にさしあたり相続を入れ、扶養も少し入れておいた (バージョン 0.0.7)。

《simbd/test_of_matching_2.py at master - JRF-2018/simbd》
https://github.com/JRF-2018/simbd/blob/master/test_of_matching_2.py

ただ、老人になったとき扶養に入る、成人したら扶養から出る…というのはほぼやってないし、当然のごとく、養子などはまだ手を付けていない。

JRF2021/3/149069

……。

次はやっと「結婚」か、その前に「扶養」をもっと詰めるか…。

JRF2021/3/146496

……。

……。

○ 2021-03-01T17:19:41Z

結婚は、たとえばものすごい年寄りと10代の若者が結婚するようなことは避けたい。しかし不倫と同じアルゴリズムを使うと、まず不倫者を選ぶから、あぶれるものどうしが不倫するみたいなことが起こりうる。

そういうことが起こらないために、matching するとき、それぞれの好意が一定以上でなければマッチングは起こらないとしようと思う。

JRF2021/3/147735

これによりある年寄りは、何度も選ばれるが、同じくらいの年寄りがたまたま選ばれない限り結婚できない…みたいなことが実現できると思う。

まぁ、まだやってみないとそれでうまくいくかはわからないが。

JRF2021/3/146905

……。

結婚相手を選ぶときの asset_rank には、親の財産を少し加味する必要があるだろう。餞別をもらってないなら、その餞別分多めに計算するなどが必要。

あと、再婚の場合は、餞別をもらえない…みたいなことも考える必要がある。

JRF2021/3/143739

……。

……。

○ 2021-03-02T14:56:12Z

不倫から結婚への昇格の他に、結婚する時、不倫があればそれが一定確率(7割ぐらい？)で「清算」される…というのはやるべきだろう。

それにシステム的に似たこととして、「焼けぼっくいに火がついた」的に、過去に不倫した者とまた不倫の関係に入るということはある程度あることとして、実装することが考えられる。

JRF2021/3/146340

ただ、過去の不倫は結構数があることになるし、それをすべての人についてチェックするとなると、結構時間を食うのではないか。また、複数の不倫のどれも同じ確率で火が再びつくというのもおかしいし、多くある不倫の中から選ぶので確率を小さくすると、若者で火がつきにくいということが起こりうる。(まぁ、火がつくかどうかを先に判定し、その後、どの不倫に火がつくか選ぶ…というのもありかもしれないが…。)

まぁ、処理が格別難しいわけではないが、これについては、今回の実装は見送ろうかと思う。

JRF2021/3/149615

……。

難民がやってきて人口が増えるような状況を考えると、全人口の何割が結婚すべきみたいな決め打ちだと、一ヶ月の結婚が多くなり過ぎることが起こるかもしれない。そこで、増分の max を決めておいたほうが良いと思われる。

離婚は、社会で何割と決まってるから…という理由でなされる「社会的離婚」の他に、hate がたまったりして自然に別れる「自然離婚」を考えたい。これも、人口減などでたまたま結婚している人が減ったときに、離婚がゼロになるのもおかしいので、作るつもり。

JRF2021/3/148405

不倫については、同じような考え方を取り入れる可能性もあるが、なんとなくとりあえず今のシンプルなままでいいかな…と考えている。

JRF2021/3/149083

……。

自然離婚はもっとも hating がある状態(== 1.0)で 10年で10%、hating が 0.0 で、30年で5% ぐらいでいいのではないか。hating が高いほうが効きやすくするため hating ** 2 に関してそういう値になるようにしたらいいのではないか。

自然離婚したあと、離婚するぐらいだから hating があったものとして、0.3 ぐらい hating を与えるが、一方、hating がもとで離婚に致っている場合は、離婚したことでスッキリしただろうということで hating を下げるのがよいだろう(0.3 まで下げる？)と思う。

JRF2021/3/142335

……。

……。

○ 2021-03-03T15:21:49Z

「焼けぼっくいに火がついた」的なものはやろう。

それで気がついたのだが、以前または今の不倫相手とたまたま新しく不倫すると選ばれたときの処理を書いてなかった。

前は、不倫の期間はひきつがない…としていたが、前の不倫の半分の期間を引き継ぐことにしよう。少し、データに整合性というか正直さがなくなるが…。

JRF2021/3/146094

……。

…と思ったが、「焼けぼっくいに火がついた」以外の場合の新しい不倫の重なりについて、すべての新しい不倫にてついて過去の不倫を調べるのは時間を食い過ぎると思う。だから、「焼けぼっくいに火がついた」以外の新しい不倫については、過去の子供の情報は引き継がないし、不倫期間も引きつがないこととする。

JRF2021/3/146571

「焼けぼっくいに火がついた」場合も、過去の子供の情報は引き継がないこととする。必要なときは、必要なときに過去の子供との関係を全部さらうということで。ただし、不倫の期間は、前の不倫の半分の期間を引き継ぐことにしよう。

JRF2021/3/144547

……。

「焼けぼっくいに火がつく」のは、不倫または結婚している場合は 10年で 10%、そうでない場合は、1年で 10% とする。

さらに火がつく相手が、結婚か不倫している場合、火がつく確率は 50% とする。50% と高いのは、火がつくと選ばれること自体がまれな「幸運」なので。

火がつくと決まったあと、どの関係が再燃するかは、昔の init_favor とその関係の存続期間を加味して決まることにする。rellist が関係のリストとして、

JRF2021/3/148084

l2 = [0.1 + math.log(1 + x.end - x.begin) \
* np_clip(x.init_favor, 0, 10) for x in rellist]

を元に決める。

今の favor ではなく、昔の favor を使うのは、そのほうが速いから。まぁ、昔の思い出で火がつくあたりは少しリアリティもあるかもしれない。

JRF2021/3/142223

……。

↓、「結婚」はまだだが、「焼けぼっくいに火がつく」は実装した (バージョン 0.0.8)。

《simbd/test_of_matching_2.py at master - JRF-2018/simbd》
https://github.com/JRF-2018/simbd/blob/master/test_of_matching_2.py

JRF2021/3/149943

……。

……。

○ 2021-03-04T19:10:31Z

「火がつくと決まったあと、どの関係が再燃するかは、昔の init_favor とその関係の存続期間を加味して決まることにする」というところの式。

JRF2021/3/143663

l2 = [0.1 + math.log(1 + (x.end - x.begin) / 12) \
* np_clip(x.init_favor, 0, 10) for x in rellist]

…に替える。今後も替わるかもしれないで、詳しくは今後ソースをご覧あれ。

JRF2021/3/140094

……。

資産・所得は家族単位で見ていくことのになるが、計算に上限を使うものは上限を家族の数によって増やさねばならない。ただ、まるまる倍になる…とかはおかしい気がするので、一人用の上限を X、家族の数を n とすると家族での上限は X * (1 + 0.25 * (n - 1)) ぐらいにする感じか。

だからこそ、上限を突破するために、このシステムでは扶養からの独立が求められるのかもしれないな…。

JRF2021/3/147942

……。

結婚誘度、結婚好意度(、別れやすさも？)を決めるにあたって注意しなければならないのは、結婚が不倫と違って公的関係であり、体裁を非常に気にするということ。

資産の多さが、教育でスポイルされることはない。教育そのものは高く評価されるかもしれないけど。誘度の計算のとき、教育の最大が 0.2 の効果で、資産の多さの最大が 0.3 の効果だとして、その和ではなく、その最大値が取られる感じか。

JRF2021/3/142631

そしてそれらより何より、年齢が釣り合ってることが重視されるだろう。年齢が離れ過ぎているのは、評価がマイナスになっていい。

初婚どうしが非常に好まれ、不倫経験はマイナス(は言い過ぎにしろゼロ)にしかはたらかないだろう。いや、ほどほどの adult_success は魅力には若干プラスにすべきか…。誘度の計算のときは結婚を嫌って若干のマイナス、好意度の計算のときは若干のプラスかな。

JRF2021/3/147359

幸運の要素も不倫より少なくていい。

誘度については、誰しも結婚のチャンスがあるようにあまり差をつけないほうがよいだろう。若いほうが結婚のチャンスが多い…ぐらいの感じか。

誘度での選抜はゆるめに多めに選んで、前書いたように matching の際に favor に threshold を設けてかなり落とす感じがいいのではないか。

JRF2021/3/147371

……。

……。

○ 2021-03-05T09:58:10Z

↓、「結婚」を実装した (バージョン 0.0.9)。実行にそれなりに時間がかかるので、バグ取りがたいへんだった。当然、バグは取り切れていないことが予想される。

《simbd/test_of_matching_2.py at master - JRF-2018/simbd》
https://github.com/JRF-2018/simbd/blob/master/test_of_matching_2.py

JRF2021/3/142219

やってみて、人口の増減がうまいぐあいにいかない。妊娠がらみのパラメータをいじってみても、うまくいかない。とにかく、初期の老人人口が多過ぎて、人が死に過ぎるのが問題のようだ。でも、たまたま老人人口が多いことはありうるはずだし、それに対応できないというのがもどかしい。

ただ、長く回していると(-t 1200ぐらい)、最初は老人の死に過ぎで人口減だった社会が、一世代たつと人口増に転じるのは確認できた。

これでヨシとすべきなのか。

JRF2021/3/143279

ただ、見てると欲しい子供の数が大きく影響していると見えないのも問題があるように思う。妊娠待機(pregnancy_wait)を欲しい子供の数に連動させてみてはどうだろう…とか考えるが、反応が遅くなるだけの気がするし…。結婚の割合や不倫の割合を増やすのも妊娠には本質的変化があるように見えない。

次は、養子のシステムか。それを入れると、欲しい子供の数に影響があることで、人口増にほんの少し転じにくくなるはずだが、それでどうなるか…。

JRF2021/3/149431

……。

……。

○ 2021-03-06T13:18:20Z

扶養について考える。

困窮した70歳以上の老人は何者かの扶養に入る。このとき、困窮しているかどうかの条件は、老人が扶養している家族がある場合、家族平均 asset_rank で見ればよいだろう。

誰に扶養されるかだが、子供がいる場合は最も裕福な子供に扶養されるべきだろう。子が死んでいるが孫が成人していれば孫でもよい。

JRF2021/3/145285

こういうふうに子供がいる場合の老人の扶養は、困窮してなくてもあってよい。とにかく70歳以上で子があれば、扶養に入る形でいいのではないか。

問題はその子が死んだとき。普通に考えれば、その子に兄弟がいれば、その扶養に入るべきだ。が、それが簡単にできるように今はなっていない。死亡時の扶養のアルゴリズムを見直す必要がありそうだ。

JRF2021/3/147296

子供がいない困窮した老人は、養子を取るなどする必要があるが、単に誰かの扶養に入るでもいいかもしれない。できるだけ裕福な、親の死んだ者の扶養に入ればいいのではないか。そのマッチングを行うべきだろう。

JRF2021/3/142361

……。

扶養に入る老人は常に70歳である必要はない。親のいないものが必ず老人を扶養する必要はない。

確率的に扶養されてない老人を選び(10年で70%)、確率的に親のいない若者を選び(10年で50%)、前者のうち、家族が扶養できるものは扶養する。そして残りの前者と後者の少ない数で前者は困窮している者から順に、後者は裕福な者から順にマッチングすればよいのではないか。

JRF2021/3/147028

……。

親が死んだ未成年の子は、早急に扶養者を探さねばならない。この未成年の判定は、10歳未満にするか、15歳未満にするか…。15歳になれば、扶養から離れてよいとする。結婚ができるようになるから。まぁ、15歳までは扶養は必要とするか。ただ、親のある被扶養者が成人するのは18歳とする。

JRF2021/3/148338

扶養者はできれば近親者がいい。これは相続のツリーを辿っていけばよいか。それで、適当なものがいない場合は、裕福な子供が欲しい若い家族の養子になる…ということで。…いや、不倫の子である場合があるから、すでに実装した supporting tree の引き継ぎでうまくいかなければ、相続のツリーを辿るというのは正しくないかな…。

子供の場合は、単に被扶養者になるだけでなく養子になるべきだ。ただ、10歳以上15歳未満の子供の場合は、養子にはならず単に被扶養者になるだけにするかな…。

JRF2021/3/141112

……。

養子に出されると、死んだ子のように trash に保存されることなく削除されるようにするか。そうでないと相続が得になりすぎる。

JRF2021/3/148973

……。

貧乏になったりしたとかで、欲しい子供の数より子供の数が大幅に大きく(2.5人多い)なった場合は養子に出してもよいだろう。

これも必ずではないので、10年で50%ぐらいの確率的に…とするか。ただし、養子になりうる10歳まで…と。

それを受け容れるのは、裕福で子供のいない家庭…ということだが、支配階層があれば、子のいない支配階層の家庭のほうがありうる話か。

JRF2021/3/142013

早急に親が必要な養子と違い、この場合は、養子を取る側がかなり選別されるべきだろう。子がいなくてしばらくたった家庭で、上位5割の家庭のうち10年で50%くらいの確率で選ばれるとするか。

そして、確率的に選ばれた者どうしで、少ない方の数でマッチングする。この場合は、裕福な家の子供は、裕福な家にもらわれるという形にすればよいのではないか。

JRF2021/3/146344

……。

扶養に入った老人は、その半分の財産を扶養者に渡すべきではないか？ なぜなら、一度、扶養に入った老夫婦が離婚することになったとき、一方の老人が扶養から出ていくが、そのとき財産のほとんどをもっていくのは、都合が悪いため。

でも、そうすると、扶養する者が他の兄弟より有利になり過ぎるか。結婚のときの「餞別」で十分とすべきだな。

JRF2021/3/140147

……。

あと、扶養に入れるときは hating の有無を確かめるべきだな。本人だけでなく、その supporting の中にも新たに扶養に入る者への hating が 0.2 以上ないことが条件とするか。そうでないと、離婚して離れていった親の両方を扶養するようなことが起きてしまう。

JRF2021/3/148060

……。

……。

○ 2021-03-07T16:02:45Z

↓、養子や老人の「扶養」を実装した (バージョン 0.0.10)。-t 1200 で正常終了はしたが、やはり、バグは取り切れていないことが予想される。

《simbd/test_of_matching_2.py at master - JRF-2018/simbd》
https://github.com/JRF-2018/simbd/blob/master/test_of_matching_2.py

JRF2021/3/147978

親が死んで扶養されていない子供については、受け容れる側が少ない場合、欲しい子供の数に関係なく受け容れることがあるものとした。

扶養されてない者、結婚している者、18歳から50歳までの者、子供が欲しい者…と順に扶養すべき子供がそれより多いか確かめて、受け容れる側の対象とするようにした。

それ以外はだいたいこれまで書いたことを参考に実装したが、せっかく導入したのにいろいろな「制度」を利用される数があまりにも小さい。このあたり、数値の微調整がもっと必要かもしれない。

JRF2021/3/144860

……。

そういう「微調整」が必要なものの、test_of_matching_2.py は当初の目標に達した。

この次は、新たな「プロジェクト」として、test_of_matching_2.py のファイルを分割したあと、test_of_merchant_peasant_ratio.py と test_of_income_1.py の成果を家族単位の経済として統合するつもり。

JRF2021/3/141242

……。

気付いていてやってないこととして、地域(district) の変更の際に土地を持っている場合、その土地を持っていけるというのはおかしいから、何か対策をしないといけない。土地を全部売ってから移動すべきなのか、それとも着いた先でも土地を買うとすべきなのか…。

JRF2021/3/148644

……。

……。

○ 2021-03-08T12:02:50Z

「余った子」を養子に出して受け容れる…確率とかって、sqrt をかけぐらいしてやっとサイズ感が出てくる。でも、2万5千人の人口で、1年ならいざしらず1ヶ月で5人とか10人とかそういう子が出るのが「正しいか」と言われると…違う。1年で10人ぐらい…とすると、まぁ、確率的に間違っていないのかな…という気はする。

JRF2021/3/144361

問題は、それに比べて、結婚・離婚・不倫が多いことなのだと思う。これは私が不倫のアルゴリズムから作りはじめて、まずハッキリとした数字が欲しいことから多めに設定していたからそうなっているのだと思う。確率について1年の数字とすべきところを1ヶ月の数字にしている感じ。

JRF2021/3/143796

特に離婚が多いのが気になる(離婚数の表示は結婚数に比べて約2倍の単位にはなるのであるがそれにしても)。しかし、離婚の数を減らすには私のモデルでは結婚を減らすしかない。そこで、結婚については、新規結婚を選び出す数をかなり少なくした。threshold があるので、そこまで少なくするとマッチングがうまくいかないのではないかと思っていたが、結構数は確保されている。少しおかしい気もするが、うまくいってるのでよしとしよう。

JRF2021/3/143741

不倫は削り過ぎると、「堕胎」を結婚から出す数が多くなるため、不倫というマージンはある程度ないといけない。そのためには、本当は、新規不倫を減らすべきではないのだが、25000人のうち 1000組以上の新規不倫は多過ぎるので、それをゴソっと減らすかわりに、不倫し続けてる人の数を増やすことにした。

JRF2021/3/146805

元が、

ARGS.adultery_rate = 0.11
ARGS.new_adultery_rate = 0.22
ARGS.marriage_rate = 0.7
ARGS.new_marriage_rate = 0.8

…だったのを…

JRF2021/3/141213

ARGS.adultery_rate = 0.20
ARGS.new_adultery_rate = 0.22
ARGS.marriage_rate = 0.768
ARGS.new_marriage_rate = 0.77

…という数値にしてみている。

副作用として、マッチングにかかる計算コストが下がりシミュレーションが終るのが早くなった。

JRF2021/3/144545

……。

……。

○ 2021-03-09T07:52:04Z

作る方は勢いで作るからある意味簡単だけど、評価する方は大変だよ。海のものとも山のものともつかないこのコードを無数のコードの中から選び、まだ発展途上のコードをほぼ何のガイドもなく読みとくわけだから。

だから、基本的には、評価してくれる人が現れなくても、それが普通ぐらいに考えて、プロジェクトを進めていかなくてはいけない。現れたら、僥倖以外の何ものでもないということ。

JRF2021/3/149588

……。

……。

○ 2021-03-09T10:24:22Z

「余った子」を養子に出して受け容れる…確率。出す側は10年で50%ぐらいの小さい確率のままだが、受け容れる側は10回に一回は手を上げる確率にした。これ、受け容れる側を必ず(確率1.0で)手を上げるようにしても、ほとんど養子が成立しないので、これでいいかと思う。

JRF2021/3/148716

……。

↓、細かい修正をしたり、表示を増やしたりした (バージョン 0.0.12)。

《simbd/test_of_matching_2.py at master - JRF-2018/simbd》
https://github.com/JRF-2018/simbd/blob/master/test_of_matching_2.py

何も思いつかなければ、そろそろ↑をファイル分割した simbdp1 (Simulation Buddhism Prototype No. 1)を作るつもり。

JRF2021/3/143089

……。

……。

○ 2021-03-10T13:39:28Z

↓、近親結婚の忌避を入れるなどした (バージョン 0.0.13)。

《simbd/test_of_matching_2.py at master - JRF-2018/simbd》
https://github.com/JRF-2018/simbd/blob/master/test_of_matching_2.py

まだ、やるべきことがあるのかも。simbdp1 は1週間ほど待ってからかな…。しばらく、休息にして、オペラ DVD でも観るのが吉なのかもしれない。

JRF2021/3/142719

……。

相続割合の計算において、半血・全血に対応するため、家系図に複数回現れる人物の割合は和を取ることにした。前は max を取っていた。ただ、これにより、姪の子なんだけど妻である場合などにおいて、若干、相続割合が増えるようになった。実務においてはどうなるのだろう？

JRF2021/3/146047

……。

近親結婚の忌避。このためだけに新たな情報 initial_father と initial_mother を足したのだけど、養子の離縁には記録する情報の不足で対応できなかった。

あと、このアルゴリズムは結構時間を食うはず。…のわりには、そこまで実行時間に影響してない。だいたいすんなりいくんだが、時々一時止まることがあるのは、ガーベージコレクションにでも引っかかっているのだろうか？

JRF2021/3/141749

時間を食うわりには、ほとんどこれで reject (忌避に引っかかる)されないんだよね。だから、時間が問題だったら、このルーチン削ってもいいと思う。

近親結婚の忌避のテストのようなものは↓に書いた (バージョン 0.0.1)。

《simbd/test_of_marriage_1.py at master - JRF-2018/simbd》
https://github.com/JRF-2018/simbd/blob/master/test_of_marriage_1.py

JRF2021/3/142801

……。

……。

○ 2021-03-11T15:07:32Z

↓、細かい修正をした (バージョン 0.0.14)。

《simbd/test_of_matching_2.py at master - JRF-2018/simbd》
https://github.com/JRF-2018/simbd/blob/master/test_of_matching_2.py

JRF2021/3/140060

まず、「自然離婚」について、初期化すぐの相手が不明な結婚の場合、判定が1/2になるのを修正した。ただその場合単純に 2 倍にするのも全体数がおかしくなるかと思い、√2倍にしておいた。

次に、養子の際に離縁の情報を残すようにして、近親婚の結婚判定を少し改善した。ただし、処理が重くなり過ぎているのを嫌っているのもあるし、正確じゃないかもしれないがそれぐらいいいだろう…というのもあって、養父との結婚・養父の実父との結婚はダメだが、養父の養父との結婚などは可にしてある。

JRF2021/3/142467

離縁の情報を残すようにすれば initial_father や initial_mother の情報はいらなくなるかと思ったが、三親等内の傍系血族のチェックに必要そうだし、あるほうが正確ではないが速い部分もあるので残っている。

あと、望まない子で「堕胎」しない子が出た場合、欲しい子供の数をすぐ増やすようにしてたんだけど、少し余裕を見て増やすようにした。もうちょっと余裕を見て増やすようにすべきか様子を見ているところ。ただ、欲しい子供の数で、全々コントロールできてない様子なんだよね…。

JRF2021/3/149770