2024年6月 – さあ，もう一度ゼロから始めよう

2024年6月20日2024年7月20日

サビ落とししてゼルコバの木を動かす

前にもどこかでこのような話題が出たことはあるが，どこでだったか覚えていない．G+＋をやっていた時期ではないかと思う．この時期には海外の系図研究者と活発な対話が成立していた．ゼルコバの木に入力してみようと思っのだが，動かない．サブ機にはコラッツ特注版というのが入っているが，起動時エラーになる．開発機に入っているのはこれとは別バージョンだが，フォントサイズを変更しようとしてエラーが止まらなくなってしまった．

開発環境でリビルドして以下のエラーになった．

2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\　Common7　\IDE\VC\VCTargets\　Microsoft.Cpp.WindowsSDK.targets(46,5): 　error MSB8036: Windows SDK バージョン 10.0.17763.0 が見つかりませんでした。必要なバージョンの Windows SDK をインストールするか、プロジェクトプロパティページで SDK バージョンを変更するか、ソリューションを右クリックして [ソリューションの再ターゲット] を選択してください。

[ソリューションの再ターゲット] を実行してビルドできるようになった．ビルドできた！実行してみよう．⇒問題なく起動できた．氏名を入力すると下の欄に１０という数字が表示されている．多分コラッツ版で入れたものだろう．⇒配偶者を登録し，配偶者に未婚の子どもを入力して例外が発生した．

▲配偶者に連れ子を入力して例外が発生した．GP例外のようだ．いや，TRIBEBOX::StartTribe でスローしている例外だ．group()が空でないために論理エラーとみなされている．MakeUpTree→SortTribeList→StartTribe というシーケンスだ．SortTribeListでは始系列を取り出そうとしているので，動作が矛盾している．⇒暫定的に止めて動作するようになった．

人名枠の中身を出力しているところを探さなくてはならない．関数名を忘れてしまった．NameBox.cppというのがある．PrintParameterでパラメータ類を出力している．

▲所属を表示しようとして停止した． Bobject::setClipRegionでマッピングモードがMM_TEXTになっているためだ．

間取り図、青写真・設計図、テキストのグラフィックのようです

2024年6月13日2024年6月13日

デルタ多面体を三角錐に分解する

デルタ多面体を三角錐に分解する問題：任意の多面体をデルタ多面体に転換することは容易に可能だが，多面体→デルタ多面体の変換には多義性がある．つまり，デルタ多面体には三角錐に分解できるものとできないものがある．それをどのように識別するか？それが問題だ．平面グラフと多面体は等価であると考えられるので，グラフ理論上の問題として考えるのが妥当かもしれない．平面グラフについて少し考えてみよう．

①平面的グラフ：平面的グラフは球面など種数０の曲面に描けるグラフと同値である．②平面グラフにおいて，辺で囲まれた極小な領域を面という．有界な面を有限面，そうでない面を無限面と呼ぶ．③オイラーの公式：種数gの曲面S上に描かれた連結グラフがSをf個の領域に分割しているとき，|V|-|E|+f=2-2g．③ワグナーの定理：グラフが非平面的であるのは，K3,3またはK5を部分グラフとして含むときかつそのときに限る．④クラトフスキーの定理：グラフが平面的グラフであるための必要十分条件は５角形グラフあるいは６角形グラフに縮小し得るようなグラフを元のグラフが含まないことである．⑤四色定理：平面グラフは４色で彩色できる．⑥２連結３平面正則グラフは１因子分解できる．これは四色定理と同値．

外平面的グラフ：すべての頂点が無限面の回りにくるように描ける平面的グラフ．このうち，辺集合が極大となっているものを極大外平面的グラフと呼ぶ．極大外平面的グラフには切断点がなく無限面以外の面がすべて三角形になるように平面描画できる．

タットの定理：グラフGが完全マッチングを持つのは頂点集合Vの任意の部分集合Uに対し，V-Uの導出部分グラフの奇数個の頂点を持つ連結成分の個数が高々|U|であるとき，かつそのときに限る．→ガライの補題

2024年6月1日2024年6月2日

基数が２のときの動作がおかしい

基数が２のときの動作がおかしい．２は素数なので(n-1)/zの値はきっちりｐにならなくてはならないはずなのに，端数が出ている．⇒2^kでk=7の場合と，14の場合で不一致が発生している．⇒2^7をダンプして末尾ゼロを目測でカウントしてみたところ，１２７あった．この数字は正しい．TrailingZeros が返してくる値は１２６で１小さい．どこかで桁落ちなど起きているのだろうか？

primeExponentが返してくる値が，１２６になっている．

n=128, p=2, k=6, e=64+32+16+8+4+2=126

どうも，対数関数のlogが誤差を出しているようだ．

p=2 n=128 log　=6.999999999999999999999999999999999999999999999999999999999999999999999999999931

この値のfloorを取ると６になってしまう．これは本来７でなくてはならないのではないだろうか？2^7=128だから，log_2(128)=７でなくてはならない．これを回避するにはどうすればよいか？logの引数をBigFloatにしてみたが，効果なし．logの値をBigFloatで受けるようにしてみたが，同じ．BigFloatの精度は256もあるのに，計算値は８０桁くらいしかない．⇒やった！primeExponentの冒頭でsetprecision(BigFloat, 512)を実行したら，log=

7.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006

という値が取り出せた．これでrも1.0に落ち着いた．とりあえず，これでよいということにしておこう．⇒この計算誤差は他の数値でも出ている可能性がある．チェックしておこう．⇒数値には変化はなかった．