Dear Users,

1. The next version, V1.0.10.2.3b will gain a compatibility with the g95 compiler. Modifications are:

a) Separations of Type statements and DATA declarations.

b) No longer use FORTRAN READ for input, in most cases.

c) Rewritten a routine writeb for more efficiency.

The intem b) has been only tested with g95, but will be extended to other compilers soon.

ソース側の変更は精読していませんが、make framework側の変更関連で
意図がよく分からな点とか問題に成りそうなところを幾つか...
# commit logからも分りません(笑)

o SYS_FOPT/SYS_COPTの定義を ifndefを囲むのははぜ？
SYS_*OPT系は、ユーザーが定義すべきものでないオプション類を羅列するところなので
上書きを許す必要は無いと思います
# SYS_COPTの -pedantic-errorsで問題が出る場合は、ソースに問題があります
# SYS_FOPTの -ff90 -pedantic/-std=gnuで問題が出るならソースのスタイルが統一されてないためです

o config/GCC.specに _USE_G95が追加されていますが、_USE_*系変数(_で始まる変数)は
config/*.spec内部利用を意図してるので、ユーザーに公開するなら USE_G95=versionの形を推奨します
本格的に g95サポートを入れるなら mk/sad.compiler.mkにも手を入れるべきかと

o mk/sad.osdep,mkに追加された ifeq ($(HAVE_F_FGTEC),YES)はきちんと動きますか？
GNU make の conditional構文は制約が多く
if
if
else
endif
else
endif
の形式は分岐によっては、うまく動かなかったケースがあった気がするのですが...

o src/sim/fgetc_Dummy.fは、 fgetc実装前の gfortranで無理矢理 SADを動かす際に
作ったもので、改行記号までの入力行が長い場合や、他の read文との相互作用があった
場合に意図道理の動作をしない不完全な fgetcですが、実用に耐えられますか？

o SYS_DEPOBJ_FSEEKに sim/fgetc_Dummy.oを入れるのは邪道
fgetc_Dummy.oの必要性が version依存でないなら SYS_DEPOBJに直接書く
version依存なら _USE_*に g95の version番号を入れて SYS_DEPOBJ_FGETC変数を
version依存に定義して SYS_DEPOBJ+=$(SYS_DEPOBJ_FGETC)することを推奨します

o CVS repository内の oldsad/src/itfgetbuf_.c,vの アクセス権が正しく設定されていません

o Cによる itfgetbufの実装(src/itfgetbuf_.c)は read文と競合がある場合、一般には正しく
動かないと思われます。(Fortran I/O側の bufferingがあるため)
逆に、src/itfgetbuf_.cで問題ないなら、Fortran I/Oを捨てられるのでは？

>
> o Cによる itfgetbufの実装(src/itfgetbuf_.c)は read文と競合がある場合、一般には正しく
> 動かないと思われます。(Fortran I/O側の bufferingがあるため)
> 逆に、src/itfgetbuf_.cで問題ないなら、Fortran I/Oを捨てられるのでは？

　今回の変更で本質的なのはここだけで、Fortranのinputはもう使わないようになった(そうしなければg95には対応できない)ということです。ただ、他のシステムで動くかどうか確かめるために中途半端な状態になっています。

>
> >
> > o Cによる itfgetbufの実装(src/itfgetbuf_.c)は read文と競合がある場合、一般には正しく
> > 動かないと思われます。(Fortran I/O側の bufferingがあるため)
> > 逆に、src/itfgetbuf_.cで問題ないなら、Fortran I/Oを捨てられるのでは？
>
> 　今回の変更で本質的なのはここだけで、Fortranのinputはもう使わないようになった(そうしなければg95には対応できない)ということです。ただ、他のシステムで動くかどうか確かめるために中途半端な状態になっています。
>
だとすると、中途半端な Fortran fgetc()もどきを使わず、readstr()/writeb()系を
POSIXな system call + libcのみで書き換える方が目的にかなうと思います

#g95が、I/O INTRINSICで 最近の gfortranと違うのは ＧＣＣ 4.0.xで gfortranから g95が forkし
#g95 projectの目的が数値計算系で必要とされる機能の実装を優先しているためだと思われます
#fgetcのダミールーチンも GCC 4.0でのテスト用に書いたものですし...

手元の環境で、試している GCCのバリエーションとして llvm-gccを評価中
ICC程は早くないですが、一部のコードでは GCC 4.2.3よりも 20-30%ぐらい高速な
コードを生成してくれます

ですから、g95用では、すでにfgetcは使わないようになっています(使おうと思っても存在しない、fgetcのダミールーチンも使っていない)。他のコンパイラの場合も同じに出来ますが、その前に少しテストしたかったので、fgetcを使うルーチンが残っているだけです。

> ですから、g95用では、すでにfgetcは使わないようになっています(使おうと思っても存在しない、fgetcのダミールーチンも使っていない)。他のコンパイラの場合も同じに出来ますが、その前に少しテストしたかったので、fgetcを使うルーチンが残っているだけです。
>
src/itfgetbuf_.cの実装に関してですが、1byte毎に read(2)を呼び出すと
system callに伴う kernel call gateや context switchのコストが増加による
大きなファイルを読み込む際のパフォーマンス低下が予測されます
# fgetc_()[Fortran]や fgetc()[LIBC]の場合、後ろに入力バッファを抱えており
# read(2)はバッファフィルにだけ使われるので system callに伴う overheadは
# 低減されている

fgetc_()を使わないままで、パフォーマンスの改善策としては
- Fortran I/O LUNを捨てて LIBCの stdio library(FILE構造体)へ乗り換える
  o Fortran側で FILE構造体へのポインタをどう管理するかが問題になる
  o write(lfno,*)を全てリプレースする必要がある
- File Descripter毎に自前のバッファリング機構を用意して管理する
  o write(lfno,*)をリプレースすると、Fortran I/O LUNを File Descripter(整数)で置き換え可能

Make等の配置に関しては、特に主張があるわけではないので、適当に直してください。

> o mk/sad.osdep,mkに追加された ifeq ($(HAVE_F_FGTEC),YES)はきちんと動きますか？
> GNU make の conditional構文は制約が多く
> if
> if
> else
> endif
> else
> endif
> の形式は分岐によっては、うまく動かなかったケースがあった気がするのですが...
>
HAVE_F_FGETC=YESな環境で、OBJ_ITGETBUF=itfgetbuf_.oになるようなので
正しく動いてないものと推定されます
src/itfgetbuf_.cが pserverから checkoutできないので、コンパイルできません

o writeb@tfprinta.fの変更
''I hope the below works for all compilers...''とありますが、
少なくとも Intel Fortran Compiler 8.1では正しく動きませんでした

> > o mk/sad.osdep,mkに追加された ifeq ($(HAVE_F_FGTEC),YES)はきちんと動きますか？
> > GNU make の conditional構文は制約が多く
> > if
> > if
> > else
> > endif
> > else
> > endif
> > の形式は分岐によっては、うまく動かなかったケースがあった気がするのですが...
> >
> HAVE_F_FGETC=YESな環境で、OBJ_ITGETBUF=itfgetbuf_.oになるようなので
> 正しく動いてないものと推定されます
> src/itfgetbuf_.cが pserverから checkoutできないので、コンパイルできません

itfgetbuf_.cはcheck inしたつもりですが、どうしてかわかりません。ifの中のifが動かない件は直します。

>
> o writeb@tfprinta.fの変更
> ''I hope the below works for all compilers...''とありますが、
> 少なくとも Intel Fortran Compiler 8.1では正しく動きませんでした

どうもIntelコンパイラは制限がきびしすぎるので、それだけ専用のモジュールにしたほうがよいのでは。

とりあえずitfgetbuf_.cをcheck in しましたがダメですか?

Checking in itfgetbuf_.c;
/SAD/cvsroot/oldsad/src/itfgetbuf_.c,v <-- itfgetbuf_.c
new revision: 1.6; previous revision: 1.5
done

> o writeb@tfprinta.fの変更
> ''I hope the below works for all compilers...''とありますが、
> 少なくとも Intel Fortran Compiler 8.1では正しく動きませんでした
>
続報です
Intel Fortranで動かないというレベルよりもさらに根が深いようです

1. CVS MAIN trunk側の writeb@tfprinta.fですが g95 version 0.91で
   検証しましたが、"Write error to file  6"が出て動きません!!

2. 書式指定の構築時に使う write(form,*)l の可搬性
   write(form,*)l で作る form文字列ですが、右詰め・左詰めどちらを期待していますか？
   Fortranの言語仕様を確認してはいませんが、手元のコンパイラ数種を試す限りは
  実装依存性が有ります(言語仕様上で規定があるならコンパイラ側のバグなのですが...)
  例えば、l=12とした場合、(空白を_で代用してます)
  左詰め+符号用一文字な出力 '_12_________'
  右詰めな出力                      '__________12'
  が、有りました
  言語仕様で実装依存を認めている場合、writeb関数での form文字列の合成結果は
  実装依存になります
  下記のように、gfortranと g95/g77間で違いがあります

簡単なテストプログラム
--- begin test.f ---
      integer num
      character*12 form

      num = 12
      write(form,*) num
      write(*,*)'form=[',form,']'
      end
--- end test.f ---

0. DEC Fortran on acsad0
% f77 test.f && ./a.out
 form=[          12]

1. GNU Fortran (GCC) 4.2.4 20080213 (prerelease)
% gfortran42 test.f && ./a.out
 form=[          12]

2. GNU Fortran (GCC) 3.4.6 [FreeBSD]
% g77-34 test.f && ./a.out
 form=[ 12         ]

3. Intel(R) Fortran Compiler for 32-bit applications, Version 8.1    Build 20060606Z
% ifort test.f && ./a.out
 form=[          12]

4. G95 0.91
% g95 test.f && ./a.out
 form=[ 12         ]

今朝$を前にもってきたものをcheck inしました。

> > o writeb@tfprinta.fの変更
> > ''I hope the below works for all compilers...''とありますが、
> > 少なくとも Intel Fortran Compiler 8.1では正しく動きませんでした
> >
> 続報です
> Intel Fortranで動かないというレベルよりもさらに根が深いようです
>
> 1. CVS MAIN trunk側の writeb@tfprinta.fですが g95 version 0.91で
> 検証しましたが、"Write error to file 6"が出て動きません!!
>
さらに、続報です

検証に使用した g95-0.91(2007/01/29)が古い可能性も考慮して
2007/02/20 13:49 +0100に http://ftp.g95.org/g95_source.tgzから
拾ってきた g95_source.tgzから g95を再生成して追試しました

使用した、SADのソースは CVS mirror pserverから
2008/02/20 15:06 +0100に checkoutしたものです

SADは、_USE_G95=YESを設定して上で、FC=g95/CC=ccでコンパイルしました

やはり、writeb@tfprinta.fによるコンソール出力は、
"Write error to file 6"で、機能しません
1.0.10.2.2b2以降で変更された src/tfprintfa.f Revision 1.60および 1.61で
出力がエラーにならない g95のソースはどこから手に入りますか？

動く環境の入手性に問題があるなら、tfprintfa.fは少なくとも g77/gfortran/DEC fortranで
動いた実績のある Revision 1.59へ戻すべきだと思います

私の試したg95(Darwin)は

G95 (GCC 4.0.3 (g95 0.90!) Feb 6 2008)
Copyright (C) 2002-2005 Free Software Foundation, Inc.

となっています。実際にはfinkで手に入れています。

ところでwritebの変更は別にg95のために行ったわけではなく、g95を必要とするわけでもないので、変更後もg77/gfortran/DECで動いているならいいのではないでしょうか。

> ところでwritebの変更は別にg95のために行ったわけではなく、g95を必要とするわけでもないので、変更後もg77/gfortran/DECで動いているならいいのではないでしょうか。
>
少なくとも鎌田さんは、1.0.10.2.3b - 1.0.10.2.3b3と gfortran-4.2.3の組み合わせで
出力異常があると報告していますが？(つまり 1.60/1.61ともに NG)
#見え方としては、出力が縦書きになるらしい
原因は、組み立てられた formの問題が処理系に対して不適切なためと思われます
また、g77 vs gfortran/DEC fortranでは、writeb内で生成する form文字列が
異なることはすでに指摘した通りです

> > ところでwritebの変更は別にg95のために行ったわけではなく、g95を必要とするわけでもないので、変更後もg77/gfortran/DECで動いているならいいのではないでしょうか。
> >
> 少なくとも鎌田さんは、1.0.10.2.3b - 1.0.10.2.3b3と gfortran-4.2.3の組み合わせで
> 出力異常があると報告していますが？(つまり 1.60/1.61ともに NG)
> #見え方としては、出力が縦書きになるらしい
>
こちらの環境で checkoutした CVS MAIN trunk(2008/02/20 16:47 +0100)と
GNU Fortran (GCC) 4.2.4 20080213 (prerelease)
でPrint[]等での writeb経由の出力が縦書きに現象を確認しました(FreeBSD/i386)

たぶん、amsad8/9(darwin/i386 + gfortran 4.2.x)では、使い物にならないとおもいますが？
生出さんの finkから入れた g95 0.90が正常なら amsad8/9を gfortran-4.2.xから g95に切り替えますか？

gfortranで動かないのなら元に戻すしかないでしょうね。明日やります。

> gfortranで動かないのなら元に戻すしかないでしょうね。明日やります。
>
writebが長さ lenの unibyte-string bufferを出力するとして、
問題点を整理しますと
1. 出力に使う書式指定を動的に生成すること自体は問題ではない

2. 1.60/1.61のコードは少なくとも gfortran-4.2.xに適合する書式指定を合成できていない

3. 書式指定の合成課程で 整数lenから書式指定に使う部分文字列を
write(foo, *) lenで生成したときに得られる文字列 fooの右詰め・左詰めに
コンパイラ依存性がある
-> Fortran規格的に可能なら、write文を手なずけて詰め方を強制する
-> さもなくば、コード側で前後の空白文字を削除する(lenw/lnblnkをつかう？)

4. GNU Fortran 4.2.x/Intel Fortran 8.1では書式指定 "An"は、
n文字幅で characterを出力する
つまり、10文字相当の integer*1 bar(10)配列を "(A10)"で書式指定すると
10文字幅の出力 * 10文字に展開される
1文字幅の出力 * 10文字の書式指定は、"(10A1)"である

"(A10)" + 長さ10の配列が "(10A10)"相当に展開されるなら、
実は"(A1)"で十分かもしれない(規格に当たってみる必要あり)
Rev 1.59の "(1024a1)"は、Rev 1.58の"(1000000000a1)"を実装系に
拒否されなくなるまで Cut&Tryで短くした結果ある

5. "nA1"の書式指定での、繰り返し数 nの上限は実装依存である
writebのオリジナルコード(Rev. 1.58)での"(1000000000a1)"などという書式しては
Intel Fortranでは実行時に無効な書式指定であるとして拒否される
これは、Fortran I/Oライブラリ内でランタイムに処理されているので、動的に生成しても
この制約から逃れられない

> 4. GNU Fortran 4.2.x/Intel Fortran 8.1では書式指定 "An"は、
> n文字幅で characterを出力する
> つまり、10文字相当の integer*1 bar(10)配列を "(A10)"で書式指定すると
> 10文字幅の出力 * 10文字に展開される
> 1文字幅の出力 * 10文字の書式指定は、"(10A1)"である
>
> "(A10)" + 長さ10の配列が "(10A10)"相当に展開されるなら、
> 実は"(A1)"で十分かもしれない(規格に当たってみる必要あり)
> Rev 1.59の "(1024a1)"は、Rev 1.58の"(1000000000a1)"を実装系に
> 拒否されなくなるまで Cut&Tryで短くした結果ある
>
> 5. "nA1"の書式指定での、繰り返し数 nの上限は実装依存である
> writebのオリジナルコード(Rev. 1.58)での"(1000000000a1)"などという書式しては
> Intel Fortranでは実行時に無効な書式指定であるとして拒否される
> これは、Fortran I/Oライブラリ内でランタイムに処理されているので、動的に生成しても
> この制約から逃れられない
このへんの話を今日 Webでいろいろ調べたまとめ
http://jyurai.ddo.jp/~amorita/diary/?date=20080220

1. 改行編集記述子$は、Fortran95規格ではIBM拡張であり、非標準
2. Fortran90以降だと、停留入出力で改行を抑止した出力が可能
ADVANCE='NO'を指定すると、writeの終了時の改行が消える
ただし、(3)の扱いを当てにして(a1)を使う場合、(a1)を処理し終わって
(a1)から処理を再開するときに改行が出力されるので注意
3. ($,1024a1)の代わりに、($,a1)で大丈夫そう
HP Fortranのマニュアルには、この扱いは拡張であるとは書かれていないが、
どのFortran規格を出典にしているかは不明

たぶん、Fortran90的には (###a1)な formを動的に生成して、
ADVANCE='NO'で出力するのが正当な気がするが、
IBM拡張を当てにするなら ($,a1)で十分

> 4. GNU Fortran 4.2.x/Intel Fortran 8.1では書式指定 "An"は、
>    n文字幅で characterを出力する
>    つまり、10文字相当の integer*1 bar(10)配列を "(A10)"で書式指定すると
>   10文字幅の出力 * 10文字に展開される
>   1文字幅の出力 * 10文字の書式指定は、"(10A1)"である
> 
>   "(A10)" + 長さ10の配列が "(10A10)"相当に展開されるなら、
>   実は"(A1)"で十分かもしれない(規格に当たってみる必要あり)
>   Rev 1.59の "(1024a1)"は、Rev 1.58の"(1000000000a1)"を実装系に
>   拒否されなくなるまで Cut&Tryで短くした結果ある
> 
> 5. "nA1"の書式指定での、繰り返し数 nの上限は実装依存である
>    writebのオリジナルコード(Rev. 1.58)での"(1000000000a1)"などという書式しては
>    Intel Fortranでは実行時に無効な書式指定であるとして拒否される
>    これは、Fortran I/Oライブラリ内でランタイムに処理されているので、動的に生成しても
>    この制約から逃れられない
このへんの話を今日 Webでいろいろ調べた日記にまとめ(URL参照)

以下要約
1. 改行編集記述子$は、Fortran95規格ではIBM拡張であり、非標準
2. Fortran90以降だと、停留入出力で改行を抑止した出力が可能
   ADVANCE='NO'を指定すると、writeの終了時の改行が消える
   ただし、(3)の扱いを当てにして(a1)を使う場合、(a1)を処理し終わって
   (a1)から処理を再開するときに改行が出力されるので注意
3. ($,1024a1)の代わりに、($,a1)で大丈夫そう
   HP Fortranのマニュアルには、この扱いは拡張であるとは書かれていないが、
   どのFortran規格を出典にしているかは不明

たぶん、Fortran90的には (###a1)な formを動的に生成して、
ADVANCE='NO'で出力するのが正当な気がするが、
IBM拡張を当てにするなら ($,a1)で十分

調査有難うございます。
ところで数時間前にcheckinしたヴァージョンではどうでしょうか。gfrotranとg95ではOKに見えますが。

> 調査有難うございます。
> ところで数時間前にcheckinしたヴァージョンではどうでしょうか。gfrotranとg95ではOKに見えますが。
write(lfno,'($,a)')string(1:l)
だと、部分配列 string(1:l)は Fortran90か95で入ったと思うので
g77で問題が出ます

> > 調査有難うございます。
> > ところで数時間前にcheckinしたヴァージョンではどうでしょうか。gfrotranとg95ではOKに見えますが。
> write(lfno,'($,a)')string(1:l)
> だと、部分配列 string(1:l)は Fortran90か95で入ったと思うので
> g77で問題が出ます
src/tfprintf.a@1.63ですが、上記の考察は間違えです
stringは 1.62以前と違い character*l で定義されているので string(1:l)か
部分文字列であって部分配列ではありません
# 動作検証は、まだしていないのですが 1.64で 1.59相当に戻っているということは
# 問題があった？

PS.
amorita branch側で readstr()の MFCと平行して build framework側での
g95サポートを独立に実装した snapshot 1410では、FreeBSD/i386
7.0-PRERELEASE上の Interl Fortran 8.1/gfortran-4.2.4/g77-3.4.6/
g95-0.91でbench2.sadが正常に動いています

早くmain側にも反映させてください。

> 早くmain側にも反映させてください。
>
g95サポート回りですか？
基本的には src/sim/fgetc_Dummy.f捨て捨てな点以外の内容は、
CVS MAIN trunkと同じですから、動作は変わりませんが？
# API仕様的には、readstr()が EOF/Errorで戻ったときに呼び出し側で
# bufferをクリアしているコードがあったので、readstr()側でクリアするように
# 安全側に変更しています
# リターンコードを確認して使っているコードに対しては、無駄な
# white space fillingを行うことになりますが、不注意なコードが
# readstr()呼び出し前の内容が未定な bufferを読み込むことを
# 避けられます

現状の実装に関しては、こちらのbranchでも下記のような問題が山積みなので、
本格的な itfgetbuf_.cの使用は避けた方が良いと思っています
# バックポートするなら、この辺の問題が片づいてからかなと思っています
o 現状の src/itfgetbuf_.c + read(2)を使う場合の問題点
 1. Read性能の劣化(試験環境で、読み込みスループットが 1/20〜1/10へ低下)
    * Character-by-characterで read(2)システムコールを発行するため
 2. 同一Logical Unit Numberに対して Read[], Write[], SeekFile[]関数を
    組み合わせて使用した場合の動作が不定となり保証できない(ファイルの部分書き換え等)
    * Write[]/SeekFile[]は、Fortran WRITE statement/FSEEK intrinsic(ベンダー拡張)経由で
       Fortran I/O Library内のファイル位置ポインタを更新するが、Read[]はKernelが管理する
       ファイル位置ポインタを見ている。
 3. 本質的な問題の解決には、WRITE statement/FSEEK intronsicを使用している部分の
    改修が必要。ただし、そこまで実装した場合、OPEN/CLOSEしか使わない Fortran I/Oの
    存在意義がなくなる(open(2)/close(2)を直接呼び出す方が効率的になる)
    実装上の問題は、
    * READ statementよりも WRITE(lfno, ...)を使っている箇所の方が多い
    * File Descriptorで管理する場合は、実用的なI/O性能を達成には
       read/write buffering機構の実装が不可欠
       ただし、ネットワークコード(socket API)等との相性は良い
       特に、buffering機構を自前(SAD側)で実装した場合は、きめ細かな buffering制御が可能
       (TCP/UDPOpenを使ったネットワークアプリケーションには有利?)
    * libcの stdioを利用するためには、SAD側のファイル記述子とFILE型へのポインタの
      対応関係を管理する必要がある
    * 移植性/メモリ効率をそれなりに求めると、内部で動的なテーブルを管理する必要あり

現在予定しているバックポートは、以下の通り
(しばらく、CVS MAIN trunkが安定していなかったので凍結中)
1. PRNG(Pseudo-Random Number Generator)の実装入れ替え
   o SEED変数の廃止(変数自体は残りますが、もはや動作に影響を与えません)
   o SEED FFSコマンドの廃止(SEED変数との名前空間衝突のため機能していなかったもの)
   o Random[]関数ファミリーの実装入れかえ
      * 追加関数
         ListRandom[]           使用可能な PRNG pluginのリストを返す
         ParabolaRandom[]    区間(-1,1)の放物線分布乱数(*)
         UniformRandom[]      区間(0,1)の均一分布乱数(*)
         UniformRandom0[]    区間[0,1)の均一分布乱数(Random[]の別名)
         UniformRandom1[]    区間(0,1]の均一分布乱数(*)
         UniformRandom01[]  区間[0,1]の均一分布乱数(*)
         (*)は、PRNG pluginでのサポートは必須ではない
      * 仕様変更
         SeedRandom[]  返り値が、現在の PRNG plguin選択状態と
                               選択中の PRNG pluginの内部状態を含む
                               List型に変更される(旧仕様は、Real型)
                               ただし、SeedRandom[]の戻り値(*)を保存し、再び
                               SeedRandom[]の引数に与えた際に戻り値(*)を
                               返した状態へ復帰する点は変化なし
                               String型を引数とした PRNG pluginの選択機能を追加
                               List型を渡しての内部状態の初期化機能を追加
         FIXSEEDフラグ   保存されるのは、PRNG pluginの選択状態と保存時に
                               選択中だった PRNG pluginの内部状態だけです
         PUSHS_EED/POPS_EED/EXCGS_EED/PEEKS_EED FFSコマンド
                               保存されるのは、PRNG pluginの選択状態と保存時に
                               選択中だった PRNG pluginの内部状態だけです
  o 試験環境での試験状況
   * 旧実装と互換の疑似乱数系列の生成性能に劣化は無い
   * RAD/FLUC付きの KEKB HER Trackingでは、同一の疑似乱数列を使えば
     コードの変更前後で粒子分布は一致する(HER Trackingで通過する
     コードパス上での変更は、動作を変えていない)
   * RAD/FLUC付き Trackingにて放射減衰後の粒子分布の統計量に
      PRNG plugin依存性が有ることが分っている
      使用した粒子数(1000個)に依存した統計誤差の範囲か、疑似乱数列の
      不備によるものかは現時点では不明
      （理論的な平衡分布が分っているモデルによる検証が必要？)

2. CONVCASE/PRSVCASEフラグの実装
   o FFSコマンドラインでの大文字・小文字自動変換機能の部分的抑制や停止をサポートします
      これにより、小文字を含む element name/patternを FFSコマンドラインで使用可能になります
   o 現状、PRSVCASEは全ての FFSコマンドをサポートしていないので、CONVCASEフラグのみ
      先行してバックポートを実施するかも
      (主要コマンドDISP/FIT/FIX/FREE/COUP等はサポートしたが...)