アカウント名:
パスワード:
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で扱うほうが良い場合も多々あるかもしれんが……そもそもその場合メルセンヌ素数は桁数以外の情報がプログラム側に吸収されて値としては出てこない気も。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
任意精度の数値表記標準フォーマット (スコア: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で扱うほうが良い場合も多々あるかもしれんが…
…そもそもその場合メルセンヌ素数は桁数以外の情報がプログラム側に吸収されて値としては出てこない気も。