37

Rに入る1e9999999999999999999999999999999と、Rはハングし、応答しません-終了する必要があります。

これは、3つの異なるコンピューター、OS（Windows 7およびUbuntu）で発生するようです。これは、RStudio、RGui、およびRScriptで発生します。

数値をより簡単に生成するためのコードを次に示します。

boom <- paste(c("1e", rep(9, 31)), collapse="")
eval(parse(text=boom))

明らかに、これは実際的な問題ではありません。この大きさの数字を使う必要はありません。それは好奇心の問題です。

不思議なことに、1e9999999999999999999999999999998または1e10000000000000000000000000000000（累乗から1を足したり引いたり）しようとするInfと、0それぞれとが得られます。この数は明らかにある種の境界ですが、ここで何となぜの間ですか？

私はそれが次のようになるかもしれないと考えました：

  • 浮動小数点の問題ですが、問題の数よりずっと前の1.7977e308で最大になると思います。
  • 32ビット整数の問題ですが、2 ^ 32は4294967296であり、問​​題の数値よりもはるかに小さくなっています。
  • 本当に変だ。これが私の支配的な理論です。

編集：遅くとも2015-09-15の時点で、これによりRがハングすることはなくなりました。彼らはそれにパッチを当てたに違いありません。

4

3 に答える 3

7

これは興味深いことですが、R には非常に大きな指数を持つ数値の解析に関する体系的な問題があると思います。

> 1e10000000000000000000000000000000
[1] 0
> 1e1000000000000000000000000000000
[1] Inf
> 1e100000000000000000000
[1] Inf
> 1e10000000000000000000
[1] 0
> 1e1000
[1] Inf
> 1e100
[1] 1e+100

さて、最後に合理的なものがあります。この出力と以下の Joshua Ulrich のコメントによると、R は約 2e308 までの数値の表現と、約 +2*10^9 までの指数を使用した数値の解析をサポートしているようですが、それらを表現することはできません。その後、明らかにオーバーフローによる未定義の動作があります。

于 2012-07-28T12:28:01.103 に答える
4

Rはbignumsを使用する場合があります。おそらく1e9999999999999999999999999999999何らかのしきい値であるか、または解析ルーチンの指数を読み取るためのバッファが限られている可能性があります。あなたの観察は、指数の 32 文字 (ヌル終了) バッファーと一致します。

むしろ、友好的であると噂されているRに特化したフォーラムやメーリング リストでその質問をしたいと思います。

あるいは、Rはフリー ソフトウェアであるため、そのソース コードを調査することもできます。

于 2012-07-28T11:53:55.623 に答える