и ещё, насчёт формул, даже если их набрать в Worde
а я их набирал ваще в FAR'e, даже после этого оны выглядят так, что от одного их вида становится не очень хорошо.
Поэтому там есть ремарка, что стоит повторять вывод формул на бумаге (если конечно это кого-то интересует), тогда всё будет более или менее понятно.
Я могу дать исходный файл как есть, однако уверяю что этого оно всё равно не красиво
ARI
А никто не пробовал арифметическое сжатие построить ?
Пусть даже и получится плохо. Но интересно было бы посмотреть...
я пробовал. результат смотри в одном из номеров InfoGuide (6 кажется)Сообщение от Proteus
исходные файлы жмет хуже чем обычные паковщики (hrust, hrip) но позволяет неплохо дожимать их (за исключением раров). недостаток- очень медленная скорость упаковки/распаковки
Привет!
Сейчас посмотрел - нет в IG6 arif16m.H. Только статья. Страшный монстр на асме получился? Какой длины? Как я понял, в твоей реализации количество кодов -256. Пробовал уменьшить их до 32, например? Как это бы повлияло на твою реализацию (скорость работы, длина программы)?
Дожимать выход именно LZ не пробовал?
Пока. Дима.
Сейчаз уже есть отлаженная программа
которая формирует конкретные данные, релизующие указанный метод сжатия (правда на Pascal на PC), так вот первые результаты не могут не радовать: действительно, таблица исходных данных хорошо жмётся (всем кроме RLE), это было видно на RAR, HA, ZIP и т.д., суммарно (т.е. исходя из размеров полученных таблиц с исходными даннымии служебными данными), получается прирост коэффициента сжатия на 10% (в среднем, сравнивается файлы от LC), однако если даже написать указанный пакер на Спектруме, то он будет слишком медленным: во-первых, задача подбора коэффициентов C[i], во-вторых, распаковка в битовом потоке, в-третьих, битовое представление дерева (не-)повторов. И наконец, распаковка исходных данных, что подразумевает либо метод Huffmana (изначально медленный, так как тоже битовый) либо LZ* (частично в битовом представлении).
если не ошибаюсь все это есть в Rip, тормозит конечно, но вполне терпимо
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
там архив есть sources.rar ищи там.
монстр не сильно страшный- я его сначала писал внаглую с сишного исходника (который в свою очередь выдрал из связки LZSS+Arifm) а потом проводил жестокую оптимизацию, успешно продолженую алко.
число кодов уменьшить можно. надо уменьшить размер таблицы частот и изменить счетчик битов чтобы он пустые нули не учитывал при сжатии
пробовал дожимать файлы после хрипа. выигрыш- от 5 до 20% получался.
Сорри что я тут встреваю. Но вообще-то Хафманское и арифметическое сжатие, это методы которые не дают потерь. И в худшем случае размер данных никогда не увеличивают. Если не считать того что приходится хранить таблицу (на практике я в этом сам убеждался, немного сжимаются даже случайные данные).
В Хафмане дерево строится так. Берутся символы считается число их вхождений в файл. Допустим если у нас есть 4 символа A,b,c,d которые появляются в файле 10 33 45 99 раз. Мы составляем таблицу в которой находим два самых редких символа и суммируем их числа. В итоге получается как бы их общее число вхождений которые мы вставляем в таблицу вместо этих двух(в соотвествующее место). Затем делаем тоже самое, в двумя самыми редкими элементами и так пока не останется два элемента....
В итоге (см. картинку символы будут кодироваться так) -
A - 0, B - 11, C - 100, D - 101
В итоге весь файл длиной 191 байт у нас умещается в 64 байта...
Саму систему составления кодов можно сделать ввиде односвязного списка в котором нужно выделить максимум 512 элементов. На спектруме особых проблем с памятью и скоростью упаковки не возникает....
Надеюсь что я изложил достаточно понятно. (не могу сейчас как следует свои слова обдумать, потому что из дома надо уходить, т.к. опаздываю)
............
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
Нет, RIP использует чистый Huffman