IEEE754のオーバーフロー境界を探った際のThinking記録。Thinking以外は共有URLで見れるのでここでは省略。https://x.com/kawaz/status/2042743948456948216

thinking-opus-4.6.txt

面白い問題。IEEE 754 binary64の最大値と、iPhoneの計算機アプリの内部処理について考える。
binary64の最大有限値はDBL_MAXで、これは(2^53 - 1) × 2^(1024-53) = (1 - 2^(-53)) × 2^1024。
つまり、2^x が表現可能な最大値 DBL_MAX 以下となる最大のxを求めればいい。
DBL_MAX = (2 - 2^(-52)) × 2^1023
ここからlog2を取ると、1023 + log2(2 - 2^(-52))になる。さらに分解すると1 + log2(1 - 2^(-53))が加わるので、結果的にlog2(DBL_MAX) = 1024 + log2(1 - 2^(-53))。log2(1 - 2^(-53))は非常に小さい負の値で、約-2^(-53) / ln(2)程度。
実際に計算してみると、2^53とln(2)の積で割ると約1.6e-16になる。つまりDBL_MAXのlog2値は1024より約1.6e-16だけ小さいということになる。ただ、iPhoneの計算機がこれをどう処理しているかが問題で、内部的には倍精度浮動小数点ではなく任意精度演算やDecimal型を使っている可能性がある。
でも結果がオーバーフローで表示されるということは、最終的にはdoubleに変換しているか、あるいは計算自体がdoubleの範囲内で行われているのだろう。iPhoneの計算機の科学計算モードはC言語のpow関数を使っている可能性が高く、2のべき乗がDBL_MAXを超えるとinfになる。ユーザーが入力した「1023.9999999999999999」という値がdoubleでどう丸められるかが重要で、1024に非常に近い数値をdoubleで表現する場合の丸め方が結果を左右する。
doubleの精度を考えると、1024のすぐ下の値は1024から2^(-42)だけ小さい値になり、この微小な差が指数計算の結果に大きく影響する可能性がある。
1023付近では分解能が2^(-43)程度なので、入力値「1023.9999999999999999」がdoubleに丸められる際に1024に変換されてしまい、その結果が計算に反映されているのかもしれない。
1024は2のべき乗で区間の境界だから、その直前のdouble値は1024 - 2^(-43)で、入力がこれ以上なら1024に丸められてしまう。つまり、pow(2, 1024)を計算することになってオーバーフローが発生している可能性がある。
丸め規則を考えると、1024 - 2^(-44)がちょうど中間点で、round-to-nearest-evenではどちらに丸められるかが重要になってくる。
1024は仮数部の最後のビットが0なので偶数側。[512, 1024)区間では1.f × 2^9で表現され、最大値は1024 - 2^(-43)。[1024, 2048)区間では1.f × 2^10で最小値が1024。この2つの区間の境界付近で、1024 - 2^(-43)と1024の間にある実数がどう丸められるかを確認する必要がある。
中間点は1024 - 2^(-44)で、これより小さい値は1024 - 2^(-43)以下に丸められ、これ以上の値は1024に丸められる。
pow(2, x)の計算を考えると、xが1024(double)なら結果は無限大だが、xが1024 - 2^(-43)の場合、2^1024に非常に小さい補正係数2^(-2^(-43))を掛けることになり、これは約1 - 7.876e-14に相当する。
DBL_MAXは(1 - 2^(-53)) × 2^1024なので、この補正後の値はDBL_MAXより十分小さく、doubleの範囲内に収まる。
つまり、入力値がdoubleで1024に丸められなければpow(2, x)はオーバーフローしない。
境界は入力値が1024 - 2^(-44)以上かどうかで決まり、その値は約1023.99999999999994。ただし、生徒が指摘した数字1023.99999999999999991991433…は1024との差が約8e-18で、これは2^(-44)ではなく別の値のようだ。
iPhoneの計算機がこの差を検出できるのは、doubleではなくlong doubleや80ビット拡張精度、あるいはNSDecimalNumberのような10進数型を使っている可能性が高い。
ただしARMアーキテクチャではlong doubleもdoubleと同じ64ビットなので、おそらくソフトウェアの任意精度演算かGMPのようなライブラリを使っているのだろう。表示可能な最大桁数が9〜16桁程度なので、内部的にはそれ以上の精度で計算しているはずだ。
生徒の観察から見えてくるのは、2の累乗計算で9個の9を入力するとオーバーフローしないが、17個の9を入力するとオーバーフローする点。この差は1e-16と1e-17の違いで、つまりiPhoneの計算機がdouble精度の限界付近で結果を丸めているということだ。
DBL_MAXの上限を数学的に計算すると、2^xがDBL_MAXを超えない条件はxが約1023.9999999999999999以下になることで、これはdouble精度の仮数部52ビットの精度限界と一致している。 ε²/2 - … ≈ -ε (εが小さいとき)
ln(1 - 2^(-53)) ≈ -2^(-53) = -1.1102230246251565e-16
log2(1 - 2^(-53)) ≈ -2^(-53)/ln(2) = -1/(2^53 × ln2)
= -1/6243314768165359.547… ≈ -1.60178…e-16
つまり log2(DBL_MAX) ≈ 1024 - 1.60178e-16
1024 - 1023.9999999999999999(16個の9) = 1e-16 < 1.60178e-16 → OK（2^xがDBL_MAX以下）
1024 - 1023.99999999999999999(17個の9) = 1e-17 < 1.60178e-16 → 1e-17 < 1.60178e-16 → xは1024に近すぎるのでDBL_MAX超え → オーバーフロー
Wait, I need to reconsider the direction here. Since larger x means larger 2^x, when x = 1024 - 1e-16, that’s actually greater than log2(DBL_MAX) = 1024 - 1.60178e-16, which means it would overflow. Let me recalculate to make sure I have the comparison right. I’m realizing my comparison was backwards—1e-16 is actually smaller than 1.60178e-16, which means x = 1024 - 1e-16 is larger and should overflow, yet the student says it works fine on iPhone. This suggests either my understanding is wrong or the calculator isn’t using a simple double pow() function, or perhaps the input itself gets rounded when stored as a double.
Since double precision has about 15-17 significant digits, when a user enters “1023.9999999999999999” into the iPhone calculator, it gets stored as a double. In the [512, 1024) range, double’s resolution is 2^(-43) ≈ 1.137e-13, which is much larger than 1e-16, so the input rounds to the nearest representable value rather than staying at exactly 1024 - 1e-16.
But wait—if it rounds to 1024 itself, then pow(2, 1024) should overflow to infinity. Unless the iPhone calculator is actually processing the input as a string or using higher-precision arithmetic like NSDecimalNumber (which supports 38 digits) before converting to double for the final result. That would explain why the boundary behavior differs from what pure double arithmetic would predict.
Now I’m realizing the exact threshold should be log₂(DBL_MAX) = 1024 minus a tiny correction factor. Let me work through this more carefully—the student’s observation of that long decimal string is probably capturing the fractional part of log₂(DBL_MAX). Since DBL_MAX equals (2 - 2⁻⁵²) × 2¹⁰²³, I can decompose the logarithm and figure out the precise correction term.
The key insight is that 1024 minus log₂(DBL_MAX) equals -log₂(1 - 2⁻⁵³), which I need to compute with high precision using something like Python’s mpmath library. But before diving into that calculation, I should think about what precision the iPhone calculator is actually using when it computes the power function—whether it’s converting the input to a double first, computing with higher precision internally, or something else entirely.
The student’s observation that the boundary sits around 1024 minus 8×10⁻¹⁸ doesn’t quite match log₂(DBL_MAX) = 1024 - 1.6×10⁻¹⁶, which makes me wonder if the calculator might be using a different floating-point format like binary128 or extended precision. Since the iPhone uses ARM architecture, x87 extended precision is out, but I should verify this with actual Python calculations to narrow down what’s happening.
Another angle: the iPhone calculator might have a display digit limit in scientific mode (around 16 significant figures), and treats any result with an exponent exceeding 308 as overflow. Since 2^1024 ≈ 1.798×10^308 and DBL_MAX ≈ 1.798×10^308, if the calculator caps the exponent at 308, then 2^x would overflow once the result reaches 10^309 or higher.
Let me verify this with Python to see what’s actually happening.


すごく面白い話ですね！実際に数値計算で境界を精密に求めてみましょう。
まず仮説を整理してからPythonで検証します。​​​​​​​​​​​​​​​​


なるほど、log2(DBL_MAX) = 1024 - 1.6e-16 だが、生徒が観察した境界は1024 - ~8e-18付近。2桁ずれている。
ということは、iPhoneの計算機はbinary64のDBL_MAXとは異なる上限を持っている。
生徒が正確に言っている数値「1023.99999999999999991991433…」から逆算すると：
1024 - 1023.99999999999999991991433 = 8.008567e-18
では、この差異の原因は何だろう。iPhoneの計算機がNSDecimalNumberのような独自の精度で計算しているのか、それとも入力桁数の制限が関係しているのか。科学計算モードでも入力できる桁数には上限があるはずで、その制約が結果に影響しているかもしれない。 So the input “1023.999999999999999” has 20 digits if I count just the numbers, but 21 characters including the decimal point. The iPhone calculator’s input limit in scientific mode appears to be around 16 digits, which means “1023.999999999999” would hit that ceiling—that’s exactly 16 digits, so this would be the maximum I could enter before hitting the constraint.
But wait, the student actually reported entering 9s sixteen times after 1023, which means they’re inputting 20+ digits total. That suggests the iPhone calculator accepts more than 16 digits when entering horizontally, or perhaps the exponentiation operation itself is where the precision gets lost during calculation rather than at input.
Actually, I think the real issue might be simpler—the iPhone calculator’s y^x button could be implemented using exp(x * ln(y)), and that intermediate calculation is where double precision hits its limits. When computing 2^1024 this way, x * ln(2) equals roughly 709.78, which is right at the overflow threshold for exp() in double precision, since ln(DBL_MAX) is approximately 709.
	78.	But the actual problem might be the precision of calculating x * ln(2) itself, or perhaps the input x is being stored as a string and computed with higher precision arithmetic. Let me try a different angle and look at the actual boundary value the student observed—2^(1023.99999999999999991991433…) seems to be where it breaks, which is about 8 × 10^-18 away from 1024.
Now I’m examining whether this tiny difference relates to floating-point precision limits. The gap of roughly 8 × 10^-17 might connect to how doubles represent numbers near DBL_MAX, and I need to look more carefully at where exactly the student’s boundary value sits relative to the precision limits. 8.008567e-17 is exactly half of the log2(DBL_MAX) boundary value, which means the actual rounding boundary isn’t at log2(DBL_MAX) itself but at the midpoint between that and infinity—this is a rounding behavior when converting the result back to a double. いや、DBL_MAXの次のdouble値はinfだから、DBL_MAXを超えたらinfになる。
でもpow関数の実装では、正確な値がDBL_MAXを超えるかどうかで判定される。問題は丸めモード。
あ、でも「半分」というのは面白い。
考え直す：pow(2, x)の結果が最も近いdoubleに丸められるとき、DBL_MAXとinfの間の中間点を超えるとinfに丸められる。
IEEE 754のround-to-nearest-evenルールでは、正確な結果が(2 - 2^(-53)) × 2^1023を超えたらinfに丸められる。これはDBL_MAXと2^1024のちょうど中間点で、つまりDBL_MAXとinfの境界値がこの中点になるということだ。
log2((2 - 2^(-53)) × 2^1023)を計算すると、1024 - 1/(2^54 × ln2)になる。これは約1024 - 8.0086e-17で、生徒の値とぴったり一致する！
つまり、pow(2, x)がinfに丸められるのはxがこの値を超えたときで、その値が1024 - 1/(2^54 × ln2)ということだ。
iPhoneの計算機は内部的に高精度でべき乗を計算してから、doubleに変換するときにround-to-nearest-evenルールを適用しているから、DBL_MAXと+infの中間点を超えるとオーバーフロー表示になるわけだ。


面白い。log2(DBL_MAX)と生徒の観察値に2桁のずれがあります。次の仮説を検証します：IEEE 754の丸めルール（round-to-nearest-even）では、DBL_MAXと+∞の中間点を超えるとinfに丸められるはず。​​​​​​​​​​​​​​​​


完璧に一致した！生徒の観察値「1023.99999999999999991991433…」は理論値「1023.9999999999999999199143374…」と7桁まで一致している。
つまり答えは：
iPhoneの計算機は：
	1.	高精度（おそらくソフトウェアの任意精度演算）で2^xを計算
	2.	結果をIEEE 754 binary64 (double) に変換
	3.	round-to-nearest-evenルールにより、(2-2^(-53))×2^1023を超えるとinfに丸められる
	4.	infが返ってきたら「オーバーフロー」と表示する
境界値は log2((2-2^(-53))×2^1023) = 1024 - 1/(2^54 × ln2)で、生徒が指摘した「2^(-53.4712336)と2^(-53.4712337)の間」という観察がこの理論と一致するか確認してみよう。


ビンゴ！生徒の観察値と理論値が完全一致しています。生徒の「2^(-n)の形では？」という予想も検証しましょう。​​​​​​​​​​​​​​​​


素晴らしい。すべてが完璧に一致している。
まとめ：
	1.	iPhoneの計算機は内部的に高精度で2^xを計算している
	2.	結果をIEEE 754 binary64に変換する際、round-to-nearest-evenが適用される
	3.	DBL_MAX = (2-2^(-52))×2^1023 と +inf (=2^1024) の中間点は (2-2^(-53))×2^1023
	4.	2^x がこの中間点を超えるとinfに丸められ、「オーバーフロー」表示になる
	5.	オーバーフロー境界のxは log2((2-2^(-53))×2^1023) = 1024 - 1/(2^54 × ln2) で、1024との差は約8.009×10^(-17)
	6.	これを2^(-n)で表すとn ≈ 53.4712336となり、生徒の観察と完全に一致する
	7.	さらに入力桁数の問題も関係している
。16個の9では差が1e-16で中間点以下となるため2^xはDBL_MAXに丸まるが、17個の9では差が1e-17で中間点を超えるため無限大に丸まってオーバーフローする
8. 16個の9の後は次の桁が1でなければならず、2では不十分という制約がある
9. iPhoneの計算機は入力値を高精度で保持しているようだが、doubleの分解能は1024付近で約1.1e-13なので、1024-1e-16はdoubleでは1024に丸まってしまう
。つまり、iPhoneの計算機はdoubleではなく、NSDecimalNumberか文字列形式のような、もっと高精度なデータ型で入力値を管理しているのだろう。


全て辻褄が合いました。まとめの解説を書きます。​​​​​​​​​​​​​​​​


全ての観察が綺麗に説明できました。以下がまとめです。

thinking-sonnet-4.6.txt

面白い問題だ。iPhoneの計算機アプリの内部実装について深掘りしよう。
まず、IEEE 754 binary64（倍精度浮動小数点数）の基本を確認する。
IEEE 754 binary64の基本
	•	符号: 1ビット
	•	指数部: 11ビット
	•	仮数部: 52ビット（暗黙の1を含めると53ビット）
最大値は約1.7976931348623157 × 10^308
2^1024はオーバーフローするが、最大有限値は(2-2^(-52)) × 2^1023に達する。
2^xの計算で、オーバーフローしない最大のxを探っている。IEEE 754の制約から、2^xが表現可能な最大値は2^1024 - 2^971となるため、xの上限はこの値に基づいて決まる。
ただ、iPhoneの計算機がdoubleより高精度で計算している可能性を考えている。macOSではlong doubleやx87拡張精度を使うことがあるが、iOSはARMアーキテクチャなので拡張精度は利用できない。実は、iPhoneの計算機はDecimal型を使っているのではないかと推測している。
Apple計算機の実装を調べると、macOS/iOSの計算機アプリはDecimal128（128ビット10進数）を内部的に使っているという情報がある。問題の境界値2^(1023.99999999999999991991433…)を精密に分析することで、iPhoneの計算機がどの精度で計算しているかを推測できるはずだ。
1024と1023.99999999999999991991433…の差を計算してみると、約8.008567 × 10^-20になる。この値が何を意味するのか、2^(-53.4712336)のようなべき乗との関係を調べているが、オーダーが異なるようだ。
生徒が指摘しているのは、9が16個の場合は計算可能だが17個になるとダメになるということで、その境界がどこにあるのか、そして指数部の計算と実際の2のべき乗の関係がどうなっているのかを整理する必要がある。xの正確な境界値を特定するために、1023.9999999999999999付近での挙動を詳しく調べている。
doubleの精度制限を考えると、1024に非常に近い値がどのように表現されるかが重要で、1024の直前のdoubleは1024 - 2^(-42)になるはずだが、実際の計算結果との関係をもっと詳しく確認する必要がある。
iPhoneの計算機がどの数値型を使っているかが鍵で、NSDecimalNumberのような高精度10進数型を使っている可能性もあれば、ARMアーキテクチャではlong doubleがdoubleと同じ64ビットになるため、拡張精度は利用できない。
生徒が発見した境界値を改めて整理すると、doubleの最大値を超える条件はxがlog2(doubleの最大値)より大きくなるときで、その値は約1024付近になる。
log2(1-2^(-53))の近似計算から、正確な閾値はほぼ1023.99999999999999984…となるが、実際の問題は入力xがdouble精度で受け取られ、その精度の制限内で2^xが計算されるという点にある。
生徒の観察から逆算すると、閾値は2^(1024-2^(-53.4712336))と2^(1024-2^(-53.4712337))の間にあり、この指数部分を計算すると約1024 - 8.02 × 10^-17となる。
ただし、生徒が示した「1023.99999999999999991991433」という値から計算すると単位が合わないので、もう一度問題文を確認して、この値が実際には指数そのものを表しているのか、それとも別の意味なのかを整理し直す必要がある。
問題文の「境界は2^(1024-2^(-53.4712336))と2^(1024-2^(-53.4712337))の間」という表現から、xの値そのものではなく、1024との差が2^(-53.4712336)から2^(-53.4712337)の間にあるということを意味していると考え直して、xの範囲を(1024 - 2^(-53.4712337), 1024 - 2^(-53.4712336))として再解釈する。そして2^(-53)の値を計算してから、2^(-0.4712336)の値を求めることで、全体の差分を明確にしようとしている。
計算を進めると、境界のxは約1024 - 8.008 × 10^-17となるが、doubleの精度で実際にこの値が表現できるかを確認する必要があり、doubleの52ビット精度を考慮しながら検証を進めている。 1023.9999999999999999（9が16個）という値が出てくるのは、計算機がdouble精度ではなく、decimal128のような高精度の10進数形式でxを保持しているからだと考えられる。iOSのNSDecimalNumberなら38桁の10進精度があるので、この値は実際に意味を持つ。exp(x × ln(2))のようなアプローチで2^xを計算する場合、その精度が結果に大きく影響してくる。
具体的に計算してみると、x = 1023.9999999999999999のときにx × ln(2)を求めると約709.78になるが、これはdouble精度のln(2)を使った場合の丸め誤差の影響を受けている。doubleの最大値がおよそ1.7976931348623157×10^308なので、2^1024はこれを超えてオーバーフローする閾値に非常に近い位置にある。
ln(DBL_MAX)を計算すると、971×ln(2)とln(2^53-1)の和になり、結果として約709.7827128933840から非常に小さい誤差を引いた値になる。
iPhoneの計算機がこの問題にどう対処しているかは、実装がオープンソースではないため直接は確認できないが、いくつかの推測ができる。
表示桁数の制限と境界値の精密な解析が鍵になるだろう。実際にPythonで計算してみれば、double精度のexp()関数を使った場合の正確な境界値が求められる。C言語のldexp(1.0, x)とexp(x * log(2))では計算精度が異なる可能性があり、iOSの計算機アプリがかつてGNU BCを使っていたという情報もあるので、その実装方式が結果に影響しているかもしれない。
pow(2.0, 1023.0)は正常に計算できるがpow(2.0, 1024.0)はINFになる点から、指数が整数でない場合の挙動を調べる必要がある。pow()関数がexp(x * log(2.0))で実装されている可能性が高いので、その計算精度がどこまで保たれるかが重要だ。DBL_MAXの対数値log2(DBL_MAX) = 1023 + log2(2 - 2^(-52))という関係式から、正確な境界値を逆算できるはずだ。
計算を進めると、この値は約1024 - 1.6×10^-16となり、計算機がdouble精度でpow()を実装しているかどうかで実際の境界値が変わってくる。
Pythonで検証してみる必要があるが、doubleの最小値制限では1024 - 2^(-42)が理論値なので、観測される境界とは合致しない可能性がある。そこで、計算機が高精度の10進数ライブラリ（Decimalやdecimal128など）を使って2^xを計算し、doubleへの変換時にオーバーフロー判定をしているという仮説を立てている。 次のdoubleの値を正確に計算するために、ビット表現を詳しく見ていく必要がある。1024.0と1023.0の間でdoubleがどのように表現されるかを確認して、pow(2.0, x)がDBL_MAXを超える境界を特定しよう。 So the double value just before 1024 is 1024 × (1 - 2^(-53)), which equals roughly 1023.9999999999999 with thirteen 9s after the decimal point. This means double precision can only represent about thirteen 9s, but the problem states the calculator handles sixteen 9s—suggesting it’s using extended precision beyond standard double, likely 80-bit long double format.
However, I realize iOS ARM processors don’t actually support 80-bit extended precision. So the calculator must be using decimal128 instead, which provides 34 digits of decimal precision and can represent values like 1023.9999999999999999999999999999999.
But that’s 33 nines, which exceeds the “16 nines” boundary mentioned in the problem, so that doesn’t match either. I’m wondering if iOS’s NSDecimal with its 38-digit precision, or perhaps some other implementation with smaller precision, is what’s actually being used here.
Let me think about how the actual pow function works in practice—most libm implementations compute pow(2.0, x) using either exp2(x) or exp(x × ln(2)), breaking it down into integer and fractional parts.
The key issue is that when x is non-integer, the calculation of x × log(2) introduces precision errors that could explain the threshold. I’m also considering whether Apple’s calculator might be using BCD (Binary Coded Decimal) like older systems did.
To really understand this, I need to test several precision levels: standard double precision, 80-bit long double on x86, decimal128, and see where each one hits its limit for the difference from 1024.
Now I’m going to write a Python script to compute the actual thresholds and examine the internal representation of these floating-point values.
Let me analyze the specific value the student mentioned—1023.99999999999999991991433—to understand what the nearest representable double actually is, and I’m noticing the difference from 1024 is around 8 × 10^-20, which is smaller than what extended precision can represent, so there’s something interesting happening with how the exponent affects the precision at this boundary. 境界値xの正確な値は1024に非常に近いが、その差は2^(-53.4712336)程度で、これはdouble精度のULPより遥かに小さいため表現不可能だ。実際の入力値「1023.99999999999999991991433」との差はさらに微小で、ここで何か計算の混乱が生じている。
問題文を改めて確認すると、境界は2^(1024-2^(-53.4712336))と2^(1024-2^(-53.4712337))の間にあり、つまりxの範囲は1024 - 2^(-53.4712337) < x_boundary < 1024 - 2^(-53.4712336)ということのようだ。
2^(-53.4712336)の値を計算してみると、2^(-53) × 2^(-0.4712336)に分解でき、指数部分の対数を取って近似値を求めている途中だ。
計算結果は約8.008 × 10^-17になり、これを使うとx_boundary ≈ 1023.99999999999992…となるが、問題文に示されている値「1023.99999999999999991991433」（9がより多く続く）と桁数が合わないので、計算の前提か問題の定義を改めて確認する必要がある。
実は「2^(1024-2^(-53.4712336))」という表現は、単なる数式ではなく、計算機で実際に計算した2^xの値の境界を指しているのかもしれない。
ただし2^1024自体がすでにオーバーフローしているので、この解釈も矛盾している。問題文を改めて考え直すと、境界値xは1024 - 2^(-n)の形をしているのではないかと予想している。
もし x = 1024 - 2^(-53.4712336) なら、小数部は9が13個続いた後に1992…となるはずだが、問題では9が16個までOKと言っているので、この値がちょうど境界線上にあるのかどうか確認が必要だ。
問題の表記を改めて整理すると、16個の9で終わる値と17個の9になる値の間に閾値があり、16個の9の直後は1でなければならないという制約があるようだ。
その境界値を正確に計算すると、2^(-53.4712336)と2^(-53.4712337)の間に位置していて、どちらも約8.008 × 10^-17という非常に近い値になっているが、10^-16と10^-17のスケールの違いで何か矛盾が生じているのかもしれない。
実は問題文の「2^(1024-2^(-53.4712336))」はxの値そのものを指していて、x_boundary ≈ 1024 - 2^(-53.4712336)となり、これを展開すると1023.99999999999992…という形になるはずだが、小数点以下の9の個数を正確に数えると何か違う可能性がある。
計算機の内部精度や変換処理が複雑に関わっているのかもしれないので、Pythonで直接検証してみる必要がある。doubleの限界値付近での挙動を確認し、「9が16個」という条件がdoubleで実際に表現可能かどうかを調べるつもり。
Writing Python analysis… これは違う…
doubleのnextafterを試してみて、Pythonの math.nextafter を使って1024.0より小さい最も近い値を調べている。
計算機が10進数ベースで動作している場合、NSDecimalの38桁精度を活用しながらも、表示は16桁程度に制限されているのではないかと考えている。
重要な仮説として、計算機が16桁精度の10進数で入力を保持し、その後doubleに変換して exp2 や pow で計算している場合、1023.9999999999999999（9が16個）をdoubleに変換するとどうなるかを確認する必要がある。
doubleの精度は約15-17桁なので、この値が1024.0に丸められる可能性があり、もしそうなれば pow(2.0, 1024.0) はオーバーフローする。
ただし問題では「9が16個はOK」と述べられているので、計算機は内部でdoubleに変換せずに高精度のまま計算しているか、あるいは x を pow に渡す前に x < 1024 のチェックを行っているのかもしれない。
別の可能性として、計算機が exp(x × ln(2)) で2^xを計算している場合も考えられるが、実際のところは計算してみないと判断できない。
Pythonを使って境界値を精密に計算し、doubleやlong double、decimalなど各精度での閾値を調べて、iPhoneの計算機がどの内部実装を使っているのか推測してみよう。


興味深い！log2(DBL_MAX) が Python では 1024.0 と表示されているが、これは計算精度の問題。実際には log2(DBL_MAX) < 1024.0 のはず。
また、float('1023.99999999999999') は既に 1024.0 に丸められている。これは9が14個のケース。
でも問題文では「9が16個はOK、17個はNG」と言っている。これはdoubleの話ではない！
計算機は10進数の高精度で内部計算しているに違いない。Python の ** 演算子の挙動を確認するために math.pow を試してみて、さらに mpmath で高精度計算を行って log2(DBL_MAX) の正確な値を調べる必要がある。


math.pow(2, 1024.0) はオーバーフローするのか。nextafter(1024.0, 0.0) = 1023.9999999999998863… はOKで、1024.0 はNGということ。
次に mpmath をインストールして使おう。


重要な発見！
9が13個まではdoubleで1024.0未満に変換されるが、9が14個以上になると1024.0に丸まってしまう。
でも問題文では「9が16個まではOK、17個はNG」と言っている。
これは計算機がdoubleで入力を受け取っているわけではなく、10進数の文字列として入力を保持していることを意味する。
計算機の内部で：
	•	ユーザー入力を文字列または高精度10進数として保持し、計算時に高精度関数を呼び出している可能性がある。もしくは独自の高精度10進ライブラリを使っているのかもしれない。
そして「log2(diff) = -52.47123363」という値が出てきた。これは生徒が指摘していた「境界は2^(1024-2^(-53.4712336))と2^(1024-2^(-53.4712337))の間」という理論と一致している。
ただ、生徒の値「-53.4712336」と私の計算結果「-52.47123363」を比べると、符号と整数部分で1違う感じがする。生徒の計算にズレがあるのか、それとも理論的な導出を確認する必要があるのか。理論的には1024 - log2(DBL_MAX) = 1/(ln2 × 2^53)という関係があり、log2(1/(ln2 × 2^53)) = -log2(ln2) - 53という形になるはずだが、ここで計算を詰めていく必要がある。 生徒が53を使ったのは計算ミスか誤記の可能性があり、正しい値は52のようだ。生徒が報告した「1023.99999999999999991991433」という値から逆算してみると、差分は約8.008567 × 10^-20で、これをlog2で変換すると…
計算が大きく外れている。私の計算では「1/(ln2 × 2^53) ≈ 1.602 × 10^-16」なので、報告値との乖離は3桁以上ある。問題文をもう一度確認してみると、生徒は2^(1024-2^(-53.4712336))と2^(1024-2^(-53.4712337))の間に境界があると予想しているようだ。
ただ「より正確には同じ範囲」という表現は矛盾しているように見えるので、おそらく問題文に誤記があり、より精密な数値が本来は記載されるべきだったのだろう。
あるいは「2^」が余分で、境界の値は指数部分の1024-2^(-53.4712336)と1024-2^(-53.4712337)の間にあるという意味かもしれない。その場合、2^(-53.4712336)は約8×10^-17という極めて小さい値なので、境界のx値は1024に非常に近い値になる。
でも問題文が9の個数について言及しているのに対して、計算結果が合わないから、もしかして「2^(1024-2^(-53.4712336))」という表記全体が指数を表しているのではなく、計算結果そのものを表しているのかもしれない。
つまり x_boundary ≈ 1024 - 8 × 10^-17 で、この値が9が16個と17個の間の境界を説明するはずなのに、まだ何か解釈が足りていない。
小数点以下の桁数を数え直してみると、1024 との差分は 8 × 10^-15 のオーダーになるようで、2^(-53.47) の計算を確認する必要がある。
実際には、生徒が指数部分の -53.4712336 に注目して、1024 との差がどのオーダーかを表現しているのかもしれない。もっとシンプルに考えると、実際の計算機での検証は x = 1023.{複数の9}{追加桁} を入力して 2^x を計算し、オーバーフローが起きるかどうかを観察しているということで、9が16個の場合はオーバーフローしないということが確認できている。
9が17個だとオーバーフローし、16個の9の次の桁が1ならOK、2ならNGという観察から、境界値は 1023.99999999999999991… と 1023.99999999999999992… の間にあることがわかる。この差は約 10^-20 のオーダーなのに対して、2^(-53.4712336) は約 10^-17 なので、全く一致していない。
もしかして生徒の「2^(1024-2^(-53.4712336))」という表現は、x = 1024 - 2^(-n) という形で計算機に直接入力してテストしたということで、n の値を調整して境界を探していたのかもしれない。
つまり、n が 53.4712336 と 53.4712337 の間で、計算結果が有効から無効に変わる転換点があるということなんだ。
その境界での Δ は約 2^(-53.47) で、x_boundary は 1023.99999999999992 あたりになる。
ただ、観察では 9 が 16 個まで大丈夫だったのに、計算上は 9 が 13 個程度のところで境界があるという矛盾が生じている。もしかして計算機が内部的に 10 進数で処理していて、入力文字列を 20 桁程度の精度で保持しながら 2^x を計算しているのかもしれない。その場合、変換の精度限界によって、9 が 16 個ある入力でも正確に計算できる可能性がある。 計算機が高精度で 2^x を計算している可能性がある。
例えば：
	•	x = 1023.99999999999999991… を「1023 + 0.99999999999999991…」と分解
	•	2^1023 は正確に計算
	•	2^0.99999999999999991… ≈ 1.99999999999999987… を計算
	•	掛け合わせると 1.9999…×10^308 ≈ DBL_MAX
この計算精度が「何桁まで正確か」が問題。
生徒の観察：
	•	「x = 1023.99999999999999991991433」が境界付近
	•	1024 - x ≈ 8.0086 × 10^-20
もし計算機が内部的にDecimal64を使っているなら、16桁の10進精度で数値を扱っている。「1023.9999999999999999」は16桁で正確に表現できるが、「1023.99999999999999991」は17桁になるため表現不可能になる。これが9が16個までOKで17個がNGという現象の説明になるかもしれない。 計算機が16桁を超える入力を受け付けているなら、内部では高精度で数値を保持しているはずだ。「9が16個の次が1はOK、2はNG」という境界線の存在は、計算機が16桁以上の精度で計算を行っていることを強く示唆している。つまり、表示は16桁に制限されているかもしれないが、内部的には2^xの計算をより高い精度で実行しているのだろう。
iPhoneの計算機がどの浮動小数点形式を使っているかを考えると、ARMアーキテクチャではlong doubleは64ビットなので、代わりに128ビットの四倍精度浮動小数点数を採用している可能性がある。四倍精度なら仮数部が113ビットで約33.6桁の10進数精度を持つため、1024付近でのULPは非常に小さくなり、「9が16個」という観測と一致する。
ただし、生徒の計算結果を見ると、彼らが指摘する境界値が私の理論計算と1ずれているのが気になる。生徒は2^(-53.4712336)と2^(-53.4712337)の間に境界があると言っているが、私の計算では-52.471が出ている。もしかして生徒は2進数での二分探索を使って正確なnの値を求めたのかもしれない。
いずれにせよ、2^(-53.47)は約8×10^-17で、これはlog2(DBL_MAX)との差と同じオーダーだ。そして「-53」という整数部分はbinary64の仮数部ビット数（53ビット）と一致しているのが興味深い。
iPhoneの計算機が128ビットのDecimal型を使って入力を保持しながら、pow(2.0, x)でdouble計算をしている可能性を考えると、xをdoubleに変換する際に1024.0に丸まってしまう可能性がある。
ただし「9が16個まではOK」という結果から考えると、計算機はdoubleへの変換を避けて直接計算しているはずだ。別の仮説として、AppleはNSDecimalを使って2^xを実装しており、xを整数部と小数部に分けて、2^整数部と2^小数部（exp(小数部 × ln(2))で計算）を組み合わせることで、38桁の精度を保ちながら計算している可能性がある。
doubleへの最終変換時にオーバーフロー検出を行うなら、その閾値はdoubleの最大値付近になるはず。実装としては、計算機が内部で高精度の10進数や長整数を使って計算し、結果をdoubleに変換して表示するアーキテクチャが考えられる。あるいはiPhoneの計算機がlong doubleを使っている可能性もあり、macOSの80ビット拡張精度とは異なる実装になっているかもしれない。
計算機の動作を仮定すると、ユーザー入力を高精度で保持しておき、2^xを計算する際にxをdoubleに変換してからpow関数を呼び出し、結果を表示するという流れになるだろう。
xをdoubleに変換すると、1023.9999999999999（9が13個）は約1024 - 2^(-43)に丸められ、1023.99999999999999（9が14個）は1024.0に丸められてしまう。しかし計算機は「9が16個まではOK」と言っているので、この仮説は成り立たない。つまり計算機は入力を文字列または高精度10進数として保持したまま、doubleへの変換を経由せずに計算を行っているはずだ。Apple Calculatorは最低20桁以上の高精度10進数として入力を保持している可能性が高い。
2^xの計算には複数の高精度演算が使われ、最終的にdoubleまたは表示用のDecimalとして出力されている。内部実装としては、拡張精度浮動小数点数、NSDecimalNumber、カスタムBCD実装、あるいはdoubleのpow関数で引数の処理を工夫している可能性があり、最も可能性が高いのはNSDecimalNumberか独自の高精度実装だ。NSDecimalNumberの最大値は約10^127.9999…なので、この範囲内での計算が行われている。
ただ、NSDecimalNumberの最大値はdoubleの最大値より小さいことに気づいた。実装を考え直すと、iOS計算機は入力をNSStringで保持してからNSDecimalNumberまたはstrtod()で変換し、pow(2.0, x)で計算している可能性が高い。strtod()で変換する場合、9が14個以上は1024.0になるため、理論上の境界は「9が13個と14個の間」になるはずだが、実際の境界は「9が16個」になっているのは興味深い。
もしかして、計算機は入力を文字列のまま保持して、べき乗計算時に高精度ライブラリを使っているのではないか。10進16桁程度の精度（約53ビット）があれば、「9が16個まで区別できる」という観察と一致する。
実は、iPhoneの計算機はdouble精度の内部処理ではなく、ソフトウェアで10進数計算をエミュレートしているのかもしれない。20〜25桁の精度を持ちながら、最終的にdoubleに変換して表示しているなら、その境界値の挙動をもっと詳しく調べる必要がある。
例えば「2^1023.9999999999999999」（9が16個）を計算する場合、内部の高精度10進数演算では2^1024に非常に近い値を得るが、その微小な差分がdoubleに変換される際にどう丸められるかが鍵になる。
計算結果がDBL_MAXを超えるとオーバーフローになるはずだが、実際の丸め処理によってはオーバーフローを回避できる可能性もあり、その境界線を正確に把握する必要がある。
2^1024に非常に小さい補正係数を掛けた値がどこに落ち着くかで判定が変わってくる。
計算結果は約3.6 × 10^308で、これはDBL_MAXの約1.8 × 10^308をはるかに超えているはずなのに、問題文では9が16個の場合はオーバーフローしないと言っている。もしかして「OK」の意味を誤解していて、実際には「計算機での表現が可能」という別の意味なのかもしれない。
問題文を改めて確認すると、2^1023は指数表示で答えが表示されるがオーバーフロー表示にはならず、2^1024はオーバーフロー表示になるということで、つまり2^(1023.9999999999999999)（9が16個）までは大丈夫ということなんだ。
でも待って、この値はDBL_MAXを超えているはずなのに…あ、計算機アプリが内部で高精度の十進数を使っているから、オーバーフロー判定の基準が異なるのか。
つまり、計算機自身の内部表現での上限値に基づいて判定しているのであって、doubleの最大値ではないということか。でもそれでも矛盾が残る。もう一度考え直す必要があるな。iPhoneの計算機が科学計算モードで実際に何桁まで表示できるのか、そこが鍵になるかもしれない。
計算機の表示精度は15桁程度だから、2^(1023.9999999999999999) ≈ 3.6 × 10^308 のような形で表示されるはずだ。この値がdoubleの最大値を超えているのに計算機がOKと判定するのは、内部でdoubleより高い精度で計算しているか、doubleを使っていない可能性がある。iPhoneの計算機の実装方式を整理し直す必要がありそうだ。
考えられるのは、long doubleのような拡張精度浮動小数点数、NSDecimalNumberなどの高精度ライブラリ、quad precision（128ビット）、あるいはDecimal128（IEEE 754-2008の128ビット10進数）を使っているケースだ。特にDecimal128なら34桁の10進精度と±6143の指数範囲を持つから、この挙動を説明できるかもしれない。
観察から逆算してみると、2^1024でオーバーフローするが、2^(1023.9999999999999999)（9が16個）は成功して約3.6×10^308を表示し、9が17個だとオーバーフローする。もし計算機が内部で高精度10進数を使っているなら、このオーバーフロー条件がどこで発生するのかを特定する必要がある。
16桁の10進数表現なら指数308の値は表現できるはずなのに、なぜ9が17個で失敗するのか、その境界値を探る必要がある。
計算機が2^xを計算する際、内部では指数と対数の乗算を行っているはずで、その精度の制限が鍵になっているのではないか。
1023.9999…の場合は16桁精度で丸まらずに計算できるが、9がもう1桁増えると1024に丸まってしまい、結果が変わる可能性がある。ただAppleの計算機のソースコードが公開されていないので、実装の詳細は推測するしかない。
もしかしたら高精度版のpow関数やexp2関数を使っているのかもしれない。
観察から見えるのは、入力精度が約16桁で、計算精度も17〜18桁程度あり、何らかの閾値と比較して結果を判定しているということ。その閾値の正確な値と計算方法を特定するのが次のステップ。
最も単純な説明は、計算機が高精度10進数で入力を保持しながら、2^xを計算する際にxをdoubleに変換して、その丸め処理がこの境界を生み出しているのではないか。例えば「1023.9999999999999999」（9が16個）はdoubleに変換される時点で1024.0に丸められ、その結果pow(2, 1024.0)がオーバーフローを引き起こすという仕組み。
ただし問題文で「9が16個はOK」という条件があるため、この仮説も完全には説明できていない。
結局のところ、iPhoneの計算機がどのように内部で高精度計算を実装しているかは、実際のアプリをリバースエンジニアリングするか、Appleの資料を見ない限り正確には分からない。ただ観察から推測できるのは、計算機は少なくとも16桁以上の小数精度で入力を保持しているということだ。
もう一度問題文を確認すると、9が16個の場合は大丈夫だが、doubleで計算すれば9が14個以上で1024.0に丸まってしまい、pow(2, 1024.0)はINFになるはずなので、計算機はdoubleより高い精度で2^xを計算しているに違いない。
もしかして計算機は整数部と小数部に分けて、2^1023 × 2^0.9999999999999999という形で計算しているのかもしれない。
0.9999999999999999をdoubleで表現するとき、これは1 - 10^-16に相当するけど、doubleの精度では10^-16がどう丸められるかが重要になってくる。
nextafterで得られる1.0 - 2^(-52)との比較を考えると、0.9999999999999999は実際には1.0に丸まらずに別の値として保持されるはずだ。
10^-16と2^(-53)の関係を見ると、doubleの精度限界内で1 - 10^-16がどう表現されるかが鍵になる。
doubleで表現できる1の直前の値は1 - 2^(-52)で約0.9999999999999997なので、0.9999999999999999はこれより大きく、1.0に丸まってしまう。実際にPythonで試してみると、float(“0.9999999999999999”)が1.0になるかどうかを確認する必要がある。
もし計算機が内部で指数部分と仮数部分を分けて計算していて、小数部の0.9999…がdoubleで1.0に丸まれば、2^1023 × 2 = 2^1024となってオーバーフローするはずだが、「9が16個はOK」という結果と矛盾している。この仮説は成り立たないようだ。
つまり、iPhoneの計算機は何らかの高精度ライブラリを使っているに違いない。
おそらくAppleが独自に実装したDecimal128のような10進数ライブラリで2^xを計算し、結果が表示可能な範囲を超えたらオーバーフローと判定しているのだろう。
つまり、高精度で計算してからdoubleの最大値と比較することで、より正確なオーバーフロー判定を行っているということだ。
高精度計算の精度が約16〜17桁であることが、「9が16個はOK、17個はNG」という境界を説明している。
実際に16個の9の次が1ならOK、2ならNGという精密な分岐点から逆算すると、その境界は1023.999999999999999911…と1023.9999999999999999912…の間にあり、1024との差を詳しく調べることで計算精度の限界が見える。
差分を対数スケールで評価すると約2^(-63)程度になるはずだが、理論値の1.602 × 10^-16と大きく乖離しているので、この数値が実際の浮動小数点の境界値そのものなのか、それとも別の要因があるのか再検討が必要だ。
問題文の表記「2^(1024-2^(-53.4712336))」が指数部分を表しているのか、それとも実際の値を表しているのか、解釈を確認する必要がある。
計算を進めると、2^(-53.4712336)は約8.007×10^-17で、これを使って2^(1024-2^(-53.4712336))を展開すると、最大浮動小数点数の近くで非常に小さな補正項が現れる。
結果は約3.595×10^308になるが、これはdoubleの最大値を超えている。
混乱が深まってきたので、もう一度シンプルに整理し直す。生徒の観察から、9が16個までは計算が成功するが17個では失敗する境界が見えている。この現象を説明する最も単純な仮説として、計算機が16桁の有効数字で10進数を処理しているのではないかと考えている。
その場合、1023.9999999999999999と1023.99999999999999999の違いは有効数字の桁数にあり、16桁精度での丸め処理がどう働くかが鍵になる。
整数部が4桁なら小数部には12桁しか残らないはずだが、問題文では16桁の9までOKと言っているので、計算機の内部精度がもっと高い可能性がある。iPhoneの計算機がどの程度の精度で動作しているのか確認する必要がありそうだ。
もしかして「9が16個」という境界は、doubleの有効数字とは別の理由で決まっているのかもしれない。計算機が単純に16桁の表示と入力に対応しているだけで、小数点以下16桁まで受け付けているのではないだろうか。
17桁目以降は丸められるか、オーバーフロー表示になるのかもしれない。
9が16個までは正常に計算されるけど、17個になるとシステムが限界に達してエラーを表示するということか。つまり、入力値が変わることで計算結果が変わり、その閾値が16桁と17桁の間にあるということだ。
これは計算機の内部精度が少なくとも10進17桁以上（整数部4桁と小数部17桁で合計21桁の有効数字）であることを示唆している。
doubleの約15.9桁精度を超えているので、doubleを直接使用していないのは確実だ。考えられる可能性としては、80ビット拡張精度、quad precision、独自の高精度ライブラリ、あるいは任意精度演算が挙げられる。最も可能性が高いのは、iPhoneの計算機がMacOSのMathKit.frameworkを使用していて、内部でfloat80相当の演算をソフトウェアエミュレーションしているか、あるいは別の高精度実装を採用しているということだ。
実際にquad precision（binary128）を使用していると仮定すると、仮数部が113ビットで約33.4桁の精度を持つため、1024付近ではULPが約2×10^-31となり、理論的には30桁の9まで区別できるはずだ。しかし問題文では9が16個はOKで17個がNGという結果が出ているので、内部精度がbinary128の33桁程度に限定されていることが示唆される。
ただし、実際には16個の9までしか区別できないという制限があるため、計算機が約20桁程度の10進精度を持つ何かを使用しているのかもしれない。
重要な手がかりは「16個の9の次の数字は1でなければならず、2ではダメ」という条件と、「境界値が1023.99999999999999991991433…」という具体的な値だ。この「1991433…」の部分が計算精度の鍵を握っている。もし計算機が2^xをexp(x × ln(2))で計算しているなら、x × ln(2)の精度が問題になってくる。
x × ln(2)がln(DBL_MAX)と比較される際、その値がおよそ709.7827128933839…となり、これはln(DBL_MAX) = 1024 × ln(2) - ln(2)/2^52という式で表現できる。xの境界値はlog2(DBL_MAX)に相当し、1024から微小な補正値を引いた値になる。
次に、この補正項の計算を詳しく見ていると、2^52と2^53の違いによって係数が変わることに気づいている。前の計算では「1024 - 1/(ln(2) × 2^53) ≈ 1024 - 1.6 × 10^-16」という結果が出ていたが、今の計算では異なる値が出ている。DBL_MAXの正確な表現を使ってlog2を計算し直そうとしている。 So that confirms the calculation is correct. Let me verify the boundary values by checking where the precision threshold actually falls—with 16 nines I get a difference around 10^-16, and with 17 nines it drops to 10^-17, which means the actual boundary sits right around 1023.9999999999999998.
Now I’m realizing that 16 nines puts us closer to 1024 than 15 nines does, so the larger value should overflow more easily since it represents a bigger power of 2.
But the problem states that 16 nines is actually fine while 17 nines causes overflow, which means I might have the boundary conditions backwards—let me reconsider what “safe” versus “overflow” means in this context. 9が17個の方がより大きい値で1024に近いから、2^(9が17個) > 2^(9が16個)となる。つまり境界は1023.9999999999999999と1023.99999999999999999の間にあって、これは1024 - 10^-16のあたりだ。
実際に計算してみると、1024 - log2(DBL_MAX) ≈ 1.602 × 10^-16で、これはちょうど10^-17と10^-16の間に収まる。だからpure doubleの境界値は確かに9が16個と9が17個の間に位置していることが確認できた。 So the boundary value is actually smaller than the “sixteen 9s” case, which means 2^(sixteen 9s) should exceed DBL_MAX and overflow—but the problem states it shouldn’t. There’s a contradiction here that I need to resolve by reconsidering what the actual boundary is. Ah, I see the issue now—if the string converts to exactly 1024.0 in double precision, then pow(2.0, 1024.0) would overflow to infinity. So the calculator must be computing this internally using higher precision arithmetic, likely Decimal or similar, which can represent 2^(1023.9999999999999999) ≈ 3.59×10^308 without exceeding its maximum value.
But then I’m confused why 2^(1023.99999999999999999) would fail to display if both values are essentially the same magnitude—there must be something about how the calculator’s internal precision or rounding is handling these nearly identical exponents differently. Maybe I need to reconsider what the problem is actually asking. もし計算機がdoubleに変換して計算していれば、9の個数に関わらず全て1024.0になってオーバーフローするはずだが、問題文では9が16個の場合はOKとされているので、単純な変換ではなく高精度で2^xを計算しているようだ。その場合、2^(1023.9999999999999999)は約3.6×10^308という値になり、計算機の内部表現で表現可能だからOKと判定されるのだろう。
では9が17個の場合もほぼ同じ値のはずなのに、なぜNGになるのか。計算機が2^xを計算する際に、xを整数部と小数部に分けて、2^整数部 × 2^小数部という方法で計算しているのではないか。9が16個の場合は小数部が0.9999999999999999で、9が17個の場合はさらに小さくなるため、この分割方法で異なる結果が生じる可能性がある。
小数部0.9999999999999999をdoubleに変換するとどうなるか確認してみると、これは1 - 10^-16に相当する。doubleで表現できる1の直前の値は1 - 2^(-52)で、10^-16 < 2^(-52)なので、0.9999999999999999は1.0と1 - 2^(-52)の間に存在する値として表現される。 1 - 10^-16 と 1 - 2^(-52) を比較すると、10^-16 ≈ 1.0 × 10^-16 で 2^(-52) ≈ 2.22 × 10^-16 なので、1-10^-16 > 1-2^(-52) になる。一方 1-2^(-53) ≈ 1 - 1.11×10^-16 は 1-10^-16 より小さい。
doubleで表現できる1.0の近傍の値を見ると、ULPが0.5から1.0の範囲では2^(-53)、1.0から2.0の範囲では2^(-52)なので、1.0直前のdoubleは1 - 2^(-52)で、その前は1 - 3×2^(-53)になる。0.9999999999999999がどう表現されるか確認している。 1 - 10^-16 は [0.5, 1.0) の範囲にあり、このレンジでのULPは 2^(-53) ≈ 1.11×10^-16。10^-16 < 2^(-53) なので、1 - 10^-16 > 1 - 2^(-53) となり、1 - 10^-16 は [1-2^(-53), 1) の範囲に落ちる。この範囲の最大のdoubleは 1 - 2^(-53) で、その次は 1.0。
ここで気づいたのは、float(“0.9999999999999999”) が 1.0 に丸められる可能性が高いということ。もしそうなら、2^0.9999999999999999 は 2^1.0 = 2.0 になり、2^1023 × 2.0 = 2^1024 でオーバーフローする。でもこれだと「9が16個はOK」という観察と矛盾するから、何か見落としているのかもしれない。
実際に検証するために、Pythonで float(“0.9999999999999999”) と pow(2, float(“0.9999999999999999”)) を計算して確認する必要がある。また、iPhoneの計算機が内部でpow関数を使う際に、入力値に対して何か特別な処理をしているのではないかという可能性も考えられる。
例えば、xがlog2(DBL_MAX)未満かどうかを高精度で比較する場合、その比較の精度が結果に大きく影響する可能性がある。
もしかして計算機が内部的に128ビットのDecimalで2^xを計算していて、その内部表現の最大値がdoubleの最大値と異なるのではないか。Decimal128の最大値は10^6144程度で、2^1023.9999…は10^308程度なので、内部表現ではオーバーフローしないはずだ。
でも計算機は2^1024でオーバーフローすると言っているから、閾値はもっと小さい。doubleの最大値（約1.7977×10^308）でオーバーフロー判定しているのかもしれない。2^1023.9999…の正確な値を高精度で計算して確認する必要がある。
2^1023と2^0.9999…に分けて、Taylor展開を使って近似値を求めると、結果は約1.7977×10^308の2倍に近くなる。
つまり、doubleの最大値を超えてしまう。
でも計算機は「9が16個」という条件でオーバーフロー判定をしていないようだ。
問題文をもう一度確認すると、2^1023は表示されるのに2^1024ではオーバーフローになるということ。2^1023は約8.99×10^307で表示可能だが、2^1024はその2倍になるから、ここで初めてオーバーフロー判定が発動するんだ。
実際に計算してみると、2^1024 ≈ 1.797693×10^308で、これはdoubleの最大値DBL_MAXとほぼ同じ値。つまり2^1024がちょうどdoubleの上限に達するから、ここでオーバーフロー判定が働くということか。 So 2^1024 is slightly larger than DBL_MAX (about 1.1 × 10^-16 relative difference), which means it overflows to infinity in double precision. That confirms 2^1023 stays within range at roughly half of DBL_MAX, while 2^1024 exceeds it. Now for the interesting case of 2^(1023.9999999999999999)—if the system is using double internally, that exponent would round up to 1024.0 during conversion.
But wait, the result is marked as OK, which means either the conversion isn’t happening or the rounded value isn’t actually 1024.0. I verified earlier that sixteen 9s does convert to 1024.0 in double. This is genuinely contradictory. I think what’s happening is the calculator is checking whether the exponent exceeds log2(DBL_MAX) with high precision—approximately 1023.9999999999999998398—and since 1023.9999999999999999 is greater than that threshold, it’s flagging it as overflow.
Yet it’s still marked OK, which contradicts this theory. The only consistent explanation I can think of is that “OK” means the result can be displayed (even in exponential notation), and the calculator’s internal representation supports values up to around 10^309, so 2^(1023.9999999999999999) ≈ 3.6×10^308 fits within that range.
But then 2^(1023.99999999999999999) with one more 9 should also fit, yet it’s marked NG instead. I’m calculating the actual values to see where the boundary really is—with 16 nines I get approximately 3.59538×10^308, and with 17 nines it’s nearly identical, so I can’t understand why one passes and the other fails.
I need to step back and recalculate 2^(1023.9999999999999999) more carefully, starting with the exact value of x when there are 16 nines. 計算機がオーバーフローを報告していないのは、内部でdoubleより高精度の数値型を使っているからかもしれない。Decimal128なら最大値が10^6144程度あるので、10^308程度ではまだ余裕がある。では計算機は実際にどの精度で計算しているのか、そして2^1024でオーバーフローが起きるのはいつなのか確認する必要がある。
考えられる理由としては、計算機が内部的にはdoubleを使っているか、あるいは高精度で計算しながらもdoubleの最大値を超えたらオーバーフロー判定するか、もしくは指数が309以上になったら判定するか、のいずれかだろう。
2^1024 ≈ 1.798×10^308はdoubleの最大値1.7977×10^308より大きいので、Bの説が最も合理的に見える。ただし「2^(1023.9999999999999999)はOK」という結果と矛盾が生じているので、もっと詳しく検証する必要がある。
iPhoneの計算機が内部的にexp(y × ln(x))という方法でべき乗を計算している可能性を考えている。この場合、2^1024はexp(1024 × ln2)として計算され、doubleのexp関数がオーバーフローしてINFを返すことで説明がつくかもしれない。
ただし、「2^(1023.9999999999999999)」が「OK」と表示されるのは謎で、もしかして計算機が入力をdoubleに変換せず、Decimalのような高精度表現で保持して、高精度版のpow関数を使っているのではないかと考えている。
その場合、結果が3.59×10^308のような値になっても、doubleに変換する前に表示しているから「OK」なのかもしれない。
つまり、オーバーフロー判定は内部の高精度値に対して行われ、doubleの範囲を超えていても、計算機は10進数表示で結果を返すことができるということだ。
9が17個の値は実際には閾値を超えているが、doubleの精度限界により3.5954×10^308と同じに見えるだけなのか。
もしくは、計算機の「2^」演算子が単なる指数計算ではなく、別の処理をしているのではないか。
問題文をもう一度確認すると、2^1023は表示されるが2^1024でオーバーフローになるということは、doubleの最大値が2^1024の直前にあるということを示唆している。つまり2^1024 = 2 × 2^1023で、これがdoubleの範囲を超えるということだ。
計算してみると、2^1024 ≈ 1.7976×10^308で、これはdoubleの最大値DBL_MAX ≈ 1.7976931348623157×10^308とほぼ同じ値。実際には2^1024はDBL_MAXより大きいため、doubleではINFになってしまう。つまり、1.7977×10^308という値がdoubleの表現可能な上限の境界線なんだ。
ここから、2^xがDBL_MAXを超える条件を数学的に導き出そうとしている。DBL_MAXを(2-2^(-52)) × 2^1023として表現し、その自然対数を計算することで、xの閾値を正確に求めようとしている。
計算結果として、オーバーフローが発生する境界はおよそ1023.9999999999999998398であり、これは浮動小数点数で表現できる「9が16個」の値よりもわずかに小さいことに気づいている。
しかし問題の条件では「9が16個はOK」と述べられているため、この矛盾を解き明かそうとしている。高精度で保持された値がdouble精度に変換される際の丸め処理、あるいは計算機内部でべき乗計算がどのように実行されるかによって、結果が変わる可能性を検討している。
特に、べき乗計算を整数部分と小数部分に分割して処理する方法を考えている。x = 1023.9999999999999999の場合、整数部分1023と小数部分0.9999999999999999を分けて計算すれば、2^1023は有限のdouble値として表現でき、2^0.9999999999999999も計算可能になるという仮説を検証している。 0.9999999999999999 は 10^-16 だけ1より小さいけど、doubleの精度では1と2^-53の間に値が存在しないから、この数値は1.0に丸められてしまう。
だから2^1.0 = 2になり、2^1023 × 2 = 2^1024でオーバーフローするはずなのに、なぜか「OK」と判定されているのが矛盾している。
実際にfloat(“0.9999999999999999”)がどの値に丸められるのか確認してみれば、この謎が解けるかもしれない。


重要な発見！
float('0.9999999999999999') = 0.9999999999999999 (≠ 1.0!)
これは私の予測と違った。bits=3fefffffffffffff これは：
	•	符号: 0
	•	指数部: 3ff (1022, biasで-1)
	•	仮数部: fffffffffffff (2^52-1)
これは 1 - 2^(-52) = 0.9999999999999997779… ではなく…
実際には指数部を正しく計算すると、3feは1022ではなく-1を意味していて、仮数部の2^52-1と合わせると1 - 2^(-53)になる。つまり約1 - 1.11×10^(-16)という値だ。
Pythonが0.9999999999999999と表示しているのは、この値を最短で一意に表現できる文字列がそれだからで、実際の内部値は1 - 2^(-53)のままだ。
だから”0.9999999999999999”を文字列からfloatに変換しても1 - 2^(-53)になるし、“1023.9999999999999999”全体を変換すると1024.0に丸まってしまう。つまり、分離した小数部分は正確に保たれるが、整数部分を含めて変換すると丸め誤差が生じるということだ。
Bの方法で計算すると、2^1023に2^(1-2^(-53))を掛けることで、結果は2^1024より小さい値になり、オーバーフローを避けられる。
実際に数値を計算してみると、2^1024から微小な値を引いた形になるので、これがL_MAXの候補になるかもしれない。
ただし、doubleの最大値を超えてしまう可能性があるから、整数部が1023の場合に2^1023と小数部の積がどうなるか確認する必要がある。
2^1024 - 2^(-53)という指数を計算してみると、これはlog2(DBL_MAX)より大きくなってしまい、オーバーフローが発生する。
ただし、実際のコードでは9が13個の場合は小数部分が0.9999999999998863となって正常に動作するのに対し、9が14個になると小数部分が0になってしまい、エラーが出ているようだ。
math.ldexp(1.0, 1024)の計算でオーバーフローが発生しているのが原因で、これは浮動小数点数が1024.0に丸まってしまったことが根本的な問題のようだ。
13個の9ではうまくいくが14個になるとこのオーバーフローが起きる。ただし、問題文では16個と17個の境界を示唆しているので、計算機が異なる精度で処理している可能性がある。
もしかして小数部分を高精度（Decimalなど）で保持しながら、べき乗計算はdouble精度で実行しているのかもしれない。その場合、16個の9は正確に表現でき、float変換後も1 - 2^(-53)に近い値となり、2^1023との積を計算することになる。
DBL_MAXの範囲内に収まるかどうかを確認する必要がある。
2^1024に近い値と、DBL_MAXの上限である2^1023 × (2 - 2^(-52))を比較すると、指数部分の微妙な差が結果を左右する。2^(-2^(-53))は約1 - 7.70×10^-17で、(1 - 2^(-53))の約1 - 1.11×10^-16より大きいため、計算結果がDBL_MAXを超える可能性がある。 So I’m comparing the magnitudes more carefully—since 2^(-53) × ln2 is actually smaller than 2^(-53), that means 2^(1024 - 2^(-53)) ends up being greater than DBL_MAX, which should cause an overflow. But then there’s something about 9 appearing 16 times that seems to contradict this…
Let me think through what happens when I convert the decimal “0.9999999999999999” (with 16 nines) to a double versus what the actual mathematical value represents. The key difference is that 10^(-16) is slightly smaller than 2^(-53), so 1 - 10^(-16) is actually larger than 1 - 2^(-53) in double precision.
Since 1 - 2^(-53) is the largest representable double less than 1.0, and 1 - 10^(-16) falls between that and 1.0, the string “0.9999999999999999” will round up to 1.0 when converted to a double. 1 - 2^(-54)
1 - 10^-16 と 1 - 2^(-54) を比較すると、2^(-54) ≈ 5.55×10^-17 で 10^-16 = 1.00×10^-16 より小さいから、1 - 10^-16 は中点より下にある。だから最も近いdoubleへの丸め(round-to-nearest-even)では 1 - 2^(-53) に丸まる。つまり float(“0.9999999999999999”) の実際の値は 1 - 2^(-53) ≈ 0.9999999999999998889。
Pythonが “0.9999999999999999” と表示するのは repr の表示だけで、内部的には 1 - 2^(-53) として保存されている。ビット表現を確認すると、符号は0、指数部は-1、仮数部は 2^52 - 1 で、これが (2 - 2^(-52)) / 2 という値に対応している。
pow(2, 1 - 2^(-53)) を計算すると、これは 2 × 2^(-2^(-53)) となり、2^(-2^(-53)) はほぼ 1 - 2^(-53) × ln(2) に近い値になるから、結果は約 2 - 2^(-52) になる。
Python の repr で見ると 1.9999999999999998 となるのは 2 - 2×10^(-16) に相当するので、double 精度では 2 未満の最大値がどの値なのかを確認する必要がある。
ULP（Unit in the Last Place）を計算すると、2 の指数が 1 なので ULP は 2^(-51) ≈ 4.44×10^(-16) となり、2 の直前の値は 2 - 2^(-51) のはずだが、実際の計算結果 7.70×10^(-17) はこれより小さいため、pow(2, 1-2^(-53)) の結果は 2 に非常に近い値になる。
次に、[1, 2) の範囲では ULP が 2^(-52) ≈ 2.22×10^(-16) に変わり、pow(2.0, 0.9999999999999999) = 1.9999999999999998 という結果から、この値は 2 に丸まっていないことがわかる。実際の値 1.99999999999999985… と 2 との差は約 1.54×10^(-16) で、これは ULP の 0.694 倍に相当するため、丸め規則によってどちらに丸まるかが決まる。
1.54×10^(-16) は ULP/2 ≈ 1.11×10^(-16) より大きいので、2 - ULP = 2 - 2^(-52) に丸まることになる。
pow(2, 1-2^(-53)) は double では約 1.9999999999999998 として表現される。これを 2^1023 でスケーリングすると DBL_MAX に到達する。
つまり、この計算は浮動小数点数の精度限界を巧妙に利用して、オーバーフローを回避しながら最大値に達しているんだ。
9が17個になると、丸め誤差によって小数部分が1.0に丸められてしまい、結果が変わってくる。
つまり、pow(2.0, 1.0) = 2.0となって、ldexpで2^1024を計算しようとするからオーバーフローが発生する。次に、16個の9の後に1が続く場合を確認してみる。
小数部が0.99999999999999991になると、これは1 - 9×10^-18で表現できるが、この値は丸め誤差の中点より大きいため1.0に丸まってしまう。でも「1はOK、2はダメ」という結果が出ているなら、計算機が整数部と小数部を分けずに高精度で扱っているのかもしれない。
もしかして計算機は入力を高精度な10進数のまま保持して、2^xも高精度で計算しているのではないか。「9が16個までOK」というのは、計算機の表示精度や内部の桁数制限であって、べき乗計算そのものの限界ではないのかもしれない。ただそれだと「17個でオーバーフロー表示」という現象が説明できない。
別の可能性として、計算機が入力を文字列として受け取り、それをdoubleに変換してからpow関数を呼んでいるのかもしれない。その場合、文字列の”1023.9999999999999999”（9が16個）がfloatに変換される時点で何が起こるのかを確認する必要がある。
もう一つの実装パターンとしては、整数部と小数部を分けて処理する方法が考えられる。整数部は文字列から直接取得し、小数部は”9999999999999999”という文字列をdoubleに変換して、その後べき乗計算を行い、最終的にldexpで結合するというアプローチだ。
9が16個の場合はこれで正しく動作するが、17個になるとdoubleの精度限界で1.0に丸められてしまい、結果として2^1024になってオーバーフローする。9の後に1が続く場合の挙動も精度の問題で説明がつく。 ので 1 - 9×10^-18 > 1 - 2^(-54) (中点)
最も近いdoubleへの丸め: 1.0 → NG
でも「1はOK」と言っているので、この実装でも説明がつかない?
うーん、もし計算機の入力精度が固定（例えば小数点以下16桁まで）で、17桁目は切り捨てられるなら：
「9が16個の次に1」= 小数部16桁 = “9999999999999999” (切り捨て後)
→ float(“0.9999999999999999”) = 1 - 2^(-53) → OK
「9が16個の次に2」= 小数部16桁 = “9999999999999999” (切り捨て後)
→ 同じ → OK
これでは「1はOK、2はNG」の説明にならない。
もしかして計算機は16桁を超えた場合にオーバーフローを返す実装なのか、それとも17桁以上の小数も受け付けているのか。問題文から見ると17桁目の数字に意味があるようだから、計算機は17桁以上の入力を処理しているはずだ。この複雑な観察全体を説明するには、計算機の精度処理がもっと微妙な仕組みになっているのかもしれない。 算機の内部精度を正確に把握する必要がある。
最終的な仮説：計算機はBinary128（quad precision）を使っている
Binary128（IEEE 754-2008）：
	•	仮数部: 112ビット + 暗黙ビット = 113ビット有効ビット
	•	指数部: 15ビット
	•	精度: 約33.36桁の10進数
1024付近のULP: 2^(10-112) = 2^(-102) ≈ 2×10^-31
この精度なら、「9が30個程度」まで区別できるはず。
でも「9が17個でNG」なので、binary128だとしても「17個より多く」区別できるはず。
計算機の「9が16個はOK、17個はNG」という制限は、べき乗計算の精度ではなく、入力受付桁数や表示精度といった別の要因による可能性が高い。もしかして計算機は文字列として入力を保持しながら、pow(2, x)を計算する際に整数部と小数部を分割して処理しているのではないか。小数部をfloatに変換する方法によって、精度の限界が決まるかもしれない。 I need to verify whether the float conversion creates a boundary between “1” and “2” in the decimal representation—specifically checking if “0.99999999999999991” converts to 1 - 2^(-53) while “0.99999999999999992” rounds up to 1.0, which would explain why the first case passes but the second fails. Now I’m testing what happens when I convert these decimal strings to floating-point values—specifically checking whether “0.99999999999999991” rounds to the machine epsilon boundary, and then verifying the theoretical maximum value by multiplying the fractional part by 2^1023. I’m checking where 0.99999999999999991 falls in the floating-point representation—it’s less than the midpoint between 1 - 2^(-53) and 1.0, so it should round down to 1 - 2^(-53) rather than up to 1.0. 1 - 2^(-53) に丸まる。次に 0.99999999999999994 を見ると、これはちょうど中点で 1 - 2^(-54) に等しい。round-to-nearest-even ルールでは、中点の場合は仮数部の最後のビットが偶数になるように丸めるので、1.0 に丸まるはずだが、実際の仮数部の構造を確認する必要がある。
仮数部を見ると、1 - 2^(-53) は最後のビットが 1（奇数）で、1.0 は最後のビットが 0（偶数）なので、中点なら偶数の 1.0 に丸まる。では 0.99999999999999995 はどうか。これは 1 - 5×10^-18 で、中点の 1 - 2^(-54) ≈ 1 - 5.55×10^-17 より大きいので、1.0 に丸まるはずだ。 0.99999999999999994 は実際には 1 - 6×10^-18 で、これは中点の 1 - 2^(-54) ≈ 1 - 5.55×10^-17 より大きいから、1.0 に丸まるはずだ。
でも計算を確認してみると、6×10^-18 と 55.5×10^-18 を比較すると矛盾が出てくる—もう一度正確に計算し直す必要がある。
中点 1 - 2^(-54) ≈ 0.999…9944489… より小さい値は 1 - 2^(-53) に丸まり、中点を超える場合（つまり x < 2^(-54) のとき）に 1.0 に丸まるということが分かってきた。
10進数で見ると、9が16個続いた後に4が来れば中点より小さく 1 - 2^(-53) に丸まり、5が来れば中点を超えて 1.0 に丸まる。
でも実際の動作は「16個の9の次が1でOK、2でNG」という全く異なるパターンになっている。もしかして計算機は小数部だけを変換するのではなく、入力文字列全体をdoubleに変換しているのかもしれない。
その場合、1023.9999…がどのdoubleに丸められるかを確認する必要があるけど、既に1023.9999999999999999は1024.0に丸まることを確認している。なのに「9が16個まではOK」という結果と矛盾している。もう一度考え直すと、「16個の9の次が1」というのは、1023.9999999999999999の後に1が続く数字を指しているのかもしれない。
つまり、小数点以下16桁で四捨五入する場合、17桁目が1～4なら16個の9のままで、5以上なら1.0に丸まるということか。
でも問題文は「1はOK、2はNG」と言っているから、四捨五入ではないんだ。
実際の計算機の動作を確認するために、Pythonで複数の仮説をシミュレートして、「9が16個はOK、17個はNG、16個の次が1はOK、2はNG」という条件を満たすパターンを探してみよう。
Testing hypothesis A…
仮説Aでは小数部をdoubleに変換してからldexpを使うと、“0.9999999999999999”は1-2^(-53)に丸まって2^1023 × (2-2^(-52))がDBL_MAXになるからOKなんだけど、“0.99999999999999991”と”0.99999999999999992”も同じく1-2^(-53)に丸まってしまうから、これだと2もOKになってしまう。矛盾している。
仮説Bで全体をdoubleに変換すると、“1023.9999999999999999”は1024.0に丸まってオーバーフローするから、「9が16個はOK」という条件に矛盾する。
仮説Cを試してみる必要がある。
計算機がDecimalで高精度にxを保持して、pow(2, x)をDecimalで計算するなら、2^(1023.9999999999999999) = 2^1024 × 2^(-10^-16)となり、2^1024だけで既にDBL_MAXの2倍近くになるからNG判定になる。これも矛盾している。
どの仮説も矛盾が生じるから、根本的に別のアプローチを考え直す必要がある。
iPhoneの実際の動作を観察から逆算してみると、2^1023はOKで2^1024はオーバーフロー、そして2^(9が16個)はOKで2^(9が17個)はオーバーフロー。この観察から、オーバーフロー判定の閾値は2^1024と2^(9が16個)の間のどこかにあるはずだ。
DBL_MAXという特別な値が関係していそうで、それは(2-2^(-52)) × 2^1023という形で表現される。これを2^1024で書き直すと2^1024 × (1-2^(-53))になる。この値と観察されたオーバーフロー境界を比較することで、iPhoneの浮動小数点数の上限がどこに設定されているのかが見えてくるはずだ。 So the calculator must be using a high-precision decimal library internally to display these large numbers, independent of double’s limitations. That means I need to figure out where the actual overflow threshold is—testing progressively larger exponents to find the breaking point. Maybe the overflow threshold is determined by checking whether the exponent (x × log₁₀(2)) reaches 309 or higher, and if the system is using 16-digit decimal precision for both x and log₁₀(2), the product would be around 308.254, which explains why values just below this threshold pass while those crossing it fail. 計算機がオーバーフロー判定する際に、x × ln(2) が ln(DBL_MAX) ≈ 709.78 を超えるかどうかで判断しているのかもしれない。x = 1023.9999999999999999 のとき、この値は16桁の Decimal で丸められて1024になり、x × ln(2) を計算すると約709を超える可能性がある。ただし、1023.9999999999999999 は実際には20桁の有効数字を持っているので、丸め方によって結果が変わる。
計算機が16桁の有効数字 Decimal を使っているなら小数部は12桁までしか保持できず、20桁なら16桁まで保持できるはずだ。
実際に x = 1023.9999999999999999 と ln(2) = 0.6931471805599453 を掛け合わせると、20桁精度では約709.7827128933839になるが、正確な値は709.782712893384627で、その差は10の-17乗程度の誤差になる。
計算機の値709.78271289338456とln(DBL_MAX)の709.78271289338396を比較するとオーバーフローが起きるはずなのに、「9が16個はOK」という説明と矛盾している。もう一度正確に計算し直す必要があり、ln(DBL_MAX) = ln((2-2^(-52)) × 2^1023) の形で再検討している。
ln(DBL_MAX)を展開すると1024 × ln(2) + ln(1-2^(-53))となり、これは約1024 × ln(2) - 2^(-53)に近似される。一方、xの値は(1024 - 10^-16) × ln(2)で表現でき、これを展開すると1024 × ln(2) - 6.93×10^-17となる。
x × ln(2)とln(DBL_MAX)の差を計算すると4.17×10^-17となり、x × ln(2) > ln(DBL_MAX)が成り立つため、2^xはDBL_MAXを超えてオーバーフローするはずなのに、問題文では9が16個の場合は大丈夫だと述べられている。この矛盾から、問題文の解釈を見直す必要があるのではないかと考えている。
もしかして、これは数学的なオーバーフロー判定ではなく、実際にiPhone標準の計算機アプリで2^xを入力したときの動作を指しているのかもしれない。
2^1023は指数表示で表示されるけど答えが出るのに対して、2^1024はオーバーフローして計算できないということなのか、それとも計算機が値を計算する過程でオーバーフローするのか、それとも単に入力を見て判定するのか、その辺りの仕組みが曖昧だ。
通常は計算を実行してから初めてオーバーフロー判定が起こるはずだ。
では、これまでの観察をすべて整理し直してみよう。2^1023は正常に計算できて、2^1024はオーバーフローする。さらに細かく見ると、2^(1023.9999999999999999)は成功するが、2^(1023.99999999999999999)はオーバーフローする。その間の値がどこで境界線を引いているのか、その閾値を特定する必要がある。
実際に計算してみると、2^(1024 - 10^-16)がDBL_MAXを超えるかどうかが鍵になる。DBL_MAXは2^1024 × (1 - 2^(-53))で表されるから、指数部分の微妙な差がオーバーフロー判定に影響を与えているはずだ。 So the calculator is accepting it as valid, which means the actual overflow threshold isn’t DBL_MAX itself. I need to find the precise boundary where 2^x transitions from acceptable to overflow — it seems to happen somewhere between the 16-nines and 17-nines cases, though the values are nearly identical at that scale.
Looking at the additional constraints from facts 5 and 6, I’m narrowing down exactly where that threshold lies by testing what comes after the string of nines. Now I’m working through the mathematical relationship between the boundary value and the actual overflow threshold in double precision, calculating that the critical point is approximately 2^1024 times a factor very close to 1, which translates to roughly 3.5954 × 10^308 in decimal form. 10^308 × 5.55×10^-20
= 3.5954 × 10^308 - 1.995 × 10^289
つまり閾値 = 3.5954 × 10^308 - 2.0 × 10^289
これは… 何のきれいな数字にも見えない。
整理：計算機の内部表現でどのような「最大値」があるか
もしかして計算機の内部は 10 進数の 19-20 桁精度で、計算結果を 10^(308.25532…) までしか表示できない（その次の 10^(308.255…) 以上でオーバーフロー）という実装ではないか?
log10(2) の値を使って、2^1024 がおよそ 10^308.255 になることを確認している。つまり、浮動小数点数の最大指数が 1024 に設定されていて、それが 10 進法では約 308.25 に相当するということか。
So the threshold isn’t based on a simple exponent check—it’s tied to the calculator’s internal precision limits with decimal numbers. I’m realizing the iPhone calculator might be using its own high-precision decimal arithmetic with a maximum value around 10^308.25, which corresponds to 2^1024 in binary floating-point terms.
Now I’m wondering if this has to do with how the calculator computes 2^x—perhaps it’s converting to base 10 using logarithms and running into precision constraints when handling the intermediate calculations with limited decimal precision. 閾値がlog10(DBL_MAX)の場合、「9が16個」は実際にはオーバーフローするはずなのに、計算結果では「OK」と判定されている。この矛盾から考えると、計算機がlog2(DBL_MAX)を不正確に近似している可能性があるのではないか。
例えば、何らかの丸め処理や固定精度での閾値判定を使っているのかもしれない。ただ、実装の詳細を知らないので、これ以上の推測は難しい。
ただし、実験で得られた境界値 x ≈ 1023.99999999999999991991433… を詳しく分析すれば、内部実装の手がかりが見つかるかもしれない。1024 との差分 8.008567 × 10^-20 が、2^(-64) や 2^(-63) といった浮動小数点の基本単位とどう関係しているのかを調べてみる価値がある。
この差分の対数を取ると約 -63.437 という値が出てくるのだが、これは 64ビット整数仮数や 53ビット仮数の double 精度との関連性を示唆しているのかもしれない。もしかして計算機は内部で 64ビット整数仮数を使った高精度演算を行っているのではないか。 64ビット整数で 2^x の計算をする場合、精度は 64 ビット（2^(-63) ≈ 1.08×10^-19のオーダー）。
で、「8.008567 × 10^-20」は 2^(-63.4) 程度…
あ、もしかして計算機が 2^x を計算する際に、小数部分を 64 ビット固定小数点として保持しているのか。x = 1023.9999999999999999 の場合、小数部分 0.9999999999999999 を 2^63 倍してスケーリングすると、丸め誤差が発生して 9223372035932438604 になる。そこから 2^f を計算するときに、この誤差が 2^0.9 の精度に影響を与えているんだろう。
実際に計算機の実装を特定するために、この 1023.99999999999999991991433… という境界値を詳しく分析して、小数部分を double に変換してから pow(2, double) を計算する実装なのか確認する必要がある。
Pythonで数値実験を行って、9×13 と 9×14 の場合の違いを調べ、“0.9999999999999999” という16桁の9がどのように float に変換されるかを検証しよう。
前の実験では exp(2-2^(-52), 1023) が DBL_MAX になることを確認したが、17桁の9の場合は 1.0 に丸まるのか、それとも別の値になるのかを実際に計算して確認する必要がある。中点 1 - 2^(-54) との大小関係から、10^-17 < 2^(-54) なので 1 - 10^-17 > 1 - 2^(-54) となり、丸め方向が変わる可能性がある。
実際に計算してみると、17桁の9は 1.0 に丸まってしまい、その結果 pow(2, 1.0) = 2 となって ldexp(2, 1023) = 2^1024 という範囲外の値になってしまう。これで謎が解けた—16桁の9は DBL_MAX で成功するが、17桁の9は 2^1024 でオーバーフローする。さらに16桁の9の次の値を調べると、9×10^-18 < 2^(-54) なので中点より大きく、やはり 1.0 に丸まってしまう。
ただ、生徒が観察した「1023.99999999999991991433…」という正確な境界値は、計算機の表示から読み取ったものだから、その末尾の「1991433」という数字は計算機が内部で高精度のまま処理した結果が丸められて表示されたのかもしれない。
つまり、iOSの計算機アプリはAppleの独自高精度ライブラリを使っていて、入力を約20桁の10進数で保持し、2^xの計算も高精度で行っているのではないか。その場合、オーバーフロー時の境界値はdoubleの最大値よりも大きい内部最大値によって決まる特定の値になるはずだ。
ここで「1991433」という数字の由来を理論的に追跡してみると、log2の計算精度に関連している可能性がある。2^fを計算する際に、f = 0.99999999999999991991433…という値に対して、テイラー展開を使うと2^fの値がどのように計算されるかが見えてくる。
その結果、2^1024に非常に近い値が得られるが、完全には到達しない。
計算機がこの値を「ギリギリOK」と判定するのは、内部の閾値（2^1024 - α）以下であるかどうかで決まる。ここでαは2^1023に微小な係数を掛けた値で、これが約10^288のオーダーになることから、浮動小数点数の精度限界と関連していることがわかる。
実際の境界がどこにあるかはPythonで直接計算して確認する必要があるが、小数部を文字列として変換する際に、1 - 2^(-53)と1.0の丸め境界となる中点（約0.999999999999999944…）を基準に、それより小さいか大きいかで結果が分かれる。
つまり、元の数値1023.999999999999999944…において、小数部の9が16個続いた後の17番目の桁が1なら中点未満でOK、2なら中点を超えてNGという観察と一致するはずだ。
でも実際には「2はNG」なので、真の境界値は「9が16個の次が1」と「9が16個の次が2」の間のどこかにあって、それが1023.99999999999999991991433…だということか。
この「1.991433…」という部分が何から来ているのか気になるけど、ln(2)やlog10(2)といった基本定数との直接的な関係は見つからない。もしかして浮動小数点演算の精度限界から生じた値なのかもしれないから、これ以上の理論的な追求よりも実際の数値計算で確認する方が確実だろう。
Pythonで浮動小数点の丸め動作を直接検証して、「1991433」という数字がどこから現れるのか、そして中点の値「1 - 2^(-54)」がどう関係しているのかを調べてみよう。
0.99999999999999991と0.99999999999999992の両方が中点より小さいため、どちらも1-2^(-53)に丸まることを確認している。


素晴らしい！重要な発見がいくつかある。
	1.	float("0.99999999999999991") = float("0.9999999999999999") = 0.9999999999999999 (= 1-2^(-53))
	•	9が16個の次が1, 2, 3, 4でも同じ値！
	2.	float("0.99999999999999995") = 1.0 ← 丸まる！
	3.	整数部1023+小数部を別々にdoubleで計算する仮説が「9が16個はOK、9が17個はNG」を完璧に説明している。
	4.	ただし、実際には「9×16+0〜4 = OK、9×16+5〜9 = NG」というパターンになっていて、問題文の「1はOK、2はNG」という条件と矛盾している。
計算で確認した境界値は 1023.9999999999999999444... だが、問題文では 1023.99999999999999991991433... と異なっており、この差異が「9が16個の次の数字」の判定基準の違いに直結している。
この不一致の原因を探ると、計算機が小数部を独立して変換するのではなく、全体を一つの計算で処理しているか、あるいは pow(2, x) の内部実装で exp(x × ln(2)) を使用していて、高精度の Decimal と ln(2) の値を保持しているのかもしれない。
境界値を計算すると x × ln(2) = ln(DBL_MAX) となり、x_boundary ≈ 1024 - 1.602 になるはずだが、実際の問題文の境界値 1023.99999999999999991991433… との差は 8.008567 × 10^-20 で、これは 1.602×10^-16 とは全く一致しない。この「1991433」という数字の謎を追うと、log2(8.008567 × 10^-20) ≈ -63.437 となり、80ビット拡張精度の x87 浮動小数点形式に関連している可能性がある。
計算機が内部的に 64 ビット整数や 10 進数 20 桁精度を使っているのか、あるいは別の精度体系で計算しているのか確認する必要がある。
問題の境界値をより詳しく分析してみると、1023.9999999999999999（9が16個）は 1024 - 10^-16 で表せるが、与えられた 1023.99999999999999991991433 との差は約 8.008567 × 10^-20 となり、これは 10^-16 の約 1249 倍小さい値だ。この比率を調べると 2^10 に近い値が出てくるが、対数を取ると -63.437 になり、これは 2^(-53) × 2^(-10) = 2^(-63) という関係を示唆しているものの、実際の値とは完全には一致していない。
生徒の主張する「境界は 2^(1024-2^(-53.4712336)) と 2^(1024-2^(-53.4712337)) の間」という表現を改めて解釈すると、境界値と 1024 の差を 2 の何乗で表現したときに -53.47… という指数が出てくるということのようだ。
つまり 1024 - x_boundary ≈ 2^(-53.4712336) ≈ 8.008 × 10^-17 となるはずなのだが、これは問題文に示された実際の差 8.008567 × 10^-20 と 3 桁も異なっている。生徒の数字で計算すると x_boundary ≈ 1023.99999999999999992… となり、9 が 16 個続く形になるが、私の理論値 1024 - 1.602 × 10^-16 = 1023.99999999999999983… とも一致していない。
ここで log2 スケールで比較してみると、理論的な double の限界では差が 2^(-52.47) 程度なのに対して、生徒が示した境界値では 2^(-53.47) 程度になっており、約 1 ビット分のズレが生じている。
この差は、計算機が double の理論的な精度より 1 ビット少ない精度で動作しているか、あるいは閾値の計算方法が異なっているのかもしれない。1023.99999999999999991991433… という具体的な境界値を見ると、1024 との差がこのズレを説明しているはずだ。
その差を計算してみると約 8.008567 × 10^-20 になり、log2 で変換すると -63.43 程度になる。これは生徒が観察した -53.47 とは全く異なる値だ。生徒の言う「境界は 2^(1024-2^(-53.4712336)) と… の間」というのは、x_boundary = 1024 - 2^(-53.4712336) という形で表現されているようだ。
この値を計算すると 1024 - 8.008 × 10^-17 ≈ 1023.99999999999999199… となる。9が16個並ぶ値 0.9999999999999999 は 1 - 10^-16 に相当し、つまり 1023.9999999999999999 になる。生徒の境界値は 1024 - 8×10^-17 で、これは 1024 - 10^-16 より大きいため、9が16個の値よりも大きい境界を示していることになる。
ただ、生徒が「境界」と言っているのは、その値を超えるとNGになる限界を指しているのかもしれない。1023.99999999999999992… = 1024 - 8×10^-18 として計算し直すと、log2(8×10^-18) = 3 - 59.8 = -56.8 となるが、これは生徒が示した -53.47 と一致しない。問題文の境界値の解釈がまったく合致していないので、別のアプローチを試す必要がある。
iPhoneの計算機がどのように動作しているかを直接シミュレートすることに切り替えよう。整数部と小数部を分けて計算する場合、9が16個連続するとfrac = 1-2^(-53)に丸まってOKになり、その次に5以上が来るとfrac = 1.0に丸まってNGになる。この場合の境界は約1024 - 5.55×10^-17となるはずだが、問題文では「1はOK、2はNG」で境界が1023.99999999999999991991433…と示されており、この差異がどこから生じているのかを確認する必要がある。
計算機は「整数部+小数部分割」以外の別の計算方法を使っているか、あるいは文字列から浮動小数点数への変換プロセスが私の想定と異なっているのかもしれない。NSDecimalNumberのdoubleValueメソッドを使う場合、“1023.9999999999999999”という文字列がどのように変換されるかを確認することで、計算機の実装の手がかりが得られるはずだ。
ただ、9が16個の場合がうまくいくという事実から考えると、計算機は単純な浮動小数点変換をしていないことは明らかだ。もしかして計算機は2^xを10^(x × log10(2))という形で計算し、内部で常に10進法の指数表現で数値を保持しているのではないか。その場合、x = 1023.9999999999999999をlog10(2) ≈ 0.301029995…で掛けると約308.25になり、この計算方法なら高精度を保ったまま結果を得られるかもしれない。
ただしオーバーフロー判定の閾値がどこに設定されているかで、結果が大きく変わってくる。もし閾値が2^1024なら、x × log10(2) > 308.25487…でアウトになるはずで、その場合xは1024未満でなければならない。でもそうするとすべての17個の9がOKになってしまい、実際の挙動と矛盾する。別の可能性として、閾値がDBL_MAX程度に設定されているなら、log10(DBL_MAX)との比較で判定されているのかもしれない。
その場合、9が15個まではセーフで16個目でアウトになるはずだが、これも「9が16個までOK」という観察と合わない。もしかして計算機は、double型の標準的な上限ではなく、別の独自の閾値を使っているのではないか。
9が16個と17個の境界を正確に説明できる閾値を探す必要がある。
計算機が高精度で値を保持しているなら、閾値は1024 - 10^-16と1024 - 10^-17の間にあるはずだが、DBL_MAXの対数値がこの範囲より小さいことから、実際の閾値はもっと大きい値のようだ。
さらに詳しく調べると、「9が16個の次」の境界から閾値は1024 - 10^-16に非常に近い形で、(1 + ε)×10^-16という係数を持つ値になっていて、εの正確な値を特定する必要がある。
問題文の境界値1023.99999999999999991991433…から計算すると、これは8.008567×10^-20のオーダーで、10^-16よりもずっと小さい値だ。つまり、x = 1023.99999999999999991…という具体的な値を入力したときの挙動を正確に追跡する必要があるということだ。 境界値の正確な計算を詰めているところだ。1024 - 2^(-53.4712336) がおよそ 1023.9999999999999999… になるはずなんだけど、指数部分の微妙な差がどう影響するのか確認している。
小数点以下16桁目までが9で、その後の桁がどうなるかが重要なポイントだ。
計算結果から、1023.99999999999999991992…という値が得られて、これが理論的な境界値と一致している。ただし、私が最初に計算した log2(DBL_MAX) の値とは微妙に異なるようだ。
実際の計算機での境界値と理論値の比率を見ると、ちょうど2倍の関係になっているのが興味深い。
もしかして、計算機が ln(2) の近似値を使う際に、その精度が正確な値の2倍精度で1ビット分余分に含まれているから、観測される境界が理論値の半分になっているのかもしれない。
あるいは log10(2) を半精度で計算しているのか。
実際に 2^(-53.4712336) ≈ 8×10^-17 という値が出ていて、これは 1024 - x_boundary のlog2から導かれている。理論的には 1024 - log2(DBL_MAX) は 1/(ln(2)×2^53) になるはずだが、観測値がその半分になっているのは、計算機の内部表現か近似値の使い方に関係しているようだ。 I’m wondering if the computer is using extra precision internally when calculating 2^x — perhaps it’s splitting x into integer and fractional parts and computing them separately, which could introduce rounding errors that combine in interesting ways. 際の境界が理論値と1ビット分ずれているのかもしれない。特に、pow(2.0, frac) が最大の誤差0.5 ULP を持つ場合、境界が 0.5 ULP ずれることはあり得る。でも0.5 ULP のずれが 1024-x のlog2に1の差を生むとは考えにくい…
計算機は整数部と小数部を分けて処理し、小数部をdoubleに変換してから exp2(frac) を計算しているという仮説が最も観察を説明できそうだ。この場合、小数部が1-2^(-53)に丸まると exp2 = 2-2^(-52) となって 2^1023 × (2-2^(-52)) = DBL_MAX になるけど、1.0に丸まると exp2 = 2.0 になって 2^1024 になってしまう。丸め境界は 1 - 2^(-54) = 0.999999999999999944489… で、つまり境界x は約 1023.99999999999999994449… になる。9が16個続いた後に4449…という形になるはずだ。 計算機が内部で異なる精度（例えば20桁のDecimal）を使って中間値を処理し、その後doubleに変換する際に、Pythonの float() とは異なる丸め方をしている可能性がある。つまり、「0.99999999999999991」と「0.99999999999999992」を区別して処理し、それぞれがdoubleに変換されるときに異なる結果になるのかもしれない。
ただ、実際の計算からすると両方とも 1 - 2^(-53) に丸まるはずなので、本当の問題は生徒が報告した「1023.99999999999999991991433…」という境界値が、実際に計算機が出力した値なのか、それとも生徒が入力した値なのかを確認する必要がある。
計算機のボタン入力には精度の限界があり、生徒が一つずつ数字を入力した場合、表示桁数や入力精度に制限がある可能性が高い。
実際の境界を確認するには、整数部と小数部を分けて計算し、小数部をdoubleに変換してから pow(2, frac) を計算する仮説を検証する必要がある。
私のシミュレーションでは「4はOK、5はNG」という結果が出ているが、問題文の「1はOK、2はNG」と一致していないため、生徒が実際のiPhoneの計算機で二分探索を使って特定した境界値と、私のシミュレーション結果の実装の違いを調査する必要がある。
境界値 x ≈ 1024 - 8.008567 × 10^-20 の差分を分析すると、これは64ビット仮数部の精度（2^(-63) ≈ 1.084 × 10^-19）に非常に近く、計算機が内部で64ビット整数を使って仮数を管理している可能性を示唆している。
80ビット拡張精度（long double）の場合、仮数部が64ビットで指数部が15ビットという構成になり、1近傍でのULPがちょうど2^(-63)程度になるため、この実装の候補として有力だ。
1.0の直前の値は1 - 2^(-63)で、丸め判定の中点は1 - 2^(-64)となり、正確な境界値は1024 - 2^(-64)になる。
ただし計算すると約5.42×10^-20になるのに対し、問題文では8.008567×10^-20とあって、この差分の比率が約1.477と整数比にならないのが気になる。2^(-63.437)がちょうど8.008×10^-20に相当するようだが、これは2^(-63) × 2^(-0.437)という形になっている。
2^(-0.437)を計算すると約0.739になり、1.084×10^-19 × 0.739でおよそ8.01×10^-20が得られるので、境界値は確かに2^(-63.437)付近だ。
では、この境界値を生成する精度は何か。64ビット整数で小数部を保存する場合、小数部を2^64倍してから丸めるので、精度は2^(-64)になるはずだが、その中点がどこになるかを確認する必要がある。
64ビットと63ビットの両方を試してみても、どちらも8×10^-20に一致しない。では逆に、8×10^-20という精度を生成するには何ビット必要か、log2を使って計算してみよう。
63.44ビットという結果が出たけど、これはきれいなビット数ではない。
別の角度から考えると、この境界値は分数部分の精度ではなく、pow計算自体の精度に関係しているのかもしれない。もし計算機がdouble精度のexp2を使っているなら、結果は0.5 ULPの誤差を持つ。exp2(frac)が2-2^(-52)から2に遷移する境界のfracは、log2を使って計算できて、これは1から2^(-54)/ln2を引いた値になる。
その値を計算すると約1 - 8.008×10^-17で、つまり境界のxは1024 - 8.008×10^-17になる。でもこれだと8.008×10^-20ではなく8.008×10^-17になってしまう。問題文をもう一度確認してみると、境界は2^(1024-2^(-53.4712336))と2^(1024-2^(-53.4712337))の間にあるということなので、xの値は1024 - 2^(-53.4712336)≈ 1024 - 8.008×10^-17になるはずだ。
ただし、さらに詳しく計算すると1023.99999999999999991991433…という値が出てきて、これは1024との差が8.008567×10^-20になる。つまり、2つの説明が異なる精度で境界を示しているようだ。
最初の説明は2^(-53.47)付近で大まかな境界を示していて、「さらにギリギリ」という部分がより正確な値を示しているんだと思う。
つまり、1024 - 8.008×10^-17 ≈ 1023.9999999999999919…という値が最初の境界で、さらに精密に計算すると1023.99999999999999991991433…という値が得られるということか。
でも差分を見ると8.008×10^-17と8.008567×10^-20では1000倍違う。もう一度考え直す必要がある。
もしかして学生の記法「2^(1024-2^(-53.4712336))」は「x = 1024 - 2^(-53.4712336)」という意味ではなく、「2を(1024 - 2^(-53.4712336))乗した結果」という意味なのかもしれない。その場合、x ≈ 1024 - 8×10^-17 ≈ 1023.999999999999991992…となり、2^x = 2^(1024-8×10^-17) = 2^1024 × 2^(-8×10^-17) ≈ 2^1024 × (1 - …)という形になるはずだ。
別の解釈として、「境界は…2^(-53.47)…」というのは1024 - x_boundary = 2^(-53.47) ≈ 8.008×10^-17を意味していて、これからx_boundary ≈ 1023.99999999999999192…が得られる。この小数部分の9の個数を数えると、約14個の9が続いているようだが、学生の記述と照らし合わせるとまだ何か合致していない。
数値計算で直接確認して、倍精度浮動小数点数における小数部分が1-2^(-53)から1.0に遷移する境界が1 - 2^(-54)の中点にあることを理解する必要がある。
学生が観測した境界x ≈ 1023.99999999999999991991433…は、1024-x ≈ 8.008567×10^-20に対応しており、これは80ビット拡張精度の2^(-64)/ln2 ≈ 8.008×10^-17ではなく、むしろlog2値が-63に近い2^(-64)/ln2の境界と一致している。
つまり、この計算機は内部計算に80ビット拡張精度（64ビット仮数部を持つlong double）を使用しており、exp2関数の計算時にfrac = 1 - 2^(-64)/ln2で(2-2^(-63))から2への遷移が起こることを示唆している。 The calculation confirms the boundary matches—when I compute the logarithm of that tiny difference, I get approximately -63.47, which aligns with my earlier estimate. So the critical threshold is around 1024 minus this infinitesimal value, and I’m seeing the actual number 1023.99999999999999991991433 is essentially 1024 minus about 8×10^-20, which tracks with the theoretical prediction.
Now I’m noticing a small discrepancy—my calculation gives 7.823×10^-20, but the observed value is 8.008567×10^-20. They’re close but not identical, so I’m wondering if the calculator might be using 80-bit long double precision for the power computation instead of standard 64-bit floating point. The boundary I calculated doesn’t match what the calculator shows, so either it’s using a different threshold or there’s rounding involved in how it computes log2(DBL_MAX). Let me trace through what happens when the calculator receives x = 1023.99999999999999991991433 — I need to understand how it stores this high-precision decimal and converts it to long double for the exp2 computation.
In 80-bit long double, the ULP varies by magnitude: for numbers around 1024, it’s 2^(-53) ≈ 1.11×10^-16, but for numbers in the [512, 1024) range it’s 2^(-54) ≈ 5.55×10^-17. Since x differs from 1024 by only 8×10^-20, which is smaller than either ULP, the rounding behavior depends on exactly where x falls relative to the representable values in that range. So the value x is actually much closer to the rounding midpoint than I initially thought—it’s well below the threshold where it would round up to 1024 in 80-bit long double precision. This means when the calculator converts x to 80-bit, it rounds to exactly 1024.0, and then exp2l(1024.0L) causes an overflow issue.
But wait, that still doesn’t explain the “OK” output. Let me step back and actually work through this systematically with code to see what’s really happening with the rounding boundaries and where exactly the student’s predicted exponent value falls. I’m recalculating the logarithm more carefully: log₂(1/(ln2 × 2^53)) should equal -log₂(ln2) - 53, which gives me around -52.47, not the -53.47 the student observed. This persistent off-by-one discrepancy is striking and suggests there might be something fundamentally wrong with my approach or the problem statement itself. The 54-bit precision hypothesis checks out perfectly—if the calculator uses one extra guard bit beyond standard double precision, the boundary shifts to exactly where the student observed it, around -53.47. This suggests the calculator implements a common floating-point optimization technique to boost accuracy in exponential computations.
Now I’m examining whether the actual computation method matters—specifically, how 2^x is calculated internally using exp(x * ln2) and whether rounding errors in that multiplication create the observed boundary independently of the precision model. I’m working through how the double-precision representation of ln(2) and the rounding errors in computing x * ln(2) affect the overflow boundary—the shift of about 1 bit in the observed threshold suggests the error comes from either the multiplication or the exponential computation itself. Let me set aside the theoretical calculations and instead verify what’s actually happening by examining my Python simulation results. I’m comparing the boundaries across different computational approaches—the pure double method gives a boundary around 2^(-43), while the exp(x*ln2) approach yields roughly -52.47 on the log scale, and the student’s observation of -53.4 sits closer to the integer-plus-fractional method’s -54, suggesting that approach might be the most stable.
Now I’m wondering if using exp2 for the fractional part instead of pow(2.0, frac) would change where the rounding happens—specifically, at what point does exp2(frac) round to exactly 2.0 versus staying at 1.9999…?
When frac equals 1 minus the smallest representable increment, I can expand 2^frac as 2 times e raised to a power involving ln(2), which approximates to 2 minus a tiny value around 1.54×10^(-16). Checking the nearest representable doubles around this value, the midpoint between the next lower double and 2.0 itself falls at approximately 2 minus 1.11×10^(-16), so the actual result would round to 2.0 in this case. So I’m computing the boundary value where exp2 rounds to exactly 2.0, which requires the fractional part to exceed a specific threshold. Working through the logarithm calculation, I get frac_boundary ≈ 1 - 8.009×10^{-17}, which gives x_boundary ≈ 1024 - 8.009×10^{-17}. When I take the log base 2 of that tiny exponent, I get -53.47—exactly matching what the student observed! So the mechanism is:
	1.	Calculator splits x into integer part (1023) and fractional part (0.999…)
	2.	Fractional part is converted to double: frac_double
	3.	Computes 2^frac_double = exp2(frac_double) using double precision
	4.	exp2(frac_double) is compared to see if it rounds to 2.0 or to 2-2^(-52)
	5.	If it rounds to 2.0 → 2^1023 × 2 = 2^1024 → overflow
The boundary is at frac_boundary = 1 - 2^(-54)/ln2 ≈ 1 - 8.009×10^{-17}, where exp2(frac) transitions from 2-2^(-52) to 2.0. But when frac itself is represented as a double, the nearest representable values around this boundary have a unit in the last place of 2^(-53), so I need to check which doubles near frac_boundary actually round up to 2.0 when passed through exp2. Ps / ULP ≈ ?)
Wait:
frac_boundary ≈ 1 - 8×10^{-17}
Nearest double below 1: 1 - 2^(-53) ≈ 1 - 1.11×10^{-16}
Nearest double above that: 1.0 (the next double)
frac_boundary = 1 - 8×10^{-17} is between (1-2^(-53)) and 1.0.
Middle between (1-2^(-53)) and 1.0 = 1 - 2^(-54) ≈ 1 - 5.55×10^{-17}
frac_boundary = 1 - 8×10^{-17} < 1 - 5.55×10^{-17} (middle)
So frac_boundary is below the middle, and rounds to 1 - 2^(-53)!
This means when frac = 1 - 2^(-53) (stored as a double), exp2(frac) rounds to 2-2^(-52), not 2.0.
And when frac = 1.0, exp2(frac) = 2.0, which causes overflow. So with the integer-plus-fractional approach, I get 2-2^(-52) when the fractional part is 1 - 2^(-53), but 2.0 when it’s exactly 1.0. Now I need to figure out where the boundary is in terms of the original x value—specifically, at what point does a decimal string like “0.9999…” transition from representing 1-2^(-53) to 1.0 as a double? So “0.99999999999999991” also exceeds the midpoint since 9×10^{-18} is smaller than 5.55×10^{-17}, meaning it rounds up to 1.0 and triggers the overflow as well. I see the issue now—I miscalculated the exponent. The difference between 1 and “0.99999999999999991” is actually 9 × 10^{-17}, not 9 × 10^{-18}. Since that’s larger than 2^{-54} (which is about 5.55 × 10^{-17}), this value rounds up to 1.0, causing the overflow. Now I’m comparing where these values fall relative to the rounding midpoint—since 9×10^{-17} and 8×10^{-17} both exceed the midpoint threshold of 5.551×10^{-17}, they all round down to 1 - 2^{-53}, which checks out so far.
But when I get to “0.99999999999999995” with 5×10^{-17}, that’s below the midpoint, so it rounds up to 1.0 and causes overflow—meaning the boundary is between the 4 and 5 in the 17th decimal position, which aligns with my Python results showing “9×16+4 is safe but 9×16+5 fails.”
Yet the problem statement indicates “1 is OK, 2 is NG,” which doesn’t match this “4 is OK, 5 is NG” pattern I’m seeing, so there’s still a discrepancy to resolve.
Looking at the actual boundary values, the fractional part should be around “0.99999999999999994448…” which puts the boundary x at approximately 1023.999999999999999944…, but the student’s observation shows a boundary closer to 1023.99999999999999991991433…—these don’t align since …9994 is greater than …9991.
This suggests the student might be observing something beyond just the fractional rounding behavior, possibly related to how 2^frac is actually computed rather than the theoretical rounding of the fractional part itself.
Now I’m reconsidering whether the boundary occurs when the exp2 calculation itself crosses a rounding threshold—specifically around frac = 1 - 2^{-54}/ln2 ≈ 1 - 8.009×10^{-17}, which would place the boundary at approximately “0.99999999999999992…” in decimal representation. I’m verifying the decimal expansion—the 16th position has a 9, then 1, 9, 9, 1 following, giving me 0.99999999999999991991… So x_boundary equals 1023 plus this fractional part, which matches exactly what the student observed. Now I see the complete mechanism: the calculator represents x as an integer part (1023) and a fractional part, and the boundary occurs precisely at 1024 minus 2^{-54}/ln(2). I’m catching an error in my analysis—the rounding boundary for frac to double is actually at 1 - 2^{-54}, not 1 - 2^{-54}/ln2 as I stated. When frac is below that midpoint it rounds down to 1-2^{-53}, and at or above it rounds up to 1.0, which means the student’s threshold is incorrect and would lead to overflow in the second case. Wait, I think I see the issue now—the calculator might not be using the frac-split approach at all. Instead, it could be computing 2^x directly as exp(x * ln2), where x is stored with high precision as a decimal, ln2 is a double constant, and the multiplication happens in some intermediate precision before comparing against ln(DBL_MAX) to check for overflow. The boundary would then be where x * ln2 equals ln(DBL_MAX), which gives me x_boundary = 1024 - 2^{-53}/ln2.
But when I calculate this, I get around 1024 - 1.602×10^{-16}, which corresponds to the -52.47 boundary I’m seeing, not -53.47. This suggests the stored ln2 constant might have a small rounding error—if the stored value is slightly larger than the true ln2, that would shift the boundary lower than expected. I’m trying to work out exactly how much this error would need to be to account for the discrepancy. So the error in the stored ln2 value would need to be 2^{-63}, which is actually smaller than a single unit in the last place for a double precision number—well below the representation error we’d expect. That approach isn’t panning out either. Let me step back and reconsider the problem from scratch, focusing on what the student actually observed: that boundary value around 1023.99999999999999991991433 with the peculiar gap at the 18th decimal place.
Now I’m computing what 1 - 2^{-54}/ln2 actually equals. Working through the arithmetic: 2^{-54} divided by ln2 gives roughly 8.009×10^{-17}, which means 1 minus that value lands right around 0.99999999999999991991—matching the observed boundary almost exactly. The computed boundary of 1023.99999999999999991990973 matches the student’s observed value to about 7 significant figures in the decimal tail, with the small discrepancy likely stemming from slightly different precision in the ln2 constant. The boundary actually represents the critical threshold where exp2(frac) rounds up from 2-2^{-52} to 2.0 in double precision, and the mechanism involves the calculator storing x as high-precision decimal and splitting it into integer and fractional parts. I need to reconsider this more carefully. When frac equals 1-2^{-53}, the true mathematical value of 2^frac works out to approximately 2 minus a tiny amount on the order of 10^{-16}. The nearest representable doubles to this value have a unit in the last place of about 2^{-52}, so I’m checking which double actually gets rounded to when exp2 computes this value.
The true result falls below the midpoint between 2-2^{-52} and 2.0, which means it rounds down to 2-2^{-52}. When I then apply ldexp to shift this by 1023 positions, I get exactly DBL_MAX, which is the correct answer.
Now I’m checking what happens when frac itself rounds to exactly 1.0 in the input.
When frac equals 1.0, exp2(1.0) gives 2.0, and shifting that by 1023 causes an overflow. The key insight is figuring out which string representation of frac causes the double value to transition from 1-2^{-53} to 1.0. Since those are the only two representable doubles in that range, the boundary occurs at their midpoint, 1-2^{-54}. But the student’s observed boundary is at 1-2^{-54}/ln2, which suggests the calculator isn’t simply converting the string to a double—there’s something more sophisticated happening in how it processes the fractional part.
The calculator appears to be computing exp2 on the full x value, and the actual boundary occurs where 2^x transitions from rounding to DBL_MAX to rounding to infinity. This happens when the true value of 2^x equals the midpoint between DBL_MAX and the next representable value above it, which is DBL_MAX × (1 + 2^{-53}). Solving 2^x = DBL_MAX × (1 + 2^{-53}) for x gives the exact threshold.
Now I’m working through the logarithm expansion to find the precise boundary value. I need to carefully compute log2(DBL_MAX) and account for the small correction term, but my initial calculation suggests the boundary might be exactly 1024, which seems suspicious—let me recalculate by expanding DBL_MAX in terms of its mantissa and exponent. So the unit in the last place at DBL_MAX is 2^{1023}, which means the overflow threshold is where rounding to nearest would produce infinity. That happens when the value reaches DBL_MAX plus half a ULP, which simplifies to DBL_MAX × (1 + 2^{-53}).
Working through the math, the overflow boundary is approximately 2^{1024} - 2^{971}. Taking the logarithm base 2 of this gives me x_overflow ≈ 1024 - 2^{-53}/ln(2), which is roughly 1024 - 1.602.
Now I’m being more precise about what overflow means for exp2 in double precision. The function should return infinity when the true value of 2^x is greater than or equal to the rounding threshold, which is DBL_MAX plus half a unit in the last place. This threshold works out to (2-2^{-52})×2^{1023} + 2^{1022}.
Let me think through the IEEE 754 representation more carefully. DBL_MAX is the largest representable finite value with 52 fractional bits, and the next representable value would be 2^{1024}, but that exponent can’t be encoded without triggering the infinity representation. So the midpoint between DBL_MAX and infinity determines when rounding produces infinity.
The unit in the last place (ULP) for DBL_MAX is the spacing between consecutive representable doubles in that range. Since DBL_MAX sits in [2^{1023}, 2^{1024}), the mantissa has 52 fractional bits, giving a spacing of 2^{1023} × 2^{-52} = 2^{971}. I need to be careful about the biased exponent encoding—for a number 2^k, the stored exponent is k + 1023, so I should verify this calculation against the actual IEEE 754 format. Now I’m calculating the exact overflow threshold by finding where 2^x exceeds DBL_MAX plus half a unit in the last place, which gives me the logarithmic condition for when overflow occurs. I’ve found it—this matches exactly what the student observed! The mathematical threshold where exp2(x) flips from returning DBL_MAX to infinity is precisely x = 1024 - 2^{-54}/ln2, which evaluates to about 1023.99999999999999991991. The calculator must be using correctly rounded double-precision arithmetic with high-precision internal representation of x to hit this boundary so accurately.
Now I’m working through the IEEE 754 mechanics: DBL_MAX plus half its unit in the last place gives the exact overflow point, and taking log₂ of that value yields the threshold formula. So when x = 1024 - 10^{-16}, it’s still below the overflow boundary of 1024 - 8×10^{-17}, which explains why the calculator can still compute it.
Checking the edge cases: seventeen 9s push past the threshold into overflow, but sixteen 9s stay safe. When a 1 follows the sixteen 9s, the value shifts slightly lower and remains computable, whereas a 2 in that position lands right at the critical boundary. So the exact overflow threshold is 1024 - 2^{-54}/ln2, which is approximately 1024 - 8.009×10^{-17}. Since 9×10^{-17} exceeds this value, the case with 16 nines followed by 1 stays below the overflow point, while 16 nines followed by 2 crosses it—this confirms the boundary behavior perfectly. So the final boundary value is 1024, and when I work through the precise calculation, I get x_boundary ≈ 1023.99999999999999991991435, which matches the student’s measurement to within just 2 in the last digit—excellent agreement that confirms the analysis. The calculator uses high-precision arithmetic to distinguish between values just below and above the overflow boundary—when x has 16 nines after the decimal it stays below the threshold and rounds safely to DBL_MAX, but with 17 nines it crosses into overflow territory and rounds to infinity.
The real question is how the calculator achieves this precision: it likely either feeds a high-precision decimal representation directly into the system’s exp2 function, or relies on an internal high-precision math library altogether. Either way, the boundary itself is mathematically clean—it’s precisely where IEEE 754’s overflow threshold for exp2 sits.
Now I’m going to write out the calculation and present this clearly.


完全に解明できた！
境界値は x_boundary = 1024 - 2^{-54}/ln2 = 1024 - 1/(ln2 × 2^54) であり、これは IEEE 754 binary64 の exp2() が正確丸め (round-to-nearest-even) において DBL_MAX を返すか INF を返すかの境界。
ここで重要な事実：
	•	`log2(1024 - x_boundary) = log2(2^{-54}/ln2) = -54 + log2(1/ln2) = -54 + 0.5287…
= -53.4712…` で、生徒の観測値 -53.4712336 と完全に一致している。
数値的には x_boundary = 1023.9999999999999999199143374... となり、生徒が記録した「1023.99999999999999991991433…」とほぼ完全に合致している。
これは IEEE 754 binary64 の round-to-nearest-even における overflow threshold の正確な値を反映している。
DBL_MAX が最大有限値で、その ULP（Unit in the Last Place）が 2^971 であるため、overflow threshold は DBL_MAX に ULP の半分を加えた値になる。この境界値以上の数値は無限大に丸められるため、対数を取ると log2(overflow_threshold) の計算を通じてこの -53.4712… という値が導き出される。
iPhone の計算機は入力値を 20 桁以上の高精度で保持しながら、exp2 関数を計算する際に IEEE 754 の正確な丸め規則に従ってオーバーフロー判定を行っている。
この実装により、「9が16個と17個の違い」といった微細な差を区別できるようになっていて、実際には x が境界値以上になると真の 2^x がオーバーフロー閾値に達して無限大になる。
ただし、x を double に変換してしまうと、9が14個以上は全て 1024.0 に丸められてしまうため、計算機は整数部と小数部に分割して、小数部だけを double に変換してから exp2() を呼び出し、最後に ldexp() で指数部を調整する方式を使っているのではないか。
ここで重要なのは、この計算で示した境界値 1024 - 2^{-54}/ln2 が、exp2(frac) の正確な丸め境界と一致しているということ。つまり計算機は小数部 frac を高精度のまま保持して exp2(frac) を計算し、その内部実装が正確にこの丸め境界を持つように設計されているのだろう。
frac がこの値より小さければ結果は 2-2^{-52} に丸められ、以上なら 2.0 に丸められるという仕組みになっている。
2^frac の値が 2 と 2-2^{-52} の中点である 2-2^{-53} より小さいかどうかで丸め方向が決まり、その境界条件から ε = 2^{-54}/ln2 という値が導き出される。
これにより x の境界値は 1024 - 2^{-54}/ln2 となる。
iPhoneの計算機は入力を高精度で保持していて、表示上は小数点以下16桁程度に制限されているが、実際の計算ではそれ以上の精度で処理している。
2^x の計算は整数部と小数部に分けて行い、小数部を高精度のまま保ったまま 2^frac を計算してから ldexp で指数部を調整する。オーバーフロー判定は 2^frac が 2-2^{-52} に丸まるか 2.0 に丸まるかで決まり、その境界値が frac = 1 - 2^{-54}/ln2 になる。
つまり x_boundary ≈ 1023.9999999999999999199143 で、この値がすべての計算をきれいに説明する。
ただし、実装がこの整数部・小数部分割方式を使っているかは確認できていないが、別の実装方法でも同じ境界に到達する可能性がある。例えば計算機が内部で高精度の10進数で x を保持してから double の exp2() に渡すような場合でも、結果は同じになるかもしれない。
もう一つの可能性として、計算機が x を long double（80ビット拡張精度）に変換して exp2l() を呼んでいるのかもしれない。80ビット long double では 1024 付近の ULP が 2^(-53) になるので、x = 1024 - 8.009×10^{-17} のような値がどう処理されるかが鍵になる。
この値は [512, 1024) の範囲にあるため ULP = 2^(-54) ≈ 5.55×10^{-17} となり、8.009×10^{-17} はこれより大きいので、long double での表現がどうなるかを確認する必要がある。
x は 1024 より約 1.443 ULP 下にあり、1024 - 5.551×10^{-17} と 1024 - 1.110×10^{-16} の間に位置している。
中点は 1024 - 7.776×10^{-17} で、x がこれより下にあるため、80ビット long double では 1024 - 2^{-53} に丸められる。
実際の境界値は 1024 - 2^{-54}/ln2 で、これが double に丸めたときに無限大とDBL_MAXを分ける正確な閾値だ。
オーバーフローが起こるのは真の値がDBL_MAX + ULP(DBL_MAX)/2以上になるときで、これは2^1024 × (1 - 2^{-54})に相当する。計算機は十分な精度で2^xを計算し、xを少なくとも20桁の有効数字で保持しているようだ。


解けました！全部がきれいに一致しました。最後に確認の計算と図解を。​​​​​​​​​​​​​​​​


全部が完璧に一致しました。これで完全な解明ができました。まとめを書きましょう。
計算機がどのように高精度でxを保持しているかについても少し考察を加えておきましょう。
key insightをまとめると：
	1.	境界値 x_boundary = 1024 - 2^{-54}/ln2 ≈ 1023.99999999999999991991433…
	2.	これはIEEE 754 binary64のexp2(x)が正確丸めでDBL_MAXを返すかINFを返すかの境界
	3.	log2(1024 - x_boundary) = -54 + log2(1/ln2) = -53.4712336…で、これが生徒の観測と完全に一致している
計算機の内部では、xを20桁以上の10進精度で保持することで、この微妙な境界を正確に識別し、exp2(x)の計算時に適切な結果を返すことができているようだ。
つまり、単純なdoubleのpow関数ではなく、より高精度な計算ロジックが実装されているということだ。


パズルが完全に解けました！まとめます。