回答編集履歴
2
表現の変更
answer
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
|
-
今回の場合は再起呼び出し
|
|
1
|
+
今回の場合は再起呼び出し回数が多すぎることが最初の原因なので、そっちのパッチが大事かなと思います。コールスタックは有限なので…数字を増やすとリニアに呼び出し回数が増えるタイプの再帰呼び出しは考え方を変えないといけないかなと。
|
|
2
2
|
|
|
3
|
-
今回の設計の場合は隙間なくnの値が取られるので、再帰的じゃなくて、下から計算すればいいんじゃないかと思います。
|
|
3
|
+
幸い、今回の設計の場合は隙間なくnの値が取られるので、再帰的じゃなくて、下から計算すればいいんじゃないかと思います。
|
|
4
4
|
|
|
5
5
|
```
|
|
6
6
|
|
1
追記
answer
CHANGED
|
@@ -1,5 +1,7 @@
|
|
|
1
|
-
|
|
1
|
+
今回の場合は再起呼び出しのコストが高すぎることが最初の原因なので、そっちのパッチが大事かなと思います。コールスタックは有限なので…いくらでも大きくなるタイプの再帰呼び出しは考え方を変えないといけないかなと。
|
|
2
2
|
|
|
3
|
+
今回の設計の場合は隙間なくnの値が取られるので、再帰的じゃなくて、下から計算すればいいんじゃないかと思います。
|
|
4
|
+
|
|
3
5
|
```
|
|
4
6
|
|
|
5
7
|
#define SIZE 10000001
|
|
@@ -36,4 +38,7 @@
|
|
|
36
38
|
|
|
37
39
|
return 0;
|
|
38
40
|
}
|
|
39
|
-
```
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
この関数は現状のサンプルでは参照透過なので、予め決まったnの値に対応する辞書を生成しておくことによってメモリスペースと計算量をトレードオフにできます。
|
|
44
|
+
ファイルに全部書き出しておいてそこから値を引っ張ってきてもいいですし、等間隔に辞書で計算結果をもっておくことによって計算量の最大を固定することもできます。
|