多重カードゼロの超ユニバーサル系図ソフト

▲Z木家系図 基準ノード=#104 藤壷の宮を開いて,系統並び替えの出口検査で垂直スプリットが検出された 

この問題は2021/01/23 InvestigateVSplits 垂直スプリット発生 で既出している.このときは,重婚クラスタ循環が存在する場合には,ShiftDirectAbsoluteを実行しないということで切り抜けたが,多重カードが存在する場合にもShiftDirectAbsoluteを実行するというのが現在の方針なので,別途対策を考えなくてはならない.垂直セグメント検定が廃止されたのは2018/02/26でコードは残ってはいるが,もう一度復活させるというのは上策とは言えない.

セーフティネットとして整備しておくという考え方もあるとは思われるが,TestVerticalSegmentを実行するためにはかなりの下部機構を再整備しなくてはならないので,コストパフォーマンス的に引き合わないように思われる.すでにクラスタ循環が存在する場合でもクラスタを世代分割して対処する方策が編み出されているのでその方向で収拾を図るべきだろう.問題を解析してみよう.

4段目(物理世代3)にスプリットの入った図面を与えられた絶対世代番号に従って描き直してみると下図のようになる.光源氏(1)は絶対世代番号3を持っているのでちょうどスプリットで空いた部分に配置される.

image

上図のような結線が許されるのなら,ShiftDirectAbsoluteを使って絶対世代番号に準拠した配置を実現できるが,果たして可能だろうか?という前にこのような図式は妥当と言えるだろうか?異なる世代にある藤壷の宮→光源氏の結婚連結線をどう引くかというのが問題だ.図を観察してみよう.結婚点◆が藤壷の下にあり,◇が光の下にあって,この2つのマークを線分が連結するというのが上図の構図だ.

もし,これが許されるのなら,これまで問題にしてきた,「婚姻当事者は同世代に配置されなくてはならない」という原則を大幅に逸脱することになる.つまり,「婚姻当事者の世代は問わない」ということになり,それを聞いて大喜びする人もいるかもしれない.もともと,重婚クラスタに循環が生じない限り異世代婚姻というのは許容されてきた.しかし,これが上図のようなところまで緩和されると,もはや「多重カードの発生要因は存在しない」という世界が実現することになる.

これでよいのだろうか?ゼルコバの木はこれまでも Politically/Socially Neutral という立場を保ってきたが,「一般に世代差のある婚姻にはつねに多少の問題がある」というのが開発者自身の個人的見解である.

しかし,逆にまた,一介の数理エンジニアとしての立場からすると,「多重カードゼロのユニバーサルな系図作成ソフト」を実現するというのはチャレンジングな課題であり,大いに興味をそそられるところがある.上の図面を見た限りでは,テクニカルには実現困難であるようには見えない.世界中のありとあらゆる系図図面が多重カードなしで描画できるとしたら,確かにそれは画期的なことであるような気がする.少なくともわたし自身はそんなものできる訳がないと考えてきた.

図形言語として考えた場合には,世代差のある結婚においても連結線はつねにある結婚点◆と他の結婚点◇を結ぶものであり,(結婚点を一回だけ通る)親子連結線と読み間違えられる可能性はないという点において文法的には正当と言える.実現可能性を考えるために,具体的に構想設計してみよう.これは両手に花技法の一種の拡張である.

BTW(Between Two Women)は「両手に花」と呼ばれているが,2つの結婚を扱うものではなく,対象となる結婚枠はつねに一つだ.つまり,カードR,カードLという本人ポジションのカードが2つあり,両者の間に結婚M=L+Rが存在し,MがRの下で展開されているとき,配偶者M.spouse=(L)を消去してLとRをBTW連結線で結ぶというのがBTWの作法だ.このような結婚枠をBTW右手結婚枠,Lを左手本人,Rを右手本人,消去されるM.spouseを右手婚配偶者と呼んでいる.

ここで右手婚配偶者を消去しなかったらどうなるか?右手配偶者を消去しないというのはその下に垂線を配置するための空間をリザーブするためだ.この可視の右手婚配偶者を抽出枠でラップして垂直にシフトし,左手本人の世代まで下げることまではできそうだ.そこまでできれば,あとは抽出枠チェーンを通る垂線を描画し,左手本人の結婚点と連結する水平線を描画すればよい.拡張BTWでは右手本人/左手本人の代わりに上手本人/下手本人と呼ぶことにしよう.拡張BTW(XBTW)構成のおおまかな手順は下記のようなものになる.

  1. 世代差のある結婚Mが存在する場合は,Mのownerを上手本人,spouseを下手本人に切り替え,Mを上手本人の拡張枠に移動してXBTW上手結婚枠とする
  2. 上手婚配偶者だけを含む抽出枠を生成し,下手本人世代までシフトとしてその間を長い尻尾で接続する
  3. 描線は,①上手本人結婚点→抽出枠中心線までの水平線,②下手本人結婚点の高さまでの長い尻尾垂線,③下手本人結婚点→抽出枠中心線までの水平線の3本
  4. 2つの結婚点のどちらが◆となり,どちらが◇になるか,つまり結婚枠のholderがどちらになるか,また,水平連結線を通すチャンネルの確保は系統並び替え出口のCheckAtypicalMarriageで実施する

方式的にはこれしかないような気がするのだが,その場合厳密には上掲したような図にはならないと考えられる.これは配偶者は一般に本人の左側に配置するというのがZTでの決まりになっているからだ.描き直してみると下図のようになる.

image

図式的にはこれで通るとは思われるが,水平線の途中から唐突に分岐するというのも意味論的に判り難いところがあるので,おそらく下図のように描画することになるのではないだろうか?

image

XBTWというのは相当程度特殊なものであり,出現する可能性もまれであると思われるので,BTWとは別に完全に独立のコードとしてもよいのではないか?最後のCheckAtypicalMarriageだけは共通化するしかないが,この方が扱い易いのではないかと思う.問題はこれだけの仕掛けですべての場合をカバーできるかどうか?という点だ.実際,世代差のある結婚がかなり離れて存在する場合があり,その中で上手本人と下手本人を結ぶ垂線がつねに描画できるかどうかという点も微妙だが,その辺りは,まぁ,やってみなければ分からないとしておこう.

ZTが「多重カードゼロの超ユニバーサル系図ソフト」に生まれ変わるかどうかという瀬戸際だが,先に進む前に一つ片付けておきたいことがある.重婚グラフと呼んでいるものは重婚クラスタを節点とし,親子関係を枝とする(非循環的)有向グラフだが,その具体的な形姿をZTを使って画面上で見てみたい.方法としては,系図情報をCSV形式で出力し,別アプリで開くということが考えられる.DLLからVBに一覧表データを送るときの形式はすでにタブ区切りデータになっているので,それをファイルに直接出力するだけでよいのではないかと思う.

一行分のレコードの内容には,番号,氏名,性別,よみ,所属,肩書き,郵便番号,電話番号,現住所,生年月日,没年月日,本籍地,婚歴,生没,血液型,干支,星座,出生地,携帯番号,E-mail,父母数,父番号,母番号,続き柄,配偶者が含まれるが,重婚クラスタの親子関係は単身婚なので,必要な情報は

番号,氏名,父母数,父番号

だけと考えられる.従って,重婚クラスタグラフを出力するのはそれほど難しくないはずだ.重婚クラスタの中身は人名カードのリストなのでその情報もほしいところだが,代表ノードの名前を氏名欄に出力しておけば,多少の手がかりにはなるだろう.

重婚クラスタグラフ出力用の専用関数としてTOPOLOGY:SaveClusterGraphを作ってみたが,まったく動作しない.一つには一覧表データとして送っているデータの列の並びとVBでエクスポートしているファイルの列の並びが一致していないという問題があったが,それだけでなく,そもそも現行バージョンでエクスポートしたファイルをインポートすることができない.インポート・エクスポートに関わるロジックは一度作ってからはまったく触っていないはずなのだが…

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA