問題はモジュールのロードに関係していることが判明

キャサリンはサイン、コサイン、タンジェント、アークタンジェントを実装しているようです。私が何かを見逃した場合、それは差分を読み間違えたからです。さすがK!

昨日 oof90 のバグを追跡したところ、問題はモジュールのロードに関係していることが判明しました。シンボルがロードされてから破棄されますが、そうであってはなりません。このシンボルはインターフェイス リストの一部であり、新しいシンボルが割り当てられるいくつかのステートメントの後で、古いシンボルの上にピシャリと割り当てられ、インターフェイス リスト内の元のシンボルの代わりになります。わお。

USE ステートメントに ONLY 句がないため、そのシンボルが解放される理由がわかりません。より深い問題があるので、私はこの特定のケースについて苦しんでいません。ONLY 句に関する私の最初のアプローチは、「必要なものをロードする」ことだったようです。

先週、Paul Brook は別の型を含む型の例を示して、この問題に見事な穴を開けました。最初のタイプが ONLY を介して読み込まれる場合、2 番目のタイプは非表示のシンボルとして読み込まれる必要があります。これにより、「すべてをロードし、必要のないものを捨てる」という哲学が変わりました。今、私たちは捨てすぎているようです。

複雑で壊れているものを修正する代わりに、ここでは一歩後退して元の単純なスキームを複雑にする方が良いと思います.

私の (暗黙の) 当初の目標の 1 つは、fseek() を介して読み飛ばさずに、モジュールを直接読み込めるようにすることでした。すべてをロードする場合は、それで済むと思います。ただし、 ONLY はほぼすべてのものを参照できるという事実を考えると、最初のパスでのみシンボルをロードし、必要に応じて依存シンボルをロードすることで、「必要なものをロードする」に戻る必要があるようです。 .

7月30日
oof90 ライブラリの現在のバグは、インターフェイス リストを飛び回っていますが、モジュールから正しくロードされていない一般的なインターフェイスと関係があります。コードの読み取りと書き込みを行う最上位モジュールは、単純化しようとしているところまで来ています。

週末は、g95 の浮動小数点変数の処理をさまざまな浮動小数点チップに準拠させる方法を考えるのに多くの時間を費やしました。基本的な問題は、結果を事前に計算する際に、コンパイラーがコンパイルされたプログラムと同じ結果を出す必要があることです。当初は、GMP の最新バージョンで新しい丸め浮動小数点型を使用する予定でしたが、これは必要ないようです。

現在のアイデアは、最終結果に必要な有効ビット数の約 2 倍を使用して、GMP で計算を行うことです。各計算の最後に、GMP 番号を最も近い機械番号に丸めます。これを行うことができるのは、g95 がターゲットの浮動小数点形式の基数、数字、最小および最大指数で構成されているためです。丸めの問題は、正しく丸められた浮動小数点数を表示する問題と同じです。通常、これらのスキームは多倍精度の演算を必要としますが、これは既に取得済みであるため大したことではありません。

各ステップで丸めることにより、ターゲットの算術演算をシミュレートしています。最新の浮動小数点演算 (支配的な IEEE-754 を含む) の基本原則の 1 つは、算術演算の結果は、演算が無限の精度を持っているかのように行われ、その後、最も近い機械数に丸められるというものです。これは、計算を安定させるいくつかの優れた特性を意味します。

私はこの件に関するいくつかの論文を入手して読みましたが、それは簡単なことではありません。

タイトルとURLをコピーしました