現在では非線形推定のプログラムをわざわざ自分で作る、なんてことはあり得ないのだが、機器組み込みのアルゴリズムとなるとそうはいかず、自分で記述しなければならない。非線形推定アルゴリズムは、例えばNumerical Recipes にもあるので、実現は簡単だろうと思われるが、そうは問屋が卸さない。Numerical Recipes はどちらかと言うと自分でアルゴリズムを開発して、出来上がったころに参考にするような資料で、最初からこれに頼って開発する、というのはよほど数学とコンピュータに慣れ親しんだ者でなければ、資料として使いこなせないと思われる。

そこで、またしてもMathematica 頼りで、非線形推定のアルゴリズムを開発しようと考えた。Mathematica で問題を記述できれば、計算の一つ一つをフォローできるので、C等への変換が安全・確実にできるのだ。当然のように現在のMathematica は非線形推定を標準のパッケージで含んでいるので、そのアルゴリズム自体の詳細は不明だ。ただし、随分と以前にMathematica にまだ種々のパッケージが搭載されていない時分に、非線形推定のためのGauss-Newton アルゴリズムについて、Mathematica J. で読んだ覚えがあったので探してみた。調べたら確かに、Mathematica Jounal, Vol. 1, No. 2, Fall, 1990 にM.N. Ediger という著者によるCode for implementing Gauss-Newton nonlinear regression という記事があって、そのリソースを見つけることができた。

いかにも古い記事でMathematica のバージョンも大分前のもので、単に自動的に変換することができず、text から再構成した。といっても、コードはごく僅かと言っていいぐらいなので、直ぐに回復することができた。できあがったコードは実験値を放り込んで、ちゃんと答えが出る事を確かめた。

その他にも、Nonlinear regression, G.K. Smyth, Volume 3, pp 1405-1411 in Encyclopedia of Environmetrics, 2002という記事をWebで見つけることができて、非線形推定の解説記事として分かり易い。

開発するホウ素計についてはかけられる時間が限られていて、後およそ半年だ。そうするとハードウェアを作り替える機会は一、二回位しかないだろう。できるだけ早く、まだ不明確なパラメータを決定する必要があるし、その結果を最終のハードウェアに反映する必要がある。とすると、試作機を使ったデータを直ちに解析してこれをフィードバックする手順を準備しておくべきである。このためには、

試作ハードウェアは、PCベースではないので、測定データを解析するために、何らかの方法でPCに持ってくる手立てが必要だ。シリアルでは大変なのでフラッシュメモリのカード程度が必要になるだろう。また、変更するところは殆どがソフトウェアで済むと思われる。ハードウェアに関連するのは、A/Dコンバータの設定とタイマー関係くらいと思われるので、そんなに大事（おおごと）にはならないと予想している。またSH4の速度や搭載メモリ量からみて、搭載すべきソフトウェアは十分許容できるサイズになるだろう。CPU周りの変更も必要ないと思われる。

SH-4にはフリーのTRONがあるのだが、今回一緒に作業するメーカーは、OSは使わない、と言っていたのが気になる。TRONを使った方が。プログラムをモジュール化できるし、タイマも使いやすいと思うのだが、よく分からない。確かめる必要があろう。あるいはOSを使わない方が何か利点があるのかも知れない。

先日、相手方の会社を訪問してみたら、計算機周りは全て外注で、その外注先は個人営業に近い会社だということがわかった。この会社が技術的にどうこう言うべき判断材料は得られなかったので、何とも言いかねるが、何か起きた場合、スケジュールが大幅に遅れる可能性はかなり高い。

そこで、最悪の場合を考えて、解析ソフトの下準備をしておくことにした。まず、開発環境の整備なのだが、linuxを立ち上げるのは何となく気が進まない。すぐ脇に一揃い置いてあるのだが、今まで殆ど電源を入れていないのだ。以前と違ってプリンタも直ぐに使えるし、tcpの設定も済んでいるのだから別に問題はない筈なのだが、linux のデスクトップの、あのちぐはぐさや稚拙なところが、顔をそむけたくなる原因なのかも知れない。いっそ昔々のKorn shell on DOS の方がなつかしい。

開発はCなので、この環境が整っていなくてはならない。PowerBook に開発環境であるX-code が入っているのを思い出して、X-term でccを探したらなかったけれど、gcc としてきちんと働いた。普通にテストプログラムを書いて、gcc test.c で問題なくa.out ができて、実行できた。もちろんX-code 上で開発することもできるので、最初はxterm で、そのうち、X-code に慣れるという意味からも、少しやる気が出てきた。

やっとNumerical Recipe をきちんと見直そうという気持ちになって読んでみたら、逆行列計算はLU分解のページに説明されていて、ごく短い二つのサブルーチンで構成されていることが分かった。ただし、行列の格納場所をアロケートするためにmalloc ではなく、特別に用意されたルーチンを使うことが勧められている。これを使えば、Cのアレイが0から始まるのに対して、行列の要素を1〜nとして扱えるので都合がよい、アロケートされた行列のサイズより小さい行列の場合でも使える、といった説明がなされている。尤もなので、Numerical Recipe の推薦通りにこれを使うこととする。

その他、行列をアレイ上に、どう展開するべきか、という問題を目に見える形にするために、行列の内積あたりはCで書き出す必要があるかも知れない。

(2004/2/25)

こんなふうに準備は整ったので、目処をたてるためにざっとアルゴリズムに沿ってプログラミングが可能かどうか見極めるだけで、後は相手に任せてもよかったのだが、貧乏性が先に出てしまって、少しずつ作ってみることにした。

まず逆行列はそのままNumerical Recipe が使えそうなので、この本に付録のフロッピーを読み込まなければいけない。以前に用意しておいたUSB-フロッピードライブを持ち出してきて読もうとするが読めない。開発元のホームページにはOS-Xに付属のドライバで十分だ、というようなことが書いてあるのだが、「読めません。初期化しますか？」の一点張りでらちが開かない。Numerical Recipe が1922年の版で、Mac用のフロッピーは800Kのものなので、無理はないかも知れない。

そうは言っても、手で書き写す気力はないので、なんとかならないかとあちこち物色していたら、古い古いPowerBook 500 を棄てずにとっておいたのを見つけた。1995年に導入したものだが、Etherがついているので現役としても使えないことはない。試してみたら無事読めた。tcpの設定を忘れていたので少し手間取ったが必要なソースを取り出す事ができた。物は大事に、という教訓が生きた。

さて、ステップ・バイ・ステップでプログラミングしていく。Matematicaで書かれたアルゴリズムは途中経過を自由に細工できるので、ホウ素濃度の実験値から非線形推定する部分の、最小二乗推定の部分の、さらに逆行列を求める関数に与える行列の数字列を取り出してきて、これをNumerical Recipe の逆行列関数に与えてみる。無事に正しい結果が出てきた。行と列の順番なんぞもMathematica と同じで楽ができた。

次に行列の転置ルーチンと行列の積のルーチンをNumerical Recipe のスタイルに合わせて作った。計算効率は今回の場合、殆ど問題にならないから、早く開発するのを第一優先に、Matematicaの計算の流れをそのまま辿るようにした。ステップを書き加える毎にMatematicaの途中結果と照らし合わせることで、エラーを早い段階から潰していくようにした。暫くCから離れていたので、思い出すのに大分手間取ったが、一番手間取ると考えていた、最小二乗推定部分が出来上がった。

開発ソフトはハードウェア・コントローラ用のボードに乗っかるので、特にメモリの使い方で気をつける必要があると思われる。今では様子が変わったのかも知れないが昔はそうだった（「昔々あるところに」、が始まってしまったが）。つまり、作業領域をstaticに取って置かないといけないのか、適宜アロケートできるのか、という問題だ。少なくとも、サブルーチンのあちこちでmalloc()とfree()を繰り返すのは、如何にも問題がおきそうな気がする。

作業メモリが必要なのは最小二乗ルーチンだ。そこでmainの中にこのルーチンを入れ子にすることで、必要なアレイはmainを参照できるようにして、malloc()はmainルーチンで一回だけ実行することにした。ターゲットハードウェアがmalloc()を許さない、という可能性もあるが、malloc()を一ヶ所にまとめて、一回しか実行しないようにしてあれば、後でstaticにしなければならない、という事態になっても改造は容易だろう、というもくろみだ。その他に、関数を入れ子にする場合でも、関数プロトタイプの宣言を最初にしないと入れ子の関数をメインの最後に持っていけない、というに気付くのに少し時間がかかった。

というわけで、メインルーチンを書き加えてver.1.0のソフトウェアが出来上がった。案ずるより産むが易しか。振り返ってみると、一番手間取ったのがマトリックスの行と列の順番がどうなっているかを確認する作業と、最小二乗ルーチンのバグとりと、このルーチンをメインの入れ子にするところだった。

(2004/3/4)

さて、ここからが問題で、ホウ素計の共同開発の相手方と、この解析ソフトについて、どんな風に交渉したらよいだろうか。いくつかの場合分けがあって、
1. 相手方が十分な開発能力を持っていて、自前でスケジュール通りに解析ソフトが開発できる、と推定される場合
2. 相手方の開発能力が不明で、いつまで経っても解析ソフトが仕上がらない場合
3. 相手方に開発能力（資金）がなくて、解析ソフト開発ができないと言ってくる場合

1の場合には何の問題もない。解析ソフトを開発したことを告げて、相手方の購入希望を聞く、あるいは黙っていて、開発したソフトを相手方の開発状況の判断材料に使うのがよい。
3の場合にも問題はない。共同開発のバランスが崩れたことを認めさせた後、解析ソフトを開発したことを告げて、交渉に入ればよい。
問題は2の場合で、早い時期にこちらから解析ソフト開発の事実を知らせると、自社の問題をうやむやにして、スケジュールぎりぎりになってから、開発が遅れて困るのはそちらでしょう、と言いつつ、泣きついてくる畏れがある。

スケジュールを確定してから、最初と最後の中間あたりにマイル・ストーンを設定しておいて、その時点で、相手方が1〜3のどれにあたるかを判断すれば良いと考えられる。

(2004/3/4)

p.s. (2004/6/15) 話が大分煮詰まってきたのだが、依然、ソフトウェアに問題がある。先日、メーカ側とこの点について話したのだが、相変わらずやる気が見えない。そこで「ところで、この装置は何台くらい売れると思います？特許の話なんかもしなきゃいけないので」と水を向けたら「えっ、この装置は売るつもりなんですか？」ときた。をいをい！

p.s. (2004/8/13) その後、大きな問題はでず、９月には分析展に出品する運びとなった。取りあえず、この仕事はお仕舞とした。