Координатные схемы сжатия

абгадрдаринлианирнлл - сожми
более того, ты перешел к абсолютно не адекватным примерам CSC -это АС без потери качества, т. ч. причем здесь: png, gif......????

 

На счёт абгадрдаринлианирнлл подумаю, только нужно будет для чистоты эксперимента заменить легко сужаемые буквы, эквивалентным набором случайных чисел
CSCшные 2,5% выигрыша в размере с практической точки зрения весьма не густо
А png, gif - вариации на тему LZW и они

 

вообще - то, не понимаю к чему ты предираешься: правило золотого сечения абсолютно - исходя из него: алгос ужимающий малоизбыточные данные не способен давать высокий процент сжатия(если ты знаешь как ето обойти - я подамся к тебе в ученики и бог присоединится ко мне: он тоже не ведает как нарушить это правило)-)

для файл серверов и 0,5% много значит - экономия траффика ещё никому не мешала
P. S.

ты сначала сожми эту строку, а потом забрасывай тапочки на более сложные цепочки)

 

абгадрдаринлианирнлл
Строим словарь:
абгдринл - занял 8*8 = 64 бита
01234567 - адрес в словаре поместился в 3 бита
архивируем:
01203430456750654677
итого: 64 (словарь) + 20*3 (текст) = 124 бита
Что составляет 22,5% против твоих 2,5% )
Хотя схема грубо - прикидочная и наверняка можно лучше

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

ЗЫ: я сначала тормознул и насчитал в словарном адресе 4 бита вместо трёх, и всё равно получил выигрыш перед CSC ))))

ЗЗЫ: А на счёт Бога - это ты зря - он придумал кроооошечный ген, из которого можно разархивировать хоть слона, хоть синего кита )) Всё перехожу на освоение фрактальных схем - вот енто интересно

 

угу, молодец - словарик заюзал.
абгцдрдцронлианитфлф (4 бита на букву, 96 бит словарь)
А – 2 0
Б -1 -4
Г -1 -4
т -1 -4
о -1 -4
Д -2 0
Р – 2 0
И – 2 0
Н – 2 0
Л – 2 0
Ф- 2 0
Ц – 2 0
повторяю(уже реально надоело): малоизбыточные данные

УДАЧИ!!!!! - я уже давно на сжатие потерял всякий оптимизм (впрочем, позже опишу ка сжимать данные без повторяющихся цепочек, но там свои подводные камни - правило золотого сечения абсолютно)

яви хоть один пример, где правило злотого сечения нарушено - ген ничего не распаковывает.

 

абгцдрдцронлианитфлф
CSC = +4 бита
Ты так и не показал данные которые пакуются CSC и не пакуются лучше чем то другим

А вот это напрасно - достаточно разочароваться в CSC и искать более эффективные пути
По прежнему уверен, что они есть

 

абгцдрдцронлианитфлф - ужми: потом говори
+4 против -16
насчет оптимизма: можно, конечно, ужать тот же рар архив и на 50% - тока алгос этот будет зверем по требованиям к системе и какой -нить вшивый файлик ты будешь жать до своей и старости и конец операции сжатия увидишь, но не в этой жизни. если у тебя есть (как ето называли в одной книжки) бог - машина (любое конечное кол - во операций за время 0)- вот тады да могешь товарища брут - форса юзать по-любому поводу и для сжатия и для взлома любого шифра - ты счастливый чел. и завидовать я тебе буду черной, оооооочень черной завистью, но, коли, тачки у тебя таковой нет рекомендую губу по полу не катать - пол грязный и липкий: споткнуться можно о губу, как о шнурок

 

Ты не внимательно считал 4 и 16 - с одинаковым знаком ! - т.е. в обоих случаях разбухание )))

Ан нет похоже рано CSC на свалку истории )
Есть рабочая версия !!! с относительным смещением !!!
"Буква_1", стоп_бит, Адрес, стоп_бит, Адрес, стоп_бит, ... "Буква_2" ...
где поле Адрес является 3х или 4х битным относительным адресом следующего вхождения "буквы" и отсчитывается с нуля относительно следующей по отношению к букве позиции (надеюсь кто-нибудь поймёт то, что я наговорил Если в пределах досягаемости Адреса есть ещё такие же буквы, то их отсчёт ведётся уже не от стартовой буквы, а от той позиции где найден её повтор (пример буква "ц" ниже). Таким образом можно ловить довольно глубоко уходящие цепочки.
Т.е. понятие блока заменяется на понятие "досягаемости для адреса"
В отличие от исходной версии, где очередная буква сравнивалась со всем остатком файла, здесь получается "окно - медуза" плывущая по файлу и периодически запускающая "щупальца" неограниченной длины - соответственно при определённых условиях можно повязать этими "щупальцами" не малый блок, а весь файл и при этом уже не будет квадратичных тормозов с ростом размера файла и можно достаточно широко варьировать соотношение буква\адрес (главное будет поймать оптимум этого соотношения для конкретных данных).

Код (Text):

1. буква  стоп   Адр_4б  стоп    Адр_4б   стоп  сумма бит
2.   а    0   12  1           14
3.   б    1                   9
4.   г    1                   9
5.   ц    0   3   0   12   1  19
6.   д    0   1   1           14
7.   р    0   2   1           14
8.   д    - уже внесён -
9.   ц    - уже внесён - следующее смещение "ц" считается с нуля относительно "р"
10.   р    - уже внесён -
11.   о    1                   9
12.   н    0   3   1           14
13.   л    0   6   1           14
14.   и    0   2   1           14
15.   а    - уже внесён -
16.   н    - уже внесён -
17.   и    - уже внесён -
18.   т    1                   9
19.   ф    0   1   1           14
20.   л    - уже внесён -
21.   ф    - уже внесён -
22.   ц    - уже внесён -
23.                 итого:     153 бит

Исходных букв: 21, что составляет 168 бит
т.е. выигрыш = 8,928571429%
Я по прежнему не уверен, что не существует более эффективного способа сжать такие данные, но ~9% уже не 2,5 как в #42 и не проигрыш как в #47 Что есть Гуд )

ЗЫ: без буквы Ц в конце тоже нормально жмётся, но нужен был пример тройного вхождения для демонстрации принципа

ЗЫЫ: UbIvItS только ты не хами а то сам будешь свои кривые алгосы оптимизировать

 

точно будет проигрыш.
но DSCC покажет положительный результат.
насчет "не хами": сорри, конечно, но надоедает из раза в раз повторять одно и тоже. к тому же, правда жизни зачастую не ахти как красива.
насчет "кривые алгосы": сделай лучше, а потом поноси, что есть, но, думаю, коли, ты усе же сделаешь что - то действительно лучше - ты уже не будешь бросать столь не обдуманные реплики.
относительная адресация имеет большую вероятность потерь - потому и показывает лучше результат, опять же правило золотого сечения в действии

 

UbIvItS
Как видишь - сделал
Кстати приведи динамический пример, который это обработает.
А про вероятность потерь - я тебе самого начала говорил, что бесполезно оптимизировать алгоритм сжатия "в общем виде" без привязки к конкретным данным. Классический пример - по теории вероятности последовательность из десятков пробелов или переводов строк практически не вероятна, а в реальных файлах встречается запросто.

И ещё обрати внимание - когда до тебя что-то туго доходит, я тебе не грублю, а терпеливо указываю на ошибки, и если опять не доходит, то ищу другие технические аргументы. Например, ты вот всё повторяешься про "малоизбыточные" данные, но так и не объяснил мне на основании чего 32 повтора в 63 байтах ты называешь "малоизбыточными" данными? Внимательно перечитай пост "про вилку", и согласись, что назвать такую архивацию "кривой" - имею полное право, даже не предлагая замены, хотя я и это сделал

 

абгцдрдцронлианитфлф - я прогнал: здесь 5 бит адресация, так что в итоге 4 бита выигрыша.

не вижу - относительная адресация показывает выигрыш за счет большего риска проигрыша.
к тому же алгосы IF и DC не ты делал.

менее оптимистичная модель сжатия имеет большее множество файлов, где она работает, таким образом под нее можно с большим успехом делать алгосы препроцессинга.

где же 32, когда 3 экземпляра нужно: 63 байта тебуют 6 бит адресации + стоп бит

чиатай ман - единстственное, что замечу: 5 бит - 32 адреса 32-20= 12 свободных кодов(ну еще код 0 тоже можно юзать) - дальше считай сам.

 

))))))
Молодец! А как на счёт постановки задачи с которой всё начиналось?

Я у тебя что требовал? - дать мне образец данных, которые сжимаются этой схемой и не сжимаются чем то-ещё. Ты дал образец "абгцдрдцронлианитфлф", который той схемой не сжимается (почему - см. пост "про вилку", думаешь мне не надоело это тебе повторять?) Я этот образец сжал, причём даже больше, чем на твои "подтасованные" 4 бита.

предложенная тобой схема (сегмент 63 байта буква 8 бит) в статическом варианте требует, чтобы повторных включений было не меньше чем 50% что и составляет 32 из 63!!! (опять см. пост "про вилку"

А ты сам то делал? - тогда кинь экзампл плизз, чтобы я наконец понял, что это действительно круто , только не забудь включить в него данные которые сжимаются этими алгосами и не сжимаются в большей степени чем то-ещё.

 

не совсем понял откуда выплывает 32 при словаре 21 буква
ага, кажись, осознал: это ты про то, что с двумя экземплярами каждой буквы сжатие будет 0 - ну, и что???..??

не плохая реплика: коим ты образом собрался ловить оптимум.
более того: опять же повторяюсь, относительная адресация показывает выигрыш только за счет увеличения риска проигрыша, поэтому я, вообще, не понимаю чего ты хочешь мне доказать. Вот, если ты покажешь алгос с той же вероятностью проигрыша, что и CSC и тем же временем обработки файла, но большей степенью сжатия, тогда ты не зря напрягаешь Клаву)
короче, я тебе предлагаю найти некую схему, которая при всех равных условиях всегда (еще раз повторяю ВСЕГДА) давала результ как минимум тот же что и CSC, тогда я точно стану твоим учеником!!!..!
а, вообще, что мелочится: упакуй сразу два бита в один и чтобы распаковка ВСЕГДА была однозначна)
Какой там закон золотого сечения, код Шеннона - все это сделано для ламеров вроде меня, а для реальных челов это семечки)

 

Неа - это когда ты перешёл с изначально заявленной схемы 8х64 к схеме 8х32 (см #51), то увеличил риска проигрыша
Обрати внимание любой из твоих блочных схем: 8х8, 8х16, 8х32, 8х64 может быть сопоставлена эквивалентная схема с относительной адресацией. Причём она выберет все те же данные и упакует их с той же степенью сжатия, что и эквивалентная ей статическая схема, но в отличие от неё не упрётся в размер блока, а сможет продолжить ловлю цепочек хоть до конца Гбайтного файла (если конечно таковые цепочки в нём найдутся) и обрати внимание - в отличие от первоначальой схемы 32х32 (которая тоже претендовала на обработку Гб) эта не имеет квадратичной зависимости времени от размера файла.
Кстати эффективность относительной адресации можно ещё повысить если выкидывать из смещения буквы с пометкой "- уже внесён -"
И ещё помедитируй потщательнее, чтобы заметить, что относительная адресация даже если она не поймает цепочку (тройное и более вхождение) всё равно имеет больший радиус действия чем эквивалентная ей статическая поскольку адрес возможного повтора последней буквы отсчитывается от неё же а не от начала блока. И именно за счёт этого у меня сработала схема 8х16, там где тебе потребовалась 8х32 (опять см. #51).
Странно - неужели эти вещи тебе не очевидны?

А здесь имеется в виду, что у одних файлов буквы будут повторятся на небольшом расстоянии друг от друга и для них эффективнее будет к примеру схема 8х16, а для других расстояние будет больше и придётся использовать 8х64, смирившись с тем, что она даёт меньшую степень сжатия. Имхо совершенно неоправданно всегда использовать 8х64 "как более универсальную", если вдруг в процессе архивации обнаружилась возможность применить 8х8, дающую куда лучшее сжатие.

 

при чем тут радиус - здесь речь о том, что при относительной адресации адрес буквы может выражаться несколькими кодами, а при абсолютной всегда одним кодом - следовательно относительная адресация при уменьшении длинны прыжка имеет большую планку выигрыша, но вероятность, что адрес будет выражен одним кодом тем меньше, чем меньше длинна прыжка.
ты лучше, мне ламеру несведующиму поведай: неужели более оптимистичная модель способна всегда обойти более пессимистическую модель.

к чему это ты : сегмент обрабатывается как массив в ОЗУ - собствеенно поэтому я и перешел на эту модель: гораздо быстрей формировать сегменты в оперативки и, затем строкать готовые пирожки в файл

 

Эк ты завернул Мне такими заворотами слабо оперировать ))
Какая разница какими кодами записывается архив? - главное:
1. эти коды должны быть как можно короче (а в относительной адресации коды смещений всегда короче чем в эквивалентной ей статической схеме)
2. алгоритм разархивирования должен быть способен восстановить по этим кодам исходные данные (и это условие прекрасно соблюдается)
Могу только посоветовать только еще внимательно помедитировать над #54 и #48

ЗЫ: а схема с относительной адресацией в отличие от статической уже есть вещь достойная релиза, как нибудь на досуге слеплю и погоняю на рельных данных. Хочешь для чистоты эксперимента слепи статическую и тогда реально сравним

 

как настрокаю, конечно, сравним

угу и совсем неважно, что он больше файла - самое главное, чтоб распаковывался: полностью согласен)

 

вообще-то нет - просто так "в лоб" выкинуть не получится, однако, возможно рациональное зерно в этой мысли есть треба внимательнее обдумать.

странно, что ты не заметил пункт 1.... ))

 

рекомендую тебе зарелизить DSC c двухбитными буквами: две буквы выстраиваються по относительной адресации с прыжком в два бита, две другие кодяться одним битом - довольно симпотная схемка в теории)) - позволяет понять все прелести оптимистичных моделей на практике

 

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