ほとんどの数学者は、次のことに同意します。
e πi + 1 = 0
ただし、ほとんどの浮動小数点の実装は同意しません。この論争をどこまで解決できるでしょうか。
さまざまな言語と実装、および結果をできるだけゼロに近づけるためのさまざまな方法について聞きたいと思っています。クリエイティブに！
質問する
2090 次
10 に答える
17
ほとんどの浮動小数点の実装が同意しないというわけではありません。100% の答えを得るために必要な精度が得られないというだけです。そして正しい答えは、できないということです。
PI は、誰もシンボリック表現以外で表すことができなかった無限の一連の数字であり、e^X も同じであるため、100% の精度を達成する唯一の方法はシンボリックにすることです。
于 2008-12-26T20:22:01.910 に答える
10
以下は、私が試した実装と言語の短いリストです。ゼロに近い順に並べ替えられます。
- 図式：
(+ 1 (make-polar 1 (atan 0 -1)))- ⇒
0.0+1.2246063538223773e-16i(シェ・スキーム、MITスキーム) - ⇒
0.0+1.22460635382238e-16i（ガイル） - ⇒
0.0+1.22464679914735e-16i（鶏とnumbers卵） - ⇒
0.0+1.2246467991473532e-16i(MzScheme、SISC、ゴーシュ、ガンビット) - ⇒
0.0+1.2246467991473533e-16i（SCM）
- ⇒
- 一般的な Lisp:
(1+ (exp (complex 0 pi)))- ⇒
#C(0.0L0 -5.0165576136843360246L-20)(クリップ) - ⇒
#C(0.0d0 1.2246063538223773d-16)(CMUCL) - ⇒
#C(0.0d0 1.2246467991473532d-16)（SBCL）
- ⇒
- パール:
use Math::Complex; Math::Complex->emake(1, pi) + 1- ⇒
1.22464679914735e-16i
- ⇒
- パイソン:
from cmath import exp, pi; exp(complex(0, pi)) + 1- ⇒
1.2246467991473532e-16j(CPython)
- ⇒
- ルビー:
require 'complex'; Complex::polar(1, Math::PI) + 1- ⇒
Complex(0.0, 1.22464679914735e-16)（MRI） - ⇒
Complex(0.0, 1.2246467991473532e-16)(JRuby)
- ⇒
- R:
complex(argument = pi) + 1- ⇒
0+1.224606353822377e-16i
- ⇒
于 2008-08-04T06:22:18.713 に答える
7
この論争を解決することは可能ですか?
私が最初に考えたのは、 Mapleのような記号言語に目を向けることです。ただし、それは浮動小数点としてカウントされないと思います。
実際、従来のプログラミング言語でi (エンジニアの場合はj ) をどのように表すのでしょうか?
おそらくより良い例は、sin(π) = 0 でしょうか? （それとも、またポイントを逃したのでしょうか？）
于 2008-08-04T06:29:03.910 に答える
5
私はライアンに同意します、あなたは別の記数法に移る必要があるでしょう。円周率を無限に長い小数として表す必要があるため、解決策は浮動小数点演算の領域外にあります。そのため、制限された精度のスキームは機能しません（少なくとも、失われたものを補うために何らかのファッジファクターを使用しない限り）精度）。
于 2008-08-25T01:10:29.007 に答える
5
浮動小数点演算が言語によって実装されていることを示唆しているように見えるので、あなたの質問は私には少し奇妙に思えます。FP 計算はハードウェアで浮動小数点プロセッサを使用して行われるため、これは一般的に正しくありません。しかし、ソフトウェアでもハードウェアでも、浮動小数点は常に不正確です。それがフロートの仕組みです。
より高い精度が必要な場合は、別の数値表現を使用する必要があります。int または long に収まらない数値に対して整数演算を行っている場合と同様です。一部の言語にはそのためのライブラリが組み込まれています (Java には BigInteger と BigDecimal があることは知っています) が、ネイティブ型の代わりにこれらのライブラリを明示的に使用する必要があり、float を使用した場合よりもパフォーマンスが (場合によっては大幅に) 低下します。
于 2008-08-25T13:37:28.430 に答える
4
@ライアン・フォックス
実際、従来のプログラミング言語で i (エンジニアの場合は j) をどのように表すのでしょうか?
ネイティブの複雑なデータ型は未知ではありません。Fortran は 60 年代半ばまでにそれを持っており、OP は歴史のフォローアップでそれらをサポートする他のさまざまな言語を示しています。
また、複素数はライブラリとして他の言語に追加できます (演算子のオーバーロードを使用すると、コード内のネイティブ型のように見えます)。
しかし、この問題の特別なケースを提供しない限り、「不一致」は不正確な機械演算の単なる表現ですよね? と嘆いているようなものです
float r = 2/3;
float s = 3*r;
float t = s - 2;
(t != 0) で終了します (少なくとも、十分に馬鹿げたコンパイラを使用している場合)...
于 2008-08-25T13:29:01.803 に答える
4
私は、無理数と他の数の違いについて、親友と長い間コーヒー チャットをしていました。さて、私たち二人は、この異なる観点で同意します:
無理数はある意味では、関数としての関係です。さて、「完全な円が必要な場合は、完全な円周率をください」と考えてみてください。ただし、円は他の図形 (4 辺、5、6、... 100、200) とは異なりますが、... 辺がいくつになるか円のように見えます。あなたがここまで私に従ってきたなら、ここでこれらすべてのアイデアを接続すると、円周率の公式が得られます。
つまり、pi は関数ですが、終わらない関数です! ∞ パラメーターのためですが、非常に大きな Int の ∞ パラメーターを変更すると、非常に大きな pi インスタンスが得られるので、pi の「インスタンス」を使用できると思います。
e と同じで、巨大なパラメータを与えてください。巨大な e を与えます。
すべてのアイデアをまとめる：
メモリの制限があるため、言語とライブラリは無理数の巨大なインスタンスを提供します。この場合は pi と e です。最終結果として、@Chris Jester-Young が提供する例のように、0 を取得するには長いアプローチが必要になります。
于 2017-05-06T03:07:58.910 に答える
3
これは、現在の浮動小数点計算アーキテクチャの制限です。浮動小数点演算は、e や pi (またはビットが許容する精度を超えるもの) などの数値極の近似値にすぎません。これらの数字は分類を無視しており、正準級数である素数よりも大きなエントロピー (?) を持っているように見えるので、私はこれらの数字を本当に楽しんでいます。比率は数値表現を無視し、そのような単純なことで人の心を吹き飛ばすことがあります (私はそれが大好きです)。
幸いなことに、言語とライブラリ全体を、表記の概念 ( Lasse V. Karlsenによって説明されているものと同様) を使用することで、精度の高い三角関数専用にすることができます。
e や pi などの概念をマシンが理解できる形式で記述したライブラリ/言語を考えてみましょう。機械は完全な円とは何かという概念を持っていますか? おそらくそうではありませんが、オブジェクトを作成することはできます。これは、既知の特徴をすべて満たす円です (半径は一定で、半径と円周の関係は 2*pi*r = C です)。pi のようなオブジェクトは、前述の比率によってのみ記述されます。r & C は、任意の精度で記述された数値オブジェクトにすることができます。e は、「e は、点 x = 0 での関数 f(x) = ex の導関数 (接線の傾き) の値が正確に 1 になるような一意の実数であるため」、wikipediaから定義できます。
楽しい質問です。
于 2009-11-20T20:37:54.937 に答える
3
数値解析は、大きな数の間の小さな差の正確な値に頼ることはできないことを教えてくれます。
これは問題の方程式に影響を与えるだけでなく、ほぼ特異な連立方程式を解くことから、多項式の零点を見つけること、log(~1) または exp(~0) を評価することまで、すべてに不安定性をもたらす可能性があります ( log(x+1) と (exp(x)-1) を評価してこれを回避するための特別な関数を見たことさえあります。
差をゼロにするという観点から考えるのではなく、エラーを最小限に抑える方法で関連する計算を行うことをお勧めします。
すみません、大学でこれを叩きつけられてから 43 年が経ちました。参考文献を思い出すことができたとしても、今はもっと良いものがあると確信しています。これを出発点として提案します。
少しひいきに聞こえる場合は、お詫び申し上げます。私の「数値解析 101」は化学コースの一部でした。当時は CS があまりなかったからです。数値解析が現代の CS コースでどのような場所/重要性を持っているかについては、私はあまり感じていません。
于 2008-12-26T21:22:09.527 に答える
3
実際、従来のプログラミング言語で i (エンジニアの場合は j) をどのように表すのでしょうか?
ネイティブ表現を持たない言語では、通常、OOP を使用してComplexを表すクラスを作成iし、演算子のオーバーロードを使用して、言語固有の他の数値や他の数値プリミティブをj含む操作を適切に処理するために追加されます。Complex
于 2008-08-25T13:48:46.517 に答える