アカウント名:
パスワード:
まぁ少なくとも10兆バイトの文字列を書く必要があるからその容量になったんだろうけど、個人でこの量は凄い。あるHDDの中身は円周率の一部分のみが延々と書かれているわけか、これはこれで凄い。
また挑戦するのであれば次は「効率」も考慮した内容になると面白そう
> まぁ少なくとも10兆バイトの文字列を書く必要があるからその容量になったんだろうけど、個人でこの量は凄い。
ギネスブックに記録を申請して、晴れて記録更新が認められた暁には、その10兆バイトがギネスブックに記録されるんでしょうか。
アカシックレコード圧縮というものがあってだね。。。
※アカシックレコードへのポインタを示せば、どんな情報も[ポインタバイト数]に圧縮できるという理論。※転じて、円周率の何桁目、といえば値は決定しているのでわざわざ全て記す必要が無いということ。
アカシックレコードを理想的な無限系列としても任意のデータを圧縮する時に、圧縮後のデータ長（ポイントバイト数）の期待値が元のデータの平均データ長と同じになるのは容易に証明できるはず
系列が１ケタ増えたときに表現できるデータの種類は１種類しか増えないからね（元が固定長データの場合。可変長データだと元のデータサイズも記録しておかないと復元できない）
例：2ビット圧縮するときに必要なアカシックレコード -> 001100 -> ポインタ位置 001 -> ポインタ位置 110 -> ポインタ位置 3（ローテート）11 -> ポインタ位置 2結局記録には2ビット必要
アカシックレコードへのポインタは可変長なんですよ。しかも連想配列です。
例えば円周率の10兆桁目の値は、「πの10兆桁目」これだけで呼び出せるんですよ！
可変長ポインタって素晴らしい。
となると10兆桁までのπは
πの1桁目とπの2桁目とπの3桁目と...πの10兆桁目
と書けばいいわけですね。あれ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
HDDの中身 (スコア:2)
まぁ少なくとも10兆バイトの文字列を書く必要があるからその容量になったんだろうけど、個人でこの量は凄い。
あるHDDの中身は円周率の一部分のみが延々と書かれているわけか、これはこれで凄い。
また挑戦するのであれば次は「効率」も考慮した内容になると面白そう
素朴な疑問 (スコア:1)
> まぁ少なくとも10兆バイトの文字列を書く必要があるからその容量になったんだろうけど、個人でこの量は凄い。
ギネスブックに記録を申請して、晴れて記録更新が認められた暁には、その10兆バイトがギネスブックに記録されるんでしょうか。
Re: (スコア:-1)
アカシックレコード圧縮というものがあってだね。。。
※アカシックレコードへのポインタを示せば、どんな情報も[ポインタバイト数]に圧縮できるという理論。
※転じて、円周率の何桁目、といえば値は決定しているのでわざわざ全て記す必要が無いということ。
Re: (スコア:0)
アカシックレコードを理想的な無限系列としても
任意のデータを圧縮する時に、圧縮後のデータ長（ポイントバイト数）の期待値が
元のデータの平均データ長と同じになるのは容易に証明できるはず
系列が１ケタ増えたときに表現できるデータの種類は１種類しか増えないからね
（元が固定長データの場合。可変長データだと元のデータサイズも記録しておかないと復元できない）
例：2ビット圧縮するときに必要なアカシックレコード -> 0011
00 -> ポインタ位置 0
01 -> ポインタ位置 1
10 -> ポインタ位置 3（ローテート）
11 -> ポインタ位置 2
結局記録には2ビット必要
Re: (スコア:0)
アカシックレコードへのポインタは可変長なんですよ。
しかも連想配列です。
例えば円周率の10兆桁目の値は、
「πの10兆桁目」
これだけで呼び出せるんですよ！
可変長ポインタって素晴らしい。
Re:素朴な疑問 (スコア:0)
となると10兆桁までのπは
πの1桁目とπの2桁目とπの3桁目と...πの10兆桁目
と書けばいいわけですね。あれ。