как мне определить вореции распаковки по длине дерева???

[Jura1990]

Сообщение от Stilet

Давай по-простому для тех кто Хаффмана не вкурил:
У тебя есть три числа: 1 2 3.
Соответственно 00000001 00000010 00000011
Можешь пошагово описать их упаковку?

так что ли:

00__00_00_01...00_00_00_10...00_00_ 00_11
0_0_0_1 0_0_0_01 0_0_0_10


00000001...00000010...00000011
0_0_0_1...0_0_0_01...0_0_0_10
00_01...00_00_1...00_01_10

00000001...00000010...00000011

00000001...0000001...000000011
000100001...000110

00_01...00_00_1...00_01_10
0_1...0_0_1...0_1_01
01...00_1...01_01

00000001...0000001...000000011
000100001...000110
01001010.....1

01...00_1...01_01
1...0_1...1_1
10_11_1

00000001...0000001...000000011
000100001...000110
01001010.....1
10111

дальше сжатию не подается иначе мы потрем звенья и ячейки.






00=0
01=1
10=01
11=10

[Utkin]

Хорошо, давайте прогу, которая сжимает/разжимает файл, мы потестим.

[Stilet]

Предложенный алгоритм ничего общего с алгоритмом Хаффмана не имеет))

Ну я так... По Фомфану

так что ли:

Я же просил: По шагам. Расписать и разжевать. Я ничего в выкладках твоих не понял. Набор бессвязных цифр.

Utkin

Ты алгоритм автора понял? Можешь обьяснить как он рассуждает?

[Utkin]

Можешь обьяснить как он рассуждает?

Могу как сжимает - вот в его последнем посте (который 21) он в конце привел правила преобразования. Он многократно их выполняет. Не вкурил только как проходит обратная распаковка. Распаковать обратно можно только если соблюсти последовательность в обратном порядке. Я так понял что ТС надеется что все преобразования обязательно выполнятся (хотя в начале он там писал про if). Однако мое мироощущение подсказывает мне что совершенно не обязательно выполнение всех 4-х преобразований за одну итерацию. И именно эту инфу ТС теряет нафиг.

[Stilet]

вот в его последнем посте (который 21) он в конце привел правила преобразования

Эти?:

00=0
01=1
10=01
11=10

Т.е. идет подмена согласно этому словарю?

[Utkin]

Я так понял что да.

[XE5]

00__00_00_01...00_00_00_10...00_00_ 00_11
0_0_0_1 0_0_0_01 0_0_0_10

Это разжать уже нельзя, так как не понятно что разжимать
0_1 в 10 или 1 0 в вообще непонятно что (это может быть и 10 00, и 11). Если бить байты по группам, то группы будут плавать, из за сжатия. В общем идея понятна, но 100% логики не вижу. Как увижу, сразу же накидаю программу.

[Utkin]

В общем идея понятна, но 100% логики не вижу.

Дык, естественно. Это же код Творца, как Вы можете его логику увидеть? Тут только у ТС траву спрашивать надо и то не факт, что попрет.

[Человек_Борща]

вы только подумайте как сильно можно сжать один гигабайт по данному алгоритму до рамера саабщения:

Вы поймите одно: Сжать можно любые данные, до любых размеров. Проблема не в алгоримах сжатия, потому что это относительно просто.
Проблема в алгоритмах распаковки и восстановления сжатых данных, быстро, и без потерь, и от этого надо оталкиваться при написании алгоритма сжатияданныхтак, чтоб потом ещё и распаковать что-то можно было.

И да, чем ваш алгоритм лучше 7zip?
У меня каждую неделю есть лог в ~30 гб, 7z его за сутки в 300-700mb сжимает, восстанавливает ещё быстрее и без потерь.
WinRAR нервно курит в сторонке, ибо итог значительно в разы больше чем у 7z.

[Utkin]

WinRAR нервно курит в сторонке, ибо итог значительно в разы больше чем у 7z.

Winrar заточен на универсальность - то есть эффективно сжимать любые данные. Здесь же просто частный случай. Нужно проводить полное сравнение.