Midnight Floating Thought

前回 ( abc予想と昔考えたこと )は、素数次円分多項式はその素数が7以上ならばabc予想の仮定の下で平方以上の素冪の値を高々有限回しか取らないということを示した。 素数次以外も同様のことが証明できる、というのはまあ読者の練習問題でもいいのだが、せっかくなので書いてみることにする。 $m$ を合成数とし、$\phi (m)$ が $6$ 以上(つまり $m=4,6,8,10,12$ 以外)と仮定しよう。 $m$次円分多項式 ${\mathrm{\Phi }}_m(X)$ が、$x$ で素冪の値 $p^n$ を取ると仮定する。ここでもちろん $n\ge 2$ である。 円分多項式はよく知られているように $X^m-1=\prod _{d|m}{\mathrm{\Phi }}_d(X)$ を満たすので、 $$x^m-1=p^n\prod {\mathrm{\Phi }}_d(x)$$ と書ける。ただし、右辺の積は $d=m$ 以外の $m$ の約数に亘る。 $x$ と右辺の各因子は互いに素なのでabc予想が使える。 abc予想: 任意の $ϵ>0$ に対して, ある正の定数 $K(ϵ)\ge 1$ が存在して, 次を満たす: $a$, $b$, $c$ が互いに素な整数で $a+b=c$ を満たすならば, 不等式 $$max\{|a|,|b|,|c|\}\mathrm{少}\mathrm{し}\mathrm{余}\mathrm{談}\mathrm{を}\mathrm{挟}\mathrm{む}\mathrm{と}、\mathrm{前}\mathrm{回}\mathrm{も}\mathrm{そ}\mathrm{う}\mathrm{だ}\mathrm{っ}\mathrm{た}\mathrm{の}\mathrm{だ}\mathrm{が}、\mathrm{左}\mathrm{辺}\mathrm{は}\text{(}max\text{)}\mathrm{を}\mathrm{取}\mathrm{る}\mathrm{の}\mathrm{が}\mathrm{大}\mathrm{事}\mathrm{な}\mathrm{の}\mathrm{で}\mathrm{は}\mathrm{な}\mathrm{く}、「\text{(}|a|\mathrm{で}\mathrm{は}\mathrm{ま}\mathrm{ず}\text{(}|a|\text{)}\mathrm{か}\mathrm{ら}\mathrm{使}\mathrm{お}\mathrm{う}。\text{[}{x}^m\mathrm{次}\mathrm{は}\text{(}|c|\text{)}\mathrm{を}\mathrm{使}\mathrm{う}。\text{[}{p}^n\prod {\mathrm{\Phi }}_d(x)\mathrm{式}\mathrm{変}\mathrm{形}\mathrm{を}\mathrm{簡}\mathrm{単}\mathrm{に}\mathrm{す}\mathrm{る}\mathrm{た}\mathrm{め}\mathrm{に}\text{(}ϵ=\frac{1}{m}\text{)}\mathrm{と}\mathrm{お}\mathrm{く}。\text{(}x\text{)}\mathrm{の}\mathrm{評}\mathrm{価}\mathrm{式}\mathrm{の}\mathrm{冪}\mathrm{は}\mathrm{次}\mathrm{の}\mathrm{よ}\mathrm{う}\mathrm{に}\mathrm{な}\mathrm{る}。\text{[}m-(m-\phi (m)+1)(1+\frac{1}{m})=\phi (m)-2+\frac{\phi (m)-1}{m}$$ 一方 $p$ の評価式の右辺の $x$ の冪は \[\epsilon m - \epsilon \varphi(m) + 1 + \epsilon = 2 - \frac{\varp...

gentoo と python と eselect と , dev-lang/python と /usr/lib/portage/pym , 0xF 0xB 0x31 0xFF と続いてきたシリーズも今回でひとまず終わり。 前回 libSystem.B.dylib で死ぬところまで見たが、 Gentoo Bugs #475284 では回避策の議論が進んだ。 eselect のコードでどこがこのバグを踏む原因になっているのかというと、 エラー出力のファイル記述子を置き換える辺りらしい。 決め打ちではエラーが起こるが、自動で振る機能は bash-4.1 以降の機能、というのが回避するコードを書く際の悩みどころだったようだ。 ともかく、対策済みのバージョンが eselect-1.3.6 としてリリースされた。 一件落着だ。 とはいえ、根本原因が塞がれたわけではないのでバグはまだオープンで、 バグタイトルが "app-shells/bash-4.2_p39-r1: "exec 3>&2" causes illegal instruction (seen with app-admin/eselect-1.3.5)" と大幅に変わって bash チームに投げられている状態である。

app-admin/eselect-1.3.5 問題の続き。 一応復習しておこう。 PORTAGE_ELOG_COMMAND で呼び出された gentwoo が eselect を呼び出したところで死ぬ。 環境変数を gentwoo に引き渡しておけば死なない。 Gentoo Bugs #475284 に報告してみて得た情報なども加味しながらもう少し情報を補足しよう。 環境変数が空っぽだと死ぬので env -i /path/to/eselect とすればいつでも再現できる、と主張したのだが、 これで現象が再現できるのは(少なくとも今のところは)私の Gentoo Prefix on OS X でだけである。 そもそも、eselect は bash スクリプトで、死んでいるのは具体的にどこなのか、と聞かれて core を吐かせることにする。 ulimit -c unlimited としておく(と core ファイルは /cores に core.PID という名前で残される)。 死んでいるのは bash の中だ。 bash 自体が死ぬような現象には遭遇した経験が無かったので、どうにもデバッグの糸口が摑めなかった。 とりあえず eselect の中に echo コマンドをいくつか挟んでみた。 どうも死ぬ場所は一定していないらしい(埋め込んだ echo が実行される前に死んだり、実行してから死んだりまちまち)。 とすると、むしろメモリーのゴミを踏んでしまっているか? メモリーエラーには valgrind。 ここでも環境変数を渡さないように env -i /path/to/valgrind /path/to/bash /path/to/eselect。 すると次のような出力を得る vex x86->IR: unhandled instruction bytes: 0xF 0xB 0x31 0xFF ==64989== valgrind: Unrecognised instruction at address 0x2a5ce9. ==64989== at 0x2A5CE9: _dispatch_mgr_invoke (in /usr/lib/libSystem.B.dylib) ==64989== by 0x2A4F58: _dispatch...