物理量は、オーバーフローまたはアンダーフローなしで64ビット整数で表すことができると仮定するのは妥当ですか？

JDKの元のバイナリ検索アルゴリズムは32ビット整数を使用し、次の場合にオーバーフローバグがありました(low + high) > INT_MAX（http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html） 。

（符号付き）64ビット整数を使用して同じバイナリ検索アルゴリズムを書き換えた場合、low + high10 ^ 18バイトのメモリを持つことは物理的に不可能であるため、INT64_MAXを決して超えないと想定できますか？

（符号付き）64ビット整数を使用して物理量を表す場合、アンダーフローとオーバーフローは発生しないと想定するのは合理的ですか？

短い答えはノーです。ただし、一部のアプリケーションでは、想定が正しい場合があります。

わかりやすくするためにカンマが追加された符号付き整数2 ^ 63を想定しています= 9,223,372,036,854,775,808。したがって、およそ9 * 10 ^ 18です。10 ^ 18は「Exa」です。

ウィキペディアによると、「2013年現在、World Wide Webは4ゼタバイトに達したと推定されています。[12]」、これは4000エクサバイトです。したがって、WWWは2 ^ 63バイトの約400倍です。

したがって、符号付き（または符号なし）64ビット整数よりもはるかに大きい物理量が少なくとも1つあります。 ユニットがバイトであると仮定します。GigaBytesのように、ユニットがもっと大きいものであれば大丈夫ですが、測定の精度は低くなります。

別の例として、遠くの銀河について考えてみましょう。アンドロメダ銀河は実際には近いものの1つであり、2.5 * 10 ^ 6光年離れています。 単位がマイルの場合、 14.5 * 10 ^ 18となり、64ビットの符号付き整数を超えます。さて、明らかにそれは測定に使用する単位に依存しますが、いくつかの銀河はアンドロメダよりもはるかに遠くにあります。（最も知られているものは、13 * 10 ^ 9 LY離れています。）測定に必要な精度によっては、64ビット整数をオーバーフローさせる可能性があります。

（追加）はい、マイルは天文学的な距離ではお粗末な単位です。より一般的な単位は、約9,300万マイルの天文単位かもしれません。その測定単位を使用すると、最も遠い既知の銀河はおよそ10 ^ 15 AU（私の計算が正しければ）で、64ビット整数に適合します。ただし、月までの距離、近くの周回衛星までの距離も測定する場合、そのユニットは大きすぎます。

電子機器のもう1つの例：静電容量の単位であるファラッド（F）。大きなコンデンサの範囲は最大5kFです。そして、ハイブリッド車、「スマートグリッド」などが改善されるにつれて、この数は時間とともに増加する可能性があります。10 ^ -18 Fという小さな静電容量を一度測定できます。したがって、今日測定できる「実際の」静電容量の全体的な範囲は、64ビット整数よりも大きい5 * 10 ^ 21です。

組み合わせ論が関係しているとき、あなたは宇宙に行く必要さえありません。ブリッジのゲームには2 ^ 95の可能な取引があり、それは複雑さの小さな側面にあります。

質問に最も関連する物理量は、コンピューターのRAMです。

Windows Server 2012 は、最大4 TBの物理メモリをサポートします。これは2 ⁴²バイトです。RAM容量が毎年約2倍に増え続ける場合、わずか17年後に「Windows Server 2032」は2 ⁶²バイトの物理メモリをサポートし、その時点でlow + high2 ^63-2に達し、最大64ビット整数にキスします。

64ビットで十分だと想定して、安全性が重要なシステムに障害が発生しないことを願っています。

少し一般的な用途では、最も適切な物理量はメモリアドレススペースです。（たとえば、メモリに多くのスタックを配置するなど、物理メモリよりもはるかに大きいアドレス空間を使用すると便利です。）現在のx86-64実装は48ビット仮想アドレスをサポートしているため、これらのCPUに到達するまであと14年しかありません 2 ⁶²バイトのアドレス空間制限。

そして分散共有メモリがあります（「物理的に分離された」メモリは1つの（論理的に共有された）アドレス空間としてアドレス指定できます）。

物理量は、オーバーフローまたはアンダーフローなしで64ビット整数で表すことができると仮定するのは妥当ですか？

ではない正確に。それよりも大きい数値と小さい数値の両方がたくさんあるため、浮動小数点数があります。浮動小数点数は、精度を低くすると範囲が広くなります。

あなたが引用した特定の例では、それより大きな数が必要になることはほとんどありません。64ビットは、およそ18クインティリオンの要素に対応します。しかし、決して言わないでください。

あなたの仮定は、浮動小数点数でしか表現できない物理量を処理しません。そして、すべての数に10000を掛けることで値をスケーリングすることにした場合でも（値はまだ整数ですが、1万分の1で表現できます）、このスキームはゼロに非常に近い数、たとえば電子質量（9.1094 *10⎻³¹kg）。

これは非常に現実的な（そして非常に小さい）物理量であり、ここでさらに問題を抱えることになります。そして、それが実際の物理量ではないと主張する場合（kg単位であっても）、以下を考慮してください。

10 kg (obviously physical quantity)
1 kg (same)
10⎻² kg (1/100 kg, or about 1/3 ounce) (also quite real)

これで私がどこへ行くかわかります。最後の1つも処理できません。

もちろん、整数乗数を可変乗数で拡大または縮小するために、数値内に特別なフィールドを持つことができます。浮動小数点を発明したばかりです。

最初に、整数で表現できる/すべき物理的な値は何かという質問に答えますか？

整数は、コンピューターシステムの自然数（およびそれらの差）の表現であるため、他のすべてに適用するのは間違っています。したがって、連続領域に属する距離または他の数量の呼び出しは、引数ではありません。そのような数量には、実数表現があります。そして、常に任意の大きな単位を選択し、任意の値を所定の精度で適合させることができます。

それでは、自然数である物理値とは何ですか？64ビット整数をオーバーフローさせることはできますか？

2つ考えることができます。物理オブジェクト（原子など）の数、および量子システムが取りうるエネルギーレベル。これらは厳密に整数である2つのものです。今、私はあなたが原子を分割できることを知っていますが、それはまだ整数量を生成し、あなたはそれを無期限に分割することはできません。どちらも64ビット範囲の符号なし整数を簡単に超えることができます。原子の数が多くなり、1つの原子が複数のエネルギー状態になる場合があります。

情報が物理的であるかどうかは、非常に議論の余地があります。そうではないと思います。したがって、情報量は物理的なものとは言いません。RAMの量などもそうではありません。これを許可する場合、今日の技術で1ビットを格納するために複数の原子が必要になるため、原子の数はこの数を簡単に超えます。

Jerry101の答えに加えて、正確さのためにこの非常にシンプルで実用的なテストを提供したいと思います。

malloc64ビットOSでを介してメモリを割り当てるとします。メモリアロケータが、要求されたサイズの有効なメモリブロックを返すことを決定したとしましょう。ただし、63番目のビットが設定されています。

言い換えると0xFFFFFFFFxxxxxxxx、の呼び出しから返される可能性のある正当なメモリ範囲であるプログラミング環境が存在すると仮定しましょうmalloc。

問題は、あなたのコードが意図したとおりに機能するかどうかです。

32ビットオペレーティングシステムで同様の状況が発生した場合、一部のソフトウェアに「上半分」のメモリアドレスが与えられていると正しく動作しませんでした。もともと、そのようなメモリアドレスは特権コード（オペレーティングシステム、デバイスドライバー、および周辺機器ハードウェア）でのみ利用可能であると考えられていましたが、32ビットのアドレススペース不足のため、OSベンダーはその予約スペースの一部をそれを要求するアプリケーション。

幸いなことに、この状況は、少なくとも10年ではなく、64ビットプログラムではしばらく起こりそうにありません。

そのような状況が最終的に発生すると、それまでに128ビットのアドレス可能なプロセッサとオペレーティングシステムが主流になり、それらの「レガシーアプリケーション」を動作させるための「64ビットエミュレーション環境」を提供できることを意味します。現在の64ビットオペレーティングシステムと同様の仮定の下で。

最後に、この説明はメモリアドレスのみに焦点を合わせていることに注意してください。特定のタイムスタンプ形式ではマイクロ秒に多くの精度のビットが割り当てられるため、将来の時間を表すために使用できるビットが少なくなるため、タイムスタンプに関する同様の問題をより慎重にとる必要があります。これらの問題は、ウィキペディアの2038年問題に関する記事にまとめられています。

これは、ケースバイケースで尋ねる必要がある質問です。あなたはいけません、正しい量がはるかに小さい範囲であろう場合にも、悪質なデータソースがあなたにオーバーフローする可能性が不合理な量を与えてしまう可能性があるため、64ビット演算がオーバーフローしないという一般的な仮定を使用すること、そしてそれがあることを勧めします予想外にそれに見舞われるよりも、この状況に備えています

64ビット数値の非オーバーフローに依存するコードを作成することが理にかなっている場合があります。私が知っている例の主なクラスはカウンターであり、カウンターは使用されるたびに増分されます。ナノ秒あたり1増分の割合（実際的ではない）でさえ、オーバーフローするのに1世紀以上かかります。

それは最初にシステムの正しさのために、「故障までの時間」に依存する「原則的には常に間違っている」ように見えるかもしれないが、我々はこれを行うことを注意すべての時間を認証/ログインに。（ブルートフォースのために）十分な時間を与えると、そのようなシステムは（パスワード、秘密鍵、セッショントークンなどに基づいて）破損します。

物理量が64ビットに収まらない可能性はありますか？もちろん。他の人は、太陽の原子の数や次の銀河までのミリメートルの数を数えることを指摘しています。そのようなケースがアプリケーションに関連するかどうかは、アプリケーションが何であるかによって異なります。倉庫内の特定のビンにあるアイテムの数を数える場合、16ビットで十分でしょう。さまざまな条件を満たした世界の人々の数に関する統計を編集している場合、数十億を記録できる必要があるため、32ビット以上が必要になります。 37ビット番号などの組み込みサポートがあります）。これがモルに相当する原子をカウントする化学アプリケーションである場合、64ビットでは不十分です。

技術的には、現在コンピュータに2 ^ 64バイトのメモリがないからといって、必ずしも配列インデックスが2 ^ 64を超えてはならないというわけではありません。配列の要素の多くが物理的にどこにも保存されない「スパース配列」と呼ばれる概念があり、そのような保存されていない値はnullやゼロなどのデフォルト値を持つと想定されます。しかし、ある種の配列またはリストを検索する関数を作成していて、配列へのインデックスを保持するために使用しているフィールドのサイズが可能な最大アドレスの2倍以上である場合、 2つのインデックスを追加することは厳密には必要ありません。

64ビット整数がすべての数値を保持できると想定するのは不合理です。複数の理由：

1. 最大および最小64ビット整数は有限数です。有限数ごとに、より大きい有限数と有限数が存在します。

2. 現在、128ビットと256ビットの数値による計算がさまざまな場所で使用されています。多くのプロセッサには、128ビット整数で動作する特定の命令があります。

3. 20年前、1 GBのディスクは「大」と見なされていました。現在、1 TBのディスクは小さいと見なされています。20年前、平均的なデスクトップには約16 MBのRAMがありました。現在のデスクトップには16 GB以上のRAMがあります。ハードディスクのスペースとRAMは過去に指数関数的に成長し、将来的に指数関数的に成長すると予測されています。誰かが成長を停止する非常に正当な理由を考え出すことができなければ、停止すると仮定するのは意味がありません。