需要帮助!无法解决这个问题，我遇到了硬件限制 - 页 9

新评论
 
Urain:

to Komposter: 安德烈，如果你在尺寸问题上卡住了，那就意味着你在制定问题时犯了一个错误。

这里有三个选项。

1 自己想一想

2、在公共论坛上公开问题

3 私下解决这个问题（为每个你认为能解决这个问题并相信能保密的人）。

让我解释一下我的意思：如果你保存新闻，你可以写整个新闻的丁字裤，或者你可以对典型短语进行编码（压缩），"账户余额 "变成1，"账户资产 "变成2，等等。另一个典型问题的变种是希望填入已经排序的数据，对于大维度来说，这是死亡，更容易添加到最后并通过索引做条件排序。

我想我明白我的意思，当我说任务定义中存在错误时。

那么，你可以在一个好的文本编辑器中进行这样的替换。我想在所有条件下（当谈到新闻时），冗余的信息将>40%。

然而，它不会摆脱处理文本数据的写作功能。如果音量问题得到解决，性能问题可能会悄然出现。

而在一般情况下，问题陈述并没有完全解决，这是一个事实...数据不多，但选择更多 ))

 
Contender:

让我想起："它是红色的吗？ 不，它是黑色的。为什么它是白色的？因为它是绿色的。"

这不是我们在这里讨论的问题。

 
YuraZ:

>> 谈谈比较两个压缩序列的问题。

唯一的元素，因为它没有序列没有被压缩，搜索失败。

检查--在实践中

例子 - 压缩RAR的两个文件

元 - 08:01。

和序列

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.



---

在HEX编辑器中打开两个RAR文件，并尝试找到

你会发现，08:01:这个元素没有被压缩。

而它不会与第二个文件中的内容相匹配。


如果你压缩每一个条目--每一列单独的--你将不会得到一个尺寸的增长

相反，你将以牺牲存档者的控制数据为代价增加数据量。

 
YuraZ:

检查它--在实践中

例子 - RAR压缩两个文件

元 - 08:01。

和序列

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.



---

在HEX编辑器中打开两个RAR文件，并尝试找到

你会发现，元素08:01:没有被压缩。

而且它不会以任何方式匹配。


但如果你压缩每一个条目--每一列单独的--你将不会增加大小

相反，你会增加数据量。

每条记录都必须单独进行压缩。当然，只有当记录大到足以压缩它们时，它才有意义。

 
Integer:

每条记录都必须单独进行压缩。自然，这只有在录音大到可以真正压缩的情况下才有意义。

因此，我们已经到了必须分块工作的地步。因此，将不可能找到一个在大小上不对应于一个块的信息。
 
Contender:
好吧，我们已经得出结论，我们必须分块工作。因此，将不可能找到与区块大小不相符的信息。

这是为什么呢？从什么？有什么问题呢？没有走到这一步。

 
Integer:

这是为什么呢？从什么？有什么问题呢？没有走到这一步。

而且他还在和密歇根谈球 :)
 
Integer:

每条记录都必须单独进行压缩。自然，只有当录音大到足以真正压缩它们时，它才有意义。

迪米特里 - 如果你压缩每条记录 - 一行

你会增加音量--检查一下!


201 a1.rar -- 压缩的aaa1 我不能说它是压缩的，但它是压缩的。

它是535 aaaa1

77 a2.rar有一个元素被压缩了 - 或者说它没有被压缩...但是在文件中+控制字节

是8 aaaa2

---

数据量将从20G增加到20G的搜索元素+速度字节的大小

那还有什么意义呢？

 
YuraZ:

迪米特里 - 如果你压缩每条记录 - 一行

你会增加音量--检查一下!


201 a1.rar -- 压缩的aaa1 我不能说它是压缩的，但它是压缩的。

535 aaaa1

77 a2.rar有一个元素被压缩了 - 或者说它没有被压缩......但是在文件中+控制字节

8 aaaa2

---

数据量将从20G增加到20G的搜索元素+管理字节的大小

那还有什么意义呢？

是的，我知道，如果数据很短，归档时大小会增加。
 
Integer:
是的，我知道，如果数据很短，归档时就会增大尺寸。

嗯--这就是为什么你建议的那个没有用的原因。

12345678910111213141516...21
新评论