LINUX.ORG.RU

Эталонные наборы данных для оценки сжатия

 , , датасет, палата мер и весов, сжатие данных


1

1

Есть ли такие? Краткий поиск через поиск ничего не показал или я не знаю как искать. Суть проста, очередной дурак (я) играется с очередным своим (а на деле велосипедным наверное) «алгоритмом» сжатия, без цели, а просто за интерес. Ну, понятно что вся суть итоговая с какими данными то или иное работает лучше, универсальных алгоритмов сжатия не существует. Но чисто для своего удобства хотелось бы иметь некий набор, например данные состоящие только из уникальных значений, данные с последовательным повторением, оно же но с разной частотой повторений или размерами этих самых повторений, смешанные данные в разных пропорциях и так далее и так далее, как набор искусственных данных для синтетической оценки коэффициентов сжатия так и реальных наборов и их комбинаций так сказать типичных в повседневной практике.

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

Можно самому напридумывать конечно, но лень и возможно будет некорректно, может есть что? А то просто совать что под руку попадётся в целом прикидывая что внутри такое себе.

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

В целом не критично, но просто если такое есть было бы удобно.
Как-то так. Может кто знает? Где и куда копать.
Если такого не существует, то надо будет заняться.

Перемещено hobbit из general

★★★★★

Последнее исправление: LINUX-ORG-RU (всего исправлений: 3)

Ответ на: комментарий от vvn_black

Там по подписке, 40$ надо заплатить в месяц чтобы иметь доступ.
А потом публиковать нельзя. Я уж лучше какнить сам :)

LINUX-ORG-RU ★★★★★
() автор топика
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)

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

датасет должен быть произвольным.

alysnix ★★★
()
Ответ на: комментарий от alysnix

Всё так, но синтетические тесте на то и синтетические, любые данные будут состоять из набора синтетических, а итоговая степень сжатия будет состоять из комбинации коэффициентов от этих синтетических. Польза будет если можно будет выявить корреляцию данных из набора с другими, тогда можно не глядя сделать оценочное суждение о том какой алгоритм для каких данных хорош будет или плох. Да это всё на уровне перекладывания с места на место, можно просто взять корень ОС (где все возможные варианты всего подряд) и сжать его весь и смотреть на фактический результат, так как только он и только он важен в итоге. Но, яж играюсь =)

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от alysnix

Если добавить требование самораспаковки то это будет неважно - пусть затачивают на что угодно. Главное чтобы не прятали датасет в коде архиватора.

firkax ★★★★★
()
Ответ на: комментарий от anonymous

Спасибо, да, на практике имеет смысл и часто надо хранить много одинаковых данных, там по сути 9 114 файлов с одинаковым содержимым на 90%. И весь бенчмарк заключается в том что они тренируют архиватор чтобы он составил словарь после чего очень эффективно по нему жал однотипные данные с не шибко большими изменениями.

А ещё они в своём же публичном датасете лоханулись ибо есть такое

"API rate limit exceeded for 70.91.205.233. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)"

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

grep "API rate limit" -r ./ | wc -l 257

Датасет состоит из 257 файлов в которых одно и тоже, а именно ошибка превышения запроса к API. Ну, такооее. Кому то было похеру, зато какие красивые графики хехехехе. Неглядя, за 5 митут нагенерили данных и не проверяя их сделали презентацию, кек. фейспук :D

Да я маленечко злорадствую, но это грязные данные. Я лучше наверное сяду и ручками напишу генераторы. Будет проще. Но всё равно спасибо, без сарказмов.

LINUX-ORG-RU ★★★★★
() автор топика
Последнее исправление: LINUX-ORG-RU (всего исправлений: 2)
Ответ на: комментарий от Forum0888

Прикольно, но там ссылки на ftp битые. По сути хорошее решение жать чисто битмапы и наглядно и наборы составлять удобно =)

Но, результаты в табличке есть, а данных на основе которых результаты составлены нету, в вебархиве наверное можно найти

UDP Нет, в вебархиве нету :3 Ну и ладно =)

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от LINUX-ORG-RU

Так на сайте много ссылок на архивы, содержащие тестовые данные ...
Да и mirrors архивов с файлами для тестов где-нибудь в inet имеются.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 5)
Ответ на: комментарий от Forum0888

Ну попыкаю мененько, пока везде ссылки битые. А из рассматриваемых алгоритмов коих там описана судя по диагональному чтению сотни ведётся разговор о том вот это вот вот для этого вот, оно и правильно делают разбор что для чего лучше подходит, какие проблемы и всё такое. Но это уже на уровне научного подхода, для последующих выводов и прочих изысканий. Мнеж нужна просто тупая как палка метрика не из академической, а более приближенной к реальной жизни. Да, жопа у меня липнется от хотелок, но яж не профи, просто поиграть :3 Но ладно, всё равно спасибо. Интересный ресурс. Но так как я в процессе придумывания своего, пока буду избегать чтения, хоца же самому =) А уже потом выяснить что это уже используется вон там то и там то. Нормальными алгоритмами сжатия занимаются математики, а я так, досуг провожу и всё.

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от alysnix

Да уже сжимают, в сетях где используется свёрточная модель это обычная практика, когда создаётся отдельный слой цель которого очень проста, принять в себя блок данных, сохранить во внутреннем представлении, а затем выдать точную копию. Сжатие данных там чудовищное, сосут любые алгоритмы, но, это сжатие конкретных данных. На любых отличных сосёт уже сетка, даже если 1 бит поменять. Если очень грубо сеть внутри себя создаёт хеш, но может в отличии от обычных хешей восстановить из него данные. Это всё есть, весь вопрос в том насколько универсале подход, у нейросетей он локален. Сжать нормально они могут только что уже было, если очень грубо (и вообще не так) они имеют в себе словарь просто во внутреннем оптимальном для себя и определённого набора данных виде.

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от dataman

1.1 GB or 4.8 GB after decompressing with bzip2 - link no longer works

Ну, там всё из разряда, а давай возьмём вот это и будем его сжимать и смотреть что будет. Без оглядки на то что из себя вообще данные то представляют, просто надеясь на их одновременно разнообразность и наличие излишеств которые будут архиваторами как кто может убирать. Нууу, мне кажется это ничем не отличается от например если я сделаю debootstrap oldstable .... и развёрнутый чрут в несколько гигабайт буду сжимать всем подряд, это уже константные данные по сути и очень разнообразные, более разнообразные чем срез куска википедии. Ну, мне так кажется.

https://unicode.org/Public/UCD/latest/ucdxml/

А вот это спасибо. Как просто фиксированные данные, с достаточной повторяемостью и разнообразием пойдёт.

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от LINUX-ORG-RU

У рандома сжатие x2-x3, у всяких дампов баз x9, а у видео x1. Это для zstd:3. Для допустимый уровень сжатия - это когда скорость записи не ниже чем 1000MBit/s (ага скорость инторнет-соединения) и скорость чтения >=2000MiB/s. Это для Btrfs/ZFS со сжатием. Но если бы я рендерил всякое говно, то такие скорости не отвечали бы моим потребностям. Если тебе нужно что-то максимально ужать в архиве, чтобы быстро распаковывать и архивировалось не долго, то используй zstd:8. Я, например, такое использую для образов initcpio.

rtxtxtrx
()
Последнее исправление: rtxtxtrx (всего исправлений: 3)
Ответ на: комментарий от t184256

👍️

Вот ещё классный ресурс: http://mattmahoney.net/dc/text.html

Соревнование в сжатии гигабайта английской Википедии, длящееся с 2006 года.

first 10⁹ bytes of the XML text dump of the English version of Wikipedia on Mar. 3, 2006

Под конец 2023 года на первом месте - nncp:

Compressed size: 106,632,363

nncp is a free, experimental file compressor by Fabrice Bellard, released May 8, 2019

Про премию: https://en.wikipedia.org/wiki/Hutter_Prize

anonymous
()
Ответ на: комментарий от anonymous

Дополню, пожалуй.

nncp v3.2 was released Oct. 23, 2023.

NNCP is an experiment to build a practical lossless data compressor with neural networks. The latest version uses a Transformer model.

Размер сжатых данных вместе с программой:

Total size: 107,261,318

anonymous
()