トップ «前の日(04-15) 最新 次の日(04-17)» 追記

Orz日記 by Akio Morita

ToDo:

  • 15 SAD Fit[]回りの障害事例の解析
  • 10 smart pointer版PEGクラスの再実装(Left Recursionまわり)
2006|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|06|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|07|08|09|10|11|12|
2013|01|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|06|07|08|10|12|
2016|01|02|03|05|06|08|10|11|
2017|01|02|03|04|05|06|07|09|10|11|12|
2018|01|02|03|04|06|07|08|09|10|11|12|
2019|01|03|04|05|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|10|11|

2008-04-16

_ [SAD]日報、未初期化変数参照の警告

warning: 'foo' may be used uninitialized in this function警告の調査完了

ソース警告数
src/phsrot.f 1
src/tcsvdm.f2
src/temit.f 3
src/tturn.f 1

後処理

  • src/tcsvdm.fの警告
    • s=c=sqrt(1/2)な極限の発生を仮定して zc初期化コード挿入とアサーション追加
    • アサーション挿入して、zc0へ初期化
  • src/tturn.f
    • 動作が怪しそうなので、TrackParticles[]でテストケースを書いて動作検証
    • 本当に問題が発生するならバグレポート書く
  • src/temit.f
    • バグレポートを書く
  • ひたすらCVS MAIN trunkへバックポート

まずは、バックポートを処理するかな

_ [SAD][Fortran]gfrotranのオプション

-finit-real=[zero|nan|inf|-inf]なるオプションが有る!

gfrotranビルド時は、-finit-real=nanでもつけておくか?

_ [SAD]src/phsrot.fのマジックシンボルi_p0

コメントsrc/bb.fのコピーっぽいので i_p0533ではないかという意見が出ているが、 BEAMBEAMエレメントのblist構造は長さ600だが、 PHSROTエレメントのblist構造は長さ240しか無いので、 明らかに違う。

正しいi_p0は、1から240までの整数のはず。 また、phsrot関数内の定数nblist(おそらく、blistの 長さを与える定数として導入されたと思われる)の値が200で、 src/tpara.ftpara関数のラベル3700で確保している 配列長が240であることから見ても、以前の考察通り、 1995年に CVS repositoryが導入された時点で保守されていなかった& 死んでいたという仮説が正しいと思われる。

_ [SAD]本日のバックポート

  • コンパイラ警告の修正
  • Random[]の再実装に関連する、ヘルプファイルの改訂

次の作業はタグ打って 数学/物理定数の整理と物理定数更新(1627...1691) かな?

extensions/Standard/SpaceCharge/Scheffに関しては需要なさそうなんで、 バックポートせずに塩漬けの予定

_ [雑記]デジタル化された著作物の著作権

昨今、いろいろなところでネットワーク上に流れるデジタル化された著作物の 著作権がらみの問題が報じられているが、昔から私が持っている疑問が有ります。

「表現をデジタル化(量子化)した著作物のあり得る数加算無限個に制限されるのでは?」と言うものです。

議論を簡単にするために、 全ての「US-ASCIIで符号化された有限長の文書」を含む 集合Xを考えます。

まず、集合の個々の要素は有限長の符号列で符号体系はで離散符号なので、 適切な定義を行えば集合は全順序集合になります。

集合Xの元xの長さをLength[x]'、 長さN以下の符号のみで出来たXの部分集合をX(N)として、 関数Order(x)を部分集合X(Length[x])を短い符号列が前に くるようにstrcmpで整列させた時にxの前から数えた順位を 返す関数として定義します。

したがって、集合Xの任意の元x,yに対して

  • Order(Null) = 1
  • Order(x) = Order(y) <-> x = y
  • Order(x) < Order(y) <-> x < y

が成り立ちます。ここで、Nullは長さ0の符号列です。

集合Xの任意の元は自然数と一対一に対応付けられます。 したがって、集合Xの濃度は加算無限(整数や有理数と同じ)です。

この著作物符号化空間内での著作権の侵害の可能性を考えてみましょう。 議論の単純化のために、著作権の消滅などは考えずに、純粋に 互いの著作物が侵害する恐れが有るか無いかを判定する 関数Conflict(x,y)を 「xyを侵害する可能性がある場合にtrueを返し、 そうでない場合にfalseを返す」と定義します。

これを使って何をやるかというと、早い話が「エネラウスの篩」です。 まず、既知の著作物集合A_0を用意します。 ここで、「∀a∈A_n, Conflict(x_n, a) = false」満足する Xの元x_nを用いて、 集合A_nの漸化式「A_{n+1} = A_n ∪ {x_n} 」を定義します。 さて、Xの元は加算無限個しか存在しないので、元x_nは 順位の小さい源から順に試していけば良いわけです。 しかも、A_nの漸化式の定義から「Order(x_n) < Order(x_{n+1})」が 満たされますから、一度検査した元を再検査する必要は有りません。 漸化式が、途中で止まるならもう新しい著作権侵害の恐れのない著作物が ないということです。

つまり、「任意の符号化著作物に対して著作権侵害を判定可能」 であるなら、衝突判定関数Conflictを構成可能で、 これを使って既知の著作物空間と衝突しない元からなる 部分集合X ∩ !A_0から発見済みの元(既知の著作物を含む)に 衝突しない元x_nを次々と選び出すことができると言うことです。

現実のリソースで表現可能な範囲は、集合Xの部分集合でしかなく、 ある十分に大きな自然数Mに対して現実のリソースで表現可能な Xの部分集合X*は、「X*X(M)」を満足します。 X(M)は、たかがか有限集合なので たかがか有限計算機リソースたかだか有限時間稼働させることで、未発見の元x_nを すべて発見出来ます。

つまり、極論すれば 「任意の符号化著作物に対して著作権侵害を判定可能」であれば、 「有限リソースで表現可能な符号化著作物空間を自動的に埋め尽くすことが可能」 であるということ。


カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記