する質問をすることでしか得られない、回答やアドバイスがある。等)において扱える配列の大きさはどれくらいでしょうか?また、もしそれ以上の大きさの配列が必要な計算が出てきた場合どう対処すればよろしいでしょうか?attachmentクリップ0気になる質問をクリップするクリップした質問は、後からいつでもマイページで確認できます。クリップした質問に回答があった際、通知やメールを受け取ることができます。自分も答えを知りたい質問者以外のユーザにも役立つ評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。質問の評価を上げたことを取り消します低評価-評価を下げられる数の上限に達しました評価を下げることができません1日5回まで評価を下げられます1日に1ユーザに対して2回まで評価を下げられます質問の評価を下げるteratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。コメントをしてください。送信する質問の評価を下げる機能の利用条件この機能を利用するためには、以下の事項を行う必要があります。64bit)でArray.new(サイズ)をpry上で試して見ました。できる、しかし、2**32だと32GiBとかあり得ないぐらいメモリが消費される。重いけど、一応動くようだ。言語仕様上は特に制限が無いためシステムが許す限り無限大と思われます。64bitでは64bitになる)が収まる2**63-1があるようですが、実際は2**60-1以下に制限されているようです。それが収まるだけのメモリが必要です。メモリさえ収まればいくらでもいけますが、1要素あたり8バイト必要なようですので、2**60-1を収めるには、8EiB(エクスビバイト)が認識できるシステムが必要でしょう。RHEL7ですら理論上はメモリの最大が64TiBのため、2**43が限界になると思われます。Cたしか、配列の添字がintに制限されていたはずです(ちょっと曖昧、C11のドラフトをさらっと見たけど、見つけられなかった)。現在のほとんどのシステムではintは32bitのため、最大値が2^31-1になりますが、Cの規格上はintは16bit以上であればいくらでも大きくてもいいので、システムによってはより大きい値を扱えるかも知れません。ECMAScript言語仕様として、Arrayのlengthプロパティが2^32未満(2^32-1以下)という制約があります。実際は、動作する環境のメモリ次第と思われます。評価が高い回答ほどページの上位に表示されます。remove低評価0回答の評価を下げる下記のような回答は推奨されていません。評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。commentコメント投稿link+1各言語において扱える配列の大きさはどれくらい言語といってもたくさんありますし環境によって違う場合もあるかと思います。特定の言語の仕様を知りたければ言語仕様を学ぶべきではないでしょうか。それはともかく指標の順番に連続領域に確保されるようなタイプの配列と仮定すると指標となる整数が30bit前後ならば多くの言語で(言語仕様上は)扱えそうな印象です。性能的に搭載したメモリーの制約を受けるでしょうから多くの場合ずっと小さなサイズとして設計するのが適切と思います。それ以上の大きさの配列が必要な計算これは「単純な配列ではなくアプリケーションの要求に応じた別の構造を用いる」としか言えないと思います。大きなサイズの配列を扱わなければならない応用として思い浮かぶのは例えば「疎な配列」ですが、そうした場合特別な配列(SparsArrayなどと呼ぶと思います)を用いるかも知れません。要素の充填率が高い配列ならば疎な配列は使えないのでアクセスの局所性に配慮して配列の代替構造やアルゴリズムを考えることになるでしょう。ご質問の内容は少々漠然としていると思います。この質問の意図に何か背景があるならもっと具体的に質問したほうがいいかも知れません。評価が高い回答ほどページの上位に表示されます。remove低評価0回答の評価を下げる下記のような回答は推奨されていません。評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。commentコメント投稿link+1・扱える配列の大きさはどれくらい・・・扱う言語のインデックスが64ビットまで使えて、(スワップ等)メモリ管理が出来れば搭載されているHDDの空き容量が限界と思います。9223372036854775807です。メモリ8GB)[加筆]もし、出現する数値に偏り(同じ数値が連続するなど)があるなら圧縮すればもっと入ると思います。評価が高い回答ほどページの上位に表示されます。remove低評価0回答の評価を下げる下記のような回答は推奨されていません。評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。commentコメント投稿link+1以前c言語とGo言語で巨大な配列のソートを比較した際に、メモリについてもわかったことがあったので。c言語をwindows上で動かそうとすると(bcc)、int型(32bit)の配列が25万強でスタックオーバーフローになりプログラムが強制終了します。c言語をlinux上で動かすと(gcc)、250万件ほどです。OSないしコンパイラによって差が出るみたいですね。解決策として、malloc()という関数でヒープ領域を確保することが挙げられます。(free()での開放を忘れずに)Go言語等スタックオーバーフローは自動的にヒープ領域を確保しない言語だから起こることで、Goなどの高水準な言語はint型(64bit)が1億件だろうとメモリの確保を意識せず動作します。(メモリに余裕があれば)また、ガベージコレクションに対応していればc言語のfree()のような開放をする必要が無くなります。高水準な言語では基本的に確保も開放も自動なので、極端にいえば「自分のPCの空きメモリサイズ=確保できる配列サイズ」だと考えてもいいでしょう。ヒープ領域はわざわざメモリが空いていることを確認して確保しにいくのでスタック領域よりも低速であることに気をつけてください。評価が高い回答ほどページの上位に表示されます。remove低評価0回答の評価を下げる下記のような回答は推奨されていません。評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。頂いたご意見への回答は行っておりません。