助けてください問題が解決できない、ハードウェアの限界にぶつかる - ページ 9

新しいコメント
 
Urain:

to Komposter: Andreiさん、次元の問題で行き詰まるということは、問題の定式化を間違えたということです。

ここでは3つの選択肢を用意しました。

1 自分で考える

2 公開フォーラムで問題を公開する

3 プライベートで問題を解決する（解決できると思う人、秘密を守れると信頼できる人全員に対して）。

どういうことか説明しますと、ニュースを保存する場合、ニュース全体をトントンと書くこともできますし、「口座残高」が1、「口座資本」が2、といったように、典型的なフレーズをコーディング（圧縮）することも可能です。もう一つの典型的な問題は、すでにソートされたデータを埋めたいという欲求である。大きな次元では、これは死であり、最後に追加してインデックスによる条件付きソートを行う方が簡単である。

タスクの定義に間違いがある、というのはわかる気がします。

まあ、そんなやり取りは、優秀なテキストエディタでやればいいんですけどね。どんな条件でも（ニュースで言えば）冗長な情報は40％以上になるのでしょう。

ただし、テキストデータを処理するための書き込み機能がなくなるわけではありません。ボリュームの問題が解決されると、パフォーマンスの問題が忍び寄ってくることがあります。

そして一般的に問題文が完全に解決されていないのは、事実です...。データ量は多くないが、オプションが多い ))

 
Contender:

赤か？ いいえ、黒 です。なぜ白なのか？緑色だからです。"

ここではそういう話ではないんです。

 
YuraZ:

>>> 2つの圧縮された配列を比較する話。

配列がないため一意な要素が圧縮されず、検索に失敗する

チェック - 実践編

例：RARの2つのファイルを圧縮する

要素 - 08:01。

AND SEQUENCE

08:01:33.
08:01:38.
08:01:38.
08:01:39.
08:01:40.
08:01:49.
08:01:57.
08:16:53.
08:16:59.
10:09:28.
10:09:29.
10:09:29.
10:09:29.
10:09:30.
10:32:23.
10:32:24.
10:56:11.
10:56:12.
10:56:12.
10:56:12.
10:56:13.
10:56:39.
10:56:39.
10:56:39.
10:56:48.
10:56:48.
10:56:48.
10:57:03.
10:57:04.
10:57:04.
10:57:07.
10:57:07.
10:57:07.
10:57:51.
10:57:52.
11:44:50.
11:44:52.
11:44:52.
11:44:52.
11:44:53.
12:57:35.
12:57:46.
12:57:46.
12:57:46.
14:01:41.
14:01:46.
14:20:06.
14:20:08.



---

両方のRARファイルをHEXエディタで開き、以下のものを探してみてください。

要素08:01:が圧縮されていないことがわかると思います

で、2つ目のファイルの内容とは一致しません。


各エントリ、つまり各カラムを別々に圧縮すると、サイズアップは望めません。

逆に、アーカイバの制御データを犠牲にしてデータ量を増やすことになります

 
YuraZ:

チェックアウト - 実践編

例：RARで2つのファイルを圧縮する

要素 - 08:01。

AND SEQUENCE

08:01:33.
08:01:38.
08:01:38.
08:01:39.
08:01:40.
08:01:49.
08:01:57.
08:16:53.
08:16:59.
10:09:28.
10:09:29.
10:09:29.
10:09:29.
10:09:30.
10:32:23.
10:32:24.
10:56:11.
10:56:12.
10:56:12.
10:56:12.
10:56:13.
10:56:39.
10:56:39.
10:56:39.
10:56:48.
10:56:48.
10:56:48.
10:57:03.
10:57:04.
10:57:04.
10:57:07.
10:57:07.
10:57:07.
10:57:51.
10:57:52.
11:44:50.
11:44:52.
11:44:52.
11:44:52.
11:44:53.
12:57:35.
12:57:46.08:01:
12:57:46.
12:57:46.
14:01:41.
14:01:46.
14:20:06.
14:20:08.



---

両方のRARファイルをHEXエディタで開き、以下のものを探してみてください。

要素08:01:が圧縮されていないことがわかります。

となってしまい、どうにもこうにも一致しません。


しかし、各エントリ、つまり各カラムを別々に圧縮すると、サイズが大きくなることはありません。

逆にデータ量が増えてしまいます。

各レコードを個別に圧縮する必要があります。もちろん、圧縮できるほど大きなレコードでなければ意味はない。

 
Integer:

各レコードを個別に圧縮する必要があります。当然ながら、これは録音が本当に圧縮できるほど大きい場合にのみ意味がある。

そこで、ブロック単位で仕事をするようになったのです。従って、ブロックサイズに該当しない情報を見つけることは不可能である。
 
Contender:
さて、私たちは、ブロック単位で仕事をしなければならないという結論に達しました。従って、ブロックのサイズに対応していない情報を見つけることは不可能となる。

それはなぜでしょうか？何から？何が問題なのか？そんなことはなかった。

 
Integer:

それはなぜでしょうか？何から？何が問題なのか？そんなことはなかった。

そして、彼はまだミシュカとボールの話をしている :)
 
Integer:

各レコードを個別に圧縮する必要があります。当然ながら、本当に圧縮できるほど大きな録音でなければ意味がない。

ディミトリ - 各レコードを圧縮した場合、1行が

音量が大きくなりますよ～確認してみてください。


201 a1.rar -- compressed aaaa1 圧縮されているとは言い難いですが、圧縮されていますね。

535aaaa1 でした。

77 a2.rarの1つの要素が圧縮されるようになった - というか、それは圧縮されていません...しかし、ファイル+コントロールバイトで。

は8 aaaa2

---

データ容量が20ギガから20ギガの検索要素＋ベロシティバイトのサイズに増加します。

では、何が言いたいのか？

 
YuraZ:

ディミトリ - 各レコードを圧縮した場合、1行が

ボリュームが増えますよ～確認してみてください。


201 a1.rar -- compressed aaaa1 圧縮されているとは言い難いですが、圧縮されていますね。

535 aaaa1

77 a2.rar 1つの要素が圧縮されている - というか、それは圧縮されていない...しかし、ファイル+コントロールバイトで。

8 aaaa2

---

データ容量が20ギガから、20ギガの検索要素＋管理バイトのサイズに増加します

では、何が言いたいのか？

はい、データが短いとアーカイブする際にサイズが大きくなってしまうことは承知しています。
 
Integer:
そうですね、データが短いとアーカイブするときにサイズが大きくなってしまうのはわかります。

うんうん、だから君が提案したのはダメなんだよ

12345678910111213141516...21
新しいコメント