アカウント名:
パスワード:
ZIPファイルで公開されているM82589933のテキストファイル
この手のはなぜかわざわざテキストファイルにする事が多いよね。1Bで0.42Bの情報って効率悪すぎだと思うんだが、なんで可変長整数/少数表記の標準ファイル形式とか産まれなかったんだろうね?圧縮すれば割と同じ事だろうけど。制御文字で切り替えて数字モードにする事で若干容量を小さくしたりコンピューターで処理しやすくなったりするだろうに。逆にファイルサイズが大きくなることもあるだろうけど、XMLとかJSONでのシリアライズで数字だけ2進数表記とかできれば処理も早くなるだろうし扱いやすい。
プログラムで24,862,048桁もあるような巨大な数値を扱う場合は数値は「文字列」として記述するのが普通です
たとえば比較的有名なライブラリとしてGNUの多倍長整数演算ライブラリGMPをみても,変数に大きな値を代入するAPIはmpz_set_str関数しかありませんhttps://gmplib.org/manual/Assigning-Integers.html [gmplib.org]そして,この関数の引数は null-terminated C string,つまり文字列です
ですから,この手のライブラリを使う人々にとっては文字列が標準フォーマットです.だからファイルフィーマットはテキストファイルが普通ですし,その方が便利です.
数値計算で何日も掛かるような大掛かりな計算をする分野ですから,24MB程度のデータファイルのサイズは気にしても意味がありません.
24,862,048文字を{}とかでくくったJSONとかXML形式とかリトルエンディアン,ビッグエンディアンとかを考慮しなければならないバイナリ形式なんてとても使えたものじゃないと思います.simple is best です.
それは交換形式であって、10進多倍長の内部形式としてはpacked BCD辺りも十分・・・C/C++ならビットフィールド使えば一桁1フィールドでそのまま表現可能。テキストだと上4ビットが邪魔で扱いにくい。
あと、MB単位の長さを考え始めるとNULL終端文字列一つ(連続メモリ領域)で扱うのも微妙。そろそろストリームを考えるべき長さだと思う。
短くなるようにコード化すると「このデータはどういうフォーマットなのか」という型情報が必要になってくる。テキスト形式なら「一目見れば誰でもわかる」とまではいかないけど、慣れてくれば見るだけで判別できることも多い。複数のデータ、それも型が混在しているものでも改行区切りやCSVなど見だけでも推測できるフォーマットが広く普及している。こういう「型情報付きでパック化したデータ」としてはMessagePack [msgpack.org]とかがあって、人間が直接目で見る必要がほとんどなくWebAPIなどでデータを頻繁にやりとりする場合はかなり有用だけど、こういう巨大ではあっても単発のデータではパック化することでテキストファイルと比べて得られるメリットって大してないと思う。
メルセンヌ素数をプログラム内部で扱う場合、2進以外ありえるの?2進で扱いやすい、ビット演算を簡単にできるところにメルセンヌ素数の意義があると思うのだけど。
多倍長演算で大きな数値を扱おうって場合、基数は2ではなく10の方が都合が良い場合がある。「任意精度の数値表記標準フォーマット 」みたいなことを考える場合は2以外の基数を想定するのは当然かと。
メルセンヌ素数の美味しい応用例に関していえば基数2で扱うほうが良い場合も多々あるかもしれんが……そもそもその場合メルセンヌ素数は桁数以外の情報がプログラム側に吸収されて値としては出てこない気も。
>圧縮すれば割と同じ事だろうけど。まさにこれが理由では?というか、情報量を考慮するなら「M82589933」という10文字足らずで表される数なんだから、10進で表すのはおまけみたいなもの。後半読んでると不安になってくるけど、2進表記で1が82589933個並ぶ特殊な数なのは分かってるよね。
バイナリの二進数表記とBCDの二種類のイメージですね。わざわざテキストにするのはデコードコストと標準フォーマットによる扱いやすさでしょうから。やり方はテキストファイルとしてできるだけ透過的に扱える仕組みが望ましく、制御文字で4Bit単位のBCD(+小数点やマイナスや終了文字)とか数桁まとめる(3B毎なら16777216でキリが良いかな?)とか、同じく制御文字でネイティブのintやfloatが埋め込める方法とか色々考えられますね。どこかで標準化されていれば普通にテキストエディタで扱えて処理も軽く便利な場面が結構あった気がします。
この手のデータをわざわざ可読テキストとして定義する需要が無いからね。受け渡しはバイナリで十分。門外漢にも広く公開しようと考えたら.txtは普及率も情報密度も圧倒的に良いでしょ。こんなもんのために専用ビューアをダウンロードしたい?
すでにテキストファイルが標準ファイル形式みたいな役割をしていて、このトピみたいな特殊用途向けデータ交換形式としては割と満足されているからじゃないかなあ。サイズについてはおっしゃる通り圧縮で対応でき、テキストを数値として読み込む標準関数が普及していることで扱いも問題ないから。
まあメルセンヌ数専用の圧縮形式作れば、82589933って情報だけあればデコードできるんだけどね。24.1MBのテキストファイルをヘッダ除いて8B(ASCIIコードの代わりにBCDコード使えば4B)に圧縮できるから超効率的
なんかネタが思いっきり滑ってる感がハンパないが、*「メルセンヌ素数のバイナリデータ」なんてネタは皆食傷気味* 素で気づいてないどっちだろ?
# 1111111.....
そうだ、16進数表示すりゃいいんじゃない? FFFFFFF...# Base64だと///////////...
すばらしい! ぜひ標準化すべきです [xkcd.com]!
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
任意精度の数値表記標準フォーマット (スコア:0)
ZIPファイルで公開されているM82589933のテキストファイル
この手のはなぜかわざわざテキストファイルにする事が多いよね。
1Bで0.42Bの情報って効率悪すぎだと思うんだが、なんで可変長整数/少数表記の標準ファイル形式とか産まれなかったんだろうね?
圧縮すれば割と同じ事だろうけど。
制御文字で切り替えて数字モードにする事で若干容量を小さくしたりコンピューターで処理しやすくなったりするだろうに。
逆にファイルサイズが大きくなることもあるだろうけど、XMLとかJSONでのシリアライズで数字だけ2進数表記とかできれば処理も早くなるだろうし扱いやすい。
Re:任意精度の数値表記標準フォーマット (スコア:3, 興味深い)
プログラムで24,862,048桁もあるような巨大な数値を扱う場合は
数値は「文字列」として記述するのが普通です
たとえば比較的有名なライブラリとして
GNUの多倍長整数演算ライブラリGMPをみても,
変数に大きな値を代入するAPIはmpz_set_str関数しかありません
https://gmplib.org/manual/Assigning-Integers.html [gmplib.org]
そして,この関数の引数は null-terminated C string,つまり文字列です
ですから,この手のライブラリを使う人々にとっては
文字列が標準フォーマットです.だからファイルフィーマットはテキストファイルが普通ですし,その方が便利です.
数値計算で何日も掛かるような大掛かりな計算をする分野ですから,
24MB程度のデータファイルのサイズは気にしても意味がありません.
24,862,048文字を{}とかでくくったJSONとかXML形式とか
リトルエンディアン,ビッグエンディアンとかを考慮しなければならないバイナリ形式なんて
とても使えたものじゃないと思います.simple is best です.
Re: (スコア:0)
それは交換形式であって、10進多倍長の内部形式としてはpacked BCD辺りも十分・・・
C/C++ならビットフィールド使えば一桁1フィールドでそのまま表現可能。
テキストだと上4ビットが邪魔で扱いにくい。
あと、MB単位の長さを考え始めるとNULL終端文字列一つ(連続メモリ領域)で扱うのも微妙。
そろそろストリームを考えるべき長さだと思う。
Re:任意精度の数値表記標準フォーマット (スコア:2)
短くなるようにコード化すると「このデータはどういうフォーマットなのか」という型情報が必要になってくる。
テキスト形式なら「一目見れば誰でもわかる」とまではいかないけど、慣れてくれば見るだけで判別できることも多い。
複数のデータ、それも型が混在しているものでも改行区切りやCSVなど見だけでも推測できるフォーマットが広く普及している。
こういう「型情報付きでパック化したデータ」としてはMessagePack [msgpack.org]とかがあって、人間が直接目で見る必要がほとんどなくWebAPIなどでデータを頻繁にやりとりする場合はかなり有用だけど、こういう巨大ではあっても単発のデータではパック化することでテキストファイルと比べて得られるメリットって大してないと思う。
うじゃうじゃ
Re: (スコア:0)
メルセンヌ素数をプログラム内部で扱う場合、2進以外ありえるの?
2進で扱いやすい、ビット演算を簡単にできるところにメルセンヌ素数の意義があると思うのだけど。
Re: (スコア:0)
多倍長演算で大きな数値を扱おうって場合、基数は2ではなく10の方が都合が良い場合がある。
「任意精度の数値表記標準フォーマット 」みたいなことを考える場合は2以外の基数を想定するのは当然かと。
メルセンヌ素数の美味しい応用例に関していえば基数2で扱うほうが良い場合も多々あるかもしれんが…
…そもそもその場合メルセンヌ素数は桁数以外の情報がプログラム側に吸収されて値としては出てこない気も。
Re:任意精度の数値表記標準フォーマット (スコア:1)
>圧縮すれば割と同じ事だろうけど。
まさにこれが理由では?
というか、情報量を考慮するなら「M82589933」という10文字足らずで表される数なんだから、10進で表すのはおまけみたいなもの。
後半読んでると不安になってくるけど、2進表記で1が82589933個並ぶ特殊な数なのは分かってるよね。
Re: (スコア:0)
バイナリの二進数表記とBCDの二種類のイメージですね。
わざわざテキストにするのはデコードコストと標準フォーマットによる扱いやすさでしょうから。
やり方はテキストファイルとしてできるだけ透過的に扱える仕組みが望ましく、制御文字で4Bit単位のBCD(+小数点やマイナスや終了文字)とか数桁まとめる(3B毎なら16777216でキリが良いかな?)とか、同じく制御文字でネイティブのintやfloatが埋め込める方法とか色々考えられますね。
どこかで標準化されていれば普通にテキストエディタで扱えて処理も軽く便利な場面が結構あった気がします。
Re: (スコア:0)
この手のデータをわざわざ可読テキストとして定義する需要が無いからね。
受け渡しはバイナリで十分。
門外漢にも広く公開しようと考えたら.txtは普及率も情報密度も圧倒的に良いでしょ。
こんなもんのために専用ビューアをダウンロードしたい?
Re: (スコア:0)
すでにテキストファイルが標準ファイル形式みたいな役割をしていて、このトピみたいな特殊用途向けデータ交換形式としては割と満足されているからじゃないかなあ。
サイズについてはおっしゃる通り圧縮で対応でき、
テキストを数値として読み込む標準関数が普及していることで扱いも問題ないから。
Re: (スコア:0)
まあメルセンヌ数専用の圧縮形式作れば、82589933って情報だけあればデコードできるんだけどね。
24.1MBのテキストファイルをヘッダ除いて8B(ASCIIコードの代わりにBCDコード使えば4B)に圧縮できるから超効率的
Re: (スコア:0)
なんかネタが思いっきり滑ってる感がハンパないが、
*「メルセンヌ素数のバイナリデータ」なんてネタは皆食傷気味
* 素で気づいてない
どっちだろ?
# 1111111.....
Re: (スコア:0)
そうだ、16進数表示すりゃいいんじゃない? FFFFFFF...
# Base64だと///////////...
Re:任意精度の数値表記標準フォーマット (スコア:1)
それはありえない。
メルセンヌ素数を16進数表記した場合は先頭は1or7となる。
もし先頭が3(2進数で11)かF(2進数で1111)だと全体が3の倍数になってしまいます。
ちなみに今回のものは16進数で先頭は"1"です。(1FFFFFFF...)
Re: (スコア:0)
すばらしい! ぜひ標準化すべきです [xkcd.com]!