Внимание! Следующий текст - это описание задания, реализация которого опубликована в данном репозитории.
Вам необходимо реализовать архиватор. Задача — достичь как можно большей степени сжатия без потерь.
Замер будет проводиться в трех номинациях:
- Арифметическое сжатие (допустим только алгоритм с нормализацией)
- PPM
- BWT
Для повышения степени сжатия своего архиватора рекомендуется использовать следующие методы:
- Адаптивная (или блочно-адаптивная) реализация арифметического сжатия.
- Подбор параметров агрессивности сжатия (возможно динамически, т.е. во время исполнения программы).
- Начальная инициализация таблиц вероятностей наиболее подходящими значениями (возможно — смена таблиц при изменении характера данных).
- Увеличение точности алгоритма арифметического сжатия (использование int64_t и double).
- Если вам этого кажется мало — реализуйте PPM (как минимум простой, рассказанный на лекции, с любыми дополнениями, которые вы можете найти в книге Методы сжатия данных).
- За использование чужих исходных текстов или совместное написание — работы всех причастных будут сниматься с замеров, и им будет присуждаться 0 баллов. Подробнее — читайте Stanford CS Honor Code.
- Если разархивированный файл не совпадает с исходным, компрессор падает или работает более 3 минут, ему присваивается значение худшего результата в замере.
- За первые три места в любой номинации (после собеседования по алгоритму) — дополнительные баллы.
- Скопировать проект себе на компьютер (git clone)
- Собрать шаблон
- Реализовать архиватор
- Загрузить архив с репозиторием в формате .zip на сайт лаборатории
В примере используется пакетный менеджер APT, который по умолчанию стоит
на Ubuntu. На macOS можно пользоваться Homebrew, и тогда на 1-2 этапах будет
использоваться команда brew
вместо apt
.
-
Обновляем package list:
sudo apt update
-
Устанавливаем всё необходимое.
sudo apt install -y git cmake g++ python3
-
Клонируем репозиторий в вашу любимую папку:
cd path/to/favorite/folder git clone https://gitlab.com/Ploshkin/compressor.git
После этого там должна появиться папка compressor.
-
Заходим в папку compressor, создаём папку build и заходим в неё:
mkdir build cd build
-
Теперь конфигурируем проект с помощью CMake, указав ../src как папку с исходниками, а после ключа
-G
— формат проекта, который мы хотим получить. Например, эта команда сгенерирует самый обыкновенный Makefile:cmake -G "Unix Makefiles" ../src
А эта — проект для CodeBlocks:
cmake -G "CodeBlocks - Unix Makefiles" ../src
Все поддерживаемые форматы можно найти в справке
cmake --help
. В дальнейшем вам не нужно будет конфигурировать проект повторно. -
Собираем проект удобным образом, например:
make # нужно быть в папке compressor/build
-
Проверяем папку compressor/build на наличие исполняемого файла compress.
-
Тестируем шаблон:
cd .. # поднимаемся из build в папку compressor python3 tests/run.py
После успешного выполнения тестов в папке compression появится файл results.csv, который можно открыть и посмотреть, что тестирование действительно прошло успешно.
-
Ура, всё получилось! Вы готовы создавать лучший в мире архиватор.
Эпиграф:
— Надо было ставить Linux!
-
В первую очередь ставим Git for Windows.
-
Теперь ставим CMake.
-
Для тестирующего скрипта ставим интерпретатор Python 3.
-
Запускаем Windows PowerShell.
-
Клонируем репозиторий в вашу любимую папку:
cd path/to/favorite/folder git clone https://gitlab.com/Ploshkin/compressor
После этого там должна появиться папка compressor.
-
Заходим в папку compressor, создаём папку build и заходим в неё:
mkdir build cd build
-
Теперь конфигурируем проект с помощью CMake, указав ../src как папку с исходниками, а после ключа
-G
— формат проекта, который мы хотим получить. Например, эта команда сгенерирует MinGW Makefile:cmake -G "MinGW Makefiles" ../src
А эта — проект для CodeBlocks:
cmake -G "CodeBlocks - MinGW Makefiles" ../src
Все поддерживаемые форматы можно найти в справке
cmake --help
. В дальнейшем вам не нужно будет конфигурировать проект повторно. -
Собираем проект удобным образом, например:
mingw32-make # нужно быть в папке compressor/build
-
Проверяем папку compressor/build на наличие исполняемого файла compress.exe.
-
Тестируем шаблон:
cd .. # поднимаемся из build в папку compression python tests/run.py
После успешного выполнения тестов в папке compression появится файл results.csv, который можно открыть и посмотреть, что тестирование действительно прошло успешно.
-
Ура, всё получилось! Вы готовы создавать лучший в мире архиватор.
Чтобы прогнать тесты с докером:
- Установите Docker
- Склонируйте ваш репозиторий
- Соберите образ и запустите контейнер:
docker build . -t compressor_tests
docker run compressor_tests
Так как набирать эти 2 строчки слишком долго, в корне лежит маленький Makefile,
который позволяет сократить проверку до 2х слов make tests
Внимание: задания будут проверяться именно этим способом, поэтому желательно протестировать последнюю версию вашей программы с Docker
Общий вид:
# Unix
compress [options]
# Windows
compress.exe [options]
Опции:
--help = Вызов справки, аналогичной этой.
--input <file> = Входной файл для архивации/разархивации, по умолчанию `input.txt`.
--output <file> = Выходной файл для архивации/разархивации, по умолчанию `output.txt`.
--mode {c | d} = Режим работы: `c` - архивация, `d` - разархивация; по умолчанию `c`.
--method {ari | ppm | bwt} = Метод архивации/разархивации файла, по умолчанию `ari`.
Например, если мы хотим заархивировать файл the_financier.txt в файл the_financier.cmp методом PPM, то команда будет выглядеть так:
# Unix
compress --input the_financier.txt --output the_financier.cmp --mode c --method ppm
# Windows
compress.exe --input the_financier.txt --output the_financier.cmp --mode c --method ppm
Git — это просто, полезно и очень удобно.
Для выполнения задания вам понадобится всего 7 команд:
-
Инициализировать себя (в самом-самом начале):
git config --global user.name "Ivan Ivanov" git config --global user.email "ivanov@email.com"
-
Клонировать репозиторий:
git clone <repo-url>
repo-url
— URL к репозиторию. -
Добавить удалённый репозиторий:
git remote add <name> <repo-url>
name
— имя репозитория для использования в дальнейшем в командной строке.Пример:
git remote add my_cmpr https://gitlab.com/<Your nickname>/compressor.git
-
Добавить файл/папку к текущим изменениям:
git add <path>
Если вы находитесь в корневой папке проекта, можно сделать так:
git add .
Тогда добавятся все файлы, которые изменились со времени последнего коммита.
-
Сделать коммит:
git commit -m "<comment>"
comment
— комментарий к коммиту.Эта команда создает в локальном репозитории новую версию проекта, которая включает все изменения, добавленные с помощью
git add
.Пример:
git commit -m "Add PPM"
-
Запушить репозиторий:
git push <name> <branch>
name
— имя репозитория из пункта 3,branch
— имя ветки.Эта команда пушит ваш локальный репозиторий в указанный, так что все файлы в указанном репозитории будут обновлены до последней версии.
Коротко про ветки: Git может поддерживать несколько независимых веток одного проекта. У каждого проекта существует главная ветка —
master
, которая, по-хорошему, должна представлять из себя последнюю рабочую версию проекта. В остальных ветках пилится что-то новое, и, в случае успешного тестирования, происходит слияние ветки с главной. Но вы можете не заморачиваться и всегда пушить вmaster
.Пример:
git push my_cmpr master
-
Pull репозитория:
git pull <name> <branch>
Эта команда, наоборот, "забирает" из указанного репозитория версию проекта, и, если ваш локальный проект имеет более страую версию, то он обновляется.
Пример:
git pull my_cmpr master
Удобная связка команд для того, чтобы запушить новую версию (например, вы реализовали декодирование арифметическим алгоритмом):
# из корневой папки проекта
git add .
git commit -m "Add ARI decompressor"
git push my_cmpr master
Вот и всё!
Если вы хотите более подробно ознакомиться с Git: Getting Started, Git Pro Book.
-
src
— папка с исходными файлами:- main.c — основной файл;
- utils.c — файл, содержащий функции, чтобы парсить аргументы командной строки;
- ari.c, ppm.c, bwt.c — файлы, которые вам нужно изменить, написав соответствующий алгоритм;
- *.h — заголовочные файлы ко всем вышеуказанным;
- CMakeLists.txt — файл, необходимый для генерации нужного вам формата прокета с помощью CMake.
Вообще говоря, никто вас не обязывает использовать именно такую архитектуру решения. Самое главное — ваше решение должно поддерживать указанный формат запуска.
-
test_files
— папка с тестовыми файлами. Рекомендуется её не трогать: при каждом пуше ваше решение тестируется на файлах из этой папки на стороне GitLab для того, чтобы убедиться, что всё действительно собирается и работает должным образом. После тестирования можно скачать файл results.csv и посмотреть итог. -
tests
— папка для тестирования. Содержит:-
testing
— содержит необходимые для тестирования скрипты. -
run.py
— тестирующий скрипт на языке Python. Его можно использовать для тестирования вашего архиватора следующим образом:python run.py [options]
Опции:
--timeout <timeout> = Время, отведённое для тестирования каждого файла, по умолчанию 180с. --testdir <dir> = Папка с тестовыми файлами, по умолчанию `test_files`. --outputdir <dir> = Папка для выходных файлов, полученных в результате работы архиватора. --output = Флаг для сохранения выходных файлов. Если папка не указана с помощью ключа --outputdir, то папка по умолчанию — `output`.
Скрипт сжимает и распаковывает каждый файл, находящийся в указанной папке, вычисляет размер получившихся файлов, сравнивает содержимое и записывает результат по каждому файлу в results.csv.
Возможные вердикты:
- OK — файл успешно сжат, распакован и совпадает с исходным;
- WA — файл успешно сжат и распакован, но не совпадает с исходным;
- RE1 — ошибка выполнения при сжатии;
- TL1 — превышен таймаут при сжатии;
- RE2 — ошибка выполнения при распаковке;
- TL2 — превышен таймаут при распаковке.
-
config.cfg
— файл с указанием реализованных методов сжатия в формате списка JSON.Всего допускается 3 значения: "ARI", "PPM", "BWT".
Пример содержимого файла:
["ARI", "BWT"]
Этот файл необходим для тестирующего скрипта, чтобы определить, какие методы тестировать.
-